The Real Question
Putting Claude Code or Codex on a headless VPS sounds like a remote-work hack, but the useful question is narrower: should this agent run on a machine that is always on?
Sometimes the answer is yes. A VPS can keep background work moving when your laptop is asleep, on a plane, or on a weak network. It can host a stable Junction daemon, keep repositories checked out, and let you supervise sessions from a browser. For Switchboard, an always-on daemon can also support issue-to-pull-request automation when you are not at your desk.
Sometimes the answer is no. If the project depends on local-only services, private network resources, hardware devices, or desktop apps, a VPS adds more friction than it removes.
The VPS question is specifically about headless, remote, always-on execution. It is not the same as dedicating a spare workstation in your office. A VPS should earn its place by running work that benefits from being server-hosted.
Good Reasons To Use A VPS
A headless VPS fits best when the agent work is mostly code, tests, and Git operations. It is especially useful when the repository can build in a standard Linux environment and the task does not require your local desktop.
Good use cases include:
- Small bug fixes with reliable tests.
- Documentation and copy updates.
- Dependency cleanup that can run in a normal server environment.
- Repeated maintenance tasks.
- Linear issues that Switchboard can turn into pull requests.
- Long-running investigations where you mainly need progress visibility.
The VPS becomes an execution host. Junction becomes the control surface. You can see live output, review diffs, stop a drifting session, approve an action, or pick up the run from a phone.
The common thread is replaceability. If the VPS disappears, you should be able to rebuild it from documented setup steps. If the machine contains irreplaceable local state, it is a poor VPS candidate.
Bad Reasons To Use A VPS
Do not move a workflow to a VPS just because remote feels more advanced. A headless server is a poor fit when the local environment is the product.
Be cautious with:
- Mobile app builds that depend on local simulators.
- Desktop app work that needs a graphical preview.
- Repos that require access to private services only available on your office network.
- Tasks that need large local datasets you do not want to copy.
- Workflows that rely on secrets stored only on your laptop.
- High-risk migrations where you want a full desktop review before every step.
If the agent cannot faithfully reproduce the development environment on the VPS, the output will be less trustworthy. Keep those runs on a machine that already matches the project.
Also avoid using a VPS as a shortcut around unclear local setup. If nobody knows how to build the repo consistently, fix that first.
What To Install
A useful VPS setup is intentionally boring:
Node.js 20+
Git
GitHub CLI, authenticated if you create pull requests
Claude Code or Codex, authenticated for that machine
The Junction daemon
Project dependencies for the repositories you plan to runThe agent provider still handles its own authentication. Junction does not need to manage API keys for Claude Code or Codex. The daemon starts sessions and streams state; the provider CLI does the agent work.
Before you trust the VPS, SSH in once and run the project""'s normal install, typecheck, test, and build commands by hand. If the machine cannot run the repo without the agent, it will not become reliable just because an agent is driving it.
A Simple Placement Rule
Use this rule:
| Task shape | Better host |
|---|---|
| Needs GUI, simulator, local desktop tooling | Laptop or workstation |
| Needs private LAN resources | Machine on that network |
| Runs normal CLI tests and builds | VPS can work |
| Should continue overnight | VPS is often better |
| Needs careful human review before every edit | Desktop-first workflow |
| Repeated small Linear issues | VPS plus Switchboard can fit |
This table keeps the decision tied to execution needs, not preference. The browser can be anywhere. The agent should run where the task is most likely to succeed.
Use a VPS when """always on""" is the deciding feature. Use a local agent box when """same environment as my development machine""" is the deciding feature.
How Junction Changes The VPS Workflow
Without Junction, a headless VPS usually means SSH, tmux, terminal logs, and manual polling. That can work, but it is not a great mobile workflow. Small screens make terminals hard to scan, and approval prompts are easy to miss.
With Junction, the VPS runs the daemon and the agents. The browser shows sessions, live output, approvals, diffs, and notifications. You still own the VPS and the repository, but you do not have to operate the agent through a raw terminal every time.
This is especially useful when paired with multi-daemon workflows. Your laptop can run tasks that need local context. The VPS can run low-touch tasks. Junction can keep both visible from one account.
Security And Maintenance Tradeoffs
A VPS is not magically safer because it is remote. It is another machine with repositories, credentials, dependencies, and network access. Keep the attack surface small. Use normal SSH hygiene. Patch the OS. Avoid storing secrets that the automation does not need.
Also decide what the VPS is not allowed to do. For example, you might allow documentation edits and test fixes but keep production deploys off that machine. You might use Switchboard only for issues with a specific label. You might require desktop review before merging any PR created from the server.
The more autonomous the workflow becomes, the more important the boundaries become.
When To Upgrade The Junction Plan
The Free plan is enough to prove the idea with one saved daemon connection and two open chats. Core is the natural fit when you want unlimited daemons and open chats across a laptop, workstation, and VPS. Switchboard fits when the VPS is meant to keep a Linear queue moving after hours.
If you are deciding whether a VPS belongs in your workflow, start with the setup guide on one machine, then compare the limits on the pricing page. Add the VPS only when always-on execution solves a real problem.