OpenCode VPS Hosting: Run OpenCode Server 24/7

Why run OpenCode on a server

The OpenCode docs describe opencode serve as a headless HTTP server that exposes an OpenAPI endpoint, and opencode attach as a way to connect a terminal UI to a server that is already running. That split is the whole case for a VPS: sessions live in the server process, not in your terminal. Close the laptop, lose the Wi-Fi, switch machines, and the job keeps running; you attach again and carry on.

• Long refactors and test runs continue while you are away from your desk.
• One checkout and one set of sessions, reachable from any machine you trust.
• A scriptable API: the server publishes an OpenAPI 3.1 spec at /doc and the repo ships a JS SDK generated from it, so other tools can create sessions and send prompts.

OpenCode is open source (MIT) and the canonical repository is github.com/anomalyco/opencode. Official docs live at opencode.ai/docs.

What the server needs

The docs publish no minimum RAM or CPU figure. The server is a thin layer around your repository: the model runs at your provider, so what you size for is your own builds, test suites and language servers. Two vCPU and 4 GB of RAM is a comfortable starting point for a normal web project; go larger if your compiler or test runner is heavy. Install needs only a Linux shell and either the official script or npm.

Step 1: create a non-root user and install

OpenCode runs shell commands and edits files with the permissions of the user that starts it. Give it its own unprivileged account on a machine that holds nothing else you care about.

adduser --disabled-password --gecos "" oc
sudo -iu oc
curl -fsSL https://opencode.ai/install | bash
exec bash -l          # reload so the new PATH entry applies
opencode --version

The docs list other install methods, including npm install -g opencode-ai and a Docker image at ghcr.io/anomalyco/opencode. Use whichever fits your server.

Step 2: sign in to a provider on the server

Run opencode auth login in the shell to configure an API key for any provider, or use /connect inside the TUI. The providers docs say the keys are stored in ~/.local/share/opencode/auth.json. Check what is signed in with opencode auth list, and remove a provider with opencode auth logout.

OpenCode Zen and OpenCode Go are two optional providers from the OpenCode team. The docs describe Zen as a list of models tested and verified to work well with OpenCode, and Go as a low-cost subscription plan for popular open coding models. Both are set up through /connect and opencode.ai/auth, like any other provider. We compare them with other options in OpenCode Zen and OpenCode Go.

Step 3: start the server on localhost with a password

The documented defaults for opencode serve are --port 4096 and --hostname 127.0.0.1. Authentication is HTTP basic auth, switched on by setting OPENCODE_SERVER_PASSWORD; the username defaults to opencode and can be changed with OPENCODE_SERVER_USERNAME.

OPENCODE_SERVER_PASSWORD='a-long-random-string' \
  opencode serve --port 4096 --hostname 127.0.0.1

The docs also show opencode web for a browser interface, with the same --port, --hostname, --mdns and --cors flags and the same password variable. Without a port it starts on 127.0.0.1 with a random available port, so pin one when you plan to tunnel to it. You can also set port, hostname, mdns and cors in the server block of opencode.json.

Do not follow the docs' example of --hostname 0.0.0.0 on a public VPS. That makes an agent that can run shell commands reachable by every scanner on the internet, protected by one shared password. Leave mDNS off too; it exists for local-network discovery.

Step 4: keep it alive with systemd

Put the password in a root-owned file so it is not in the unit or your shell history, then run the server as the oc user. Replace the ExecStart path with whatever command -v opencode prints for that user.

# /etc/opencode.env  (chmod 600, owned by root)
OPENCODE_SERVER_PASSWORD=a-long-random-string

# /etc/systemd/system/opencode.service
[Unit]
Description=OpenCode server
After=network-online.target
Wants=network-online.target

[Service]
User=oc
WorkingDirectory=/home/oc/project
EnvironmentFile=/etc/opencode.env
ExecStart=/home/oc/.opencode/bin/opencode serve --port 4096 --hostname 127.0.0.1
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now opencode
curl -u opencode:a-long-random-string http://127.0.0.1:4096/global/health

The last command calls the documented GET /global/health endpoint, which returns the server status and version. If you only want a quick test, run the same opencode serve line inside tmux instead.

Step 5: reach it safely from your own machine

Forward the server port over SSH. Nothing is opened on the VPS firewall except SSH.

ssh -N -L 4096:127.0.0.1:4096 oc@your-vps
# in another terminal on your laptop:
opencode attach http://localhost:4096 --password 'a-long-random-string'

opencode attach accepts --dir, --continue, --session and --fork as well, so you can resume the last session or branch from it. For a browser, point it at http://localhost:4096 through the same tunnel after starting opencode web. With Tailscale, install it on both machines, keep the server bound to 127.0.0.1 and tunnel to it over the tailnet SSH address; the server port is never exposed beyond the VPS itself.

A related trick from the CLI docs: opencode run --attach http://localhost:4096 sends a one-off prompt to the running server instead of starting a fresh process, which avoids MCP server start-up time on every call.

Permissions: decide what the agent may do

OpenCode's permission setting resolves each tool to allow, ask or deny. The docs say most permissions default to allow, with doom_loop and external_directory set to ask, and .env files denied for reads by default. On a headless server nobody is watching the prompt, so set your policy in opencode.json before you walk away:

{
  "permission": {
    "*": "ask",
    "bash": "allow",
    "edit": "deny"
  }
}

That example is from the docs: a global default of ask, with bash allowed and edits denied. Granular object rules use pattern matching where the last matching rule wins, and per-agent overrides under the agent key take precedence over the global config. Permissions are a policy inside OpenCode, not a sandbox; the real boundary is the unprivileged user and a server with nothing else on it.

Updating and configuration

opencode upgrade updates to the latest version or one you name. Config files are merged rather than replaced: global ~/.config/opencode/opencode.json, then an OPENCODE_CONFIG file, then the project's opencode.json, with later sources winning. The config also supports {env:NAME} and {file:path} substitution so secrets can stay out of the file, and autoupdate can be set to false or notify.

VPS or managed: what it costs

Model usage is separate in every row: your provider (or OpenCode Zen or Go, if you choose them) bills you directly.

The managed option: Coding Harness

OpenClaw Launch's Coding Harness is a hosted Linux workspace you open in the browser, with eight coding CLIs pre-installed: Claude Code, Codex, OpenCode, Aider, OpenClaude, Zero, Pi and DeepSeek Harness. You pick one from the workspace card and all of them share one persisted /workspace directory, with Reset and Wipe available. You sign in to OpenCode the native way, in the terminal, with opencode auth login. The workspace does not inject your saved provider API keys under the variable names a CLI reads, so an ambient key cannot silently override a subscription login.

Telegram works too: click Telegram on the workspace card, paste a new bot token from @BotFather and open the one-time pairing link. Each message to that bot then runs Codex, Claude Code or OpenCode inside the workspace and the result comes back in chat; only the paired Telegram account can use it. A workspace uses one of your plan's instance slots at normal plan pricing, and there is a 30-minute free trial with no credit card. See the OpenCode tool page and the OpenCode comparison.

OpenClaw Launch also hosts chat agents (OpenClaw and Hermes Agent) on Telegram, Discord, WhatsApp and more. That is a different product from a coding workspace; see Hermes hosting and hosting.

Frequently Asked Questions

Related Guides

• Coding Harness hosting — the managed workspace
• Hermes Agent with OpenCode
• OpenClaw with OpenCode Go
• Claude Code VPS hosting
• Codex VPS hosting
• Pi coding agent VPS hosting
• OpenCode comparison