May 1, 2026, 2:04 AM

Orin Nano is officially a Razzy worker (v1 connection update)

Razzy (Pi 5) is the parent brain; Orin Nano is a locked-down GPU worker over Tailscale with token auth and safe job endpoints. I got the foundation working, fixed a real systemd/Tailscale startup race, and I’m intentionally not enabling shell execution until file ops + policy + logs are in place.

## Quick update I finally got my Orin Nano out of “random dev box” territory and into something I actually trust as a worker. The rule is simple: **Razzy (Raspberry Pi 5) stays the parent controller. Orin is the worker appliance.** ## The architecture (simple on purpose) The mental model I’m enforcing: - Razzy owns orchestration + decisions - Orin executes approved jobs (GPU-heavy / worker-y tasks) - Razzy stores and uses the results I’m doing it this way because I *don’t* want two independent agents drifting into two separate brains with two separate memories. ## What’s working right now Right now the Orin worker is reachable only inside my tailnet and it’s intentionally limited: - Health checks + capabilities - GPU probe - Create/list/get jobs - Create/list workspaces - Append-only job ledger (JSONL for now) Security-wise, it’s behind: - Tailscale private network - Bearer token auth for all `/v1/*` routes - Binding only to the Orin’s Tailscale IP (not `0.0.0.0`) ## The small ops win that made this feel real I hit a classic startup race: `EADDRNOTAVAIL: address not available 100.86.175.53:8787` Basically, systemd was starting the service before Tailscale had actually brought up the interface/IP. The fix was an `ExecStartPre` wait script that blocks until the bind IP exists. Small change, big difference — the worker now restarts cleanly instead of randomly failing at boot. ## What I’m *not* doing yet (on purpose) No shell execution. No package installs. No “run arbitrary code.” Not because it’s impossible — because it’s irresponsible until the worker has the boring safeguards: - safe workspace file operations - explicit allowlists - per-job logs - timeouts + stdout/stderr capture - output size limits ## What’s next Next up is adding **safe workspace file operations** so Razzy can inspect and manipulate workspace state without jumping straight to command execution: - `get_workspace` - `delete_workspace` - `list_workspace_files` - `read_workspace_file` - `write_workspace_file` Once file ops + policy + logging are solid, then I’ll consider controlled command execution with strict allowlists. ## TL;DR Razzy can now call the Orin Nano as a private, authenticated worker over Tailscale. It’s limited on purpose, and that constraint is what makes the whole setup sane.

References: v1 Orin Nano/Razzy connection updates (Notion: v1 Orin Nano/Razzy connection updates)

Tags: orin-nano, razzy, tailscale, homelab, worker-architecture, build-in-public, jetson

Engagement

0 up votes, 0 down votes, 0 comments

No comments yet.