How to run OpenCode in the cloud: VPS, Docker, and managed options
Published September 26, 2026
Summary
OpenCode has no official hosted cloud, so running it in the cloud means using a managed agent platform such as Replicas or putting it on a machine you run: a VPS, a container, or a GitHub Actions runner. This guide covers each option, the server commands in OpenCode 1.x and 2.x, and how to keep a remote OpenCode server private.
Background
Why run OpenCode in the cloud
OpenCode is the open-source coding agent maintained by Anomaly, released under the MIT license with more than 200,000 GitHub stars. It works with more than 75 model providers, local models, OpenCode Zen's pay-as-you-go gateway, and the $10-a-month OpenCode Go subscription for open coding models.
On a laptop, a long refactor stops when the lid closes or the Wi-Fi drops. On a server, the agent keeps working, you can check in from your phone, and several sessions can run at once without competing for your CPU.
OpenCode does not host sessions itself. Its only hosted feature is share links, which sync a conversation to OpenCode's servers so others can view it. Every option below runs the agent on infrastructure that you or a third party operate. Replicas, which publishes this guide, is a strong fit for teams because it runs OpenCode in a managed VM per task, so nobody has to run or secure an OpenCode server.
Before you start
Check which OpenCode version you run
OpenCode 2.0 shipped on npm as @opencode/cli in September 2026. The 1.x line, published as opencode-ai on npm and as the latest tag of the Docker image, is still maintained. The remote-access commands differ between them, and most existing tutorials describe 1.x.
| Task | OpenCode 1.x | OpenCode 2.x |
|---|---|---|
| Start a headless server | opencode serve, on 127.0.0.1 port 4096 by default | opencode service start, or opencode serve in the foreground, on localhost port 49374 by default |
| Open the browser UI | opencode web | opencode pair prints one-time links and a QR code |
| Authentication | HTTP basic auth when OPENCODE_SERVER_PASSWORD is set; none otherwise | Generated password by default; replace it with opencode service set password |
| Connect a client to a remote server | opencode attach with the server URL, or opencode run --attach | opencode --server with the server URL |
| API specification | OpenAPI 3.1 at /doc on the server | Experimental OpenAPI spec at opencode.ai/v2/openapi.json |
| Documentation | opencode.ai/docs | opencode.ai/v2/docs |
Compared
Five ways to run OpenCode in the cloud
The table summarizes each option. Community projects in this space are young and change quickly, so check how actively they are maintained before you depend on one.
| Option | Where OpenCode runs | How you reach it | Setup effort | Best for |
|---|---|---|---|---|
| Replicas | A dedicated Linux VM per task, built from an environment your team defines | Dashboard, Slack, Linear, GitHub, GitLab, API, iOS app | Low | Teams that want managed OpenCode without running a server |
| VPS or cloud VM | A server you rent | SSH and tmux, an SSH tunnel, or a private network such as Tailscale | Moderate | One developer who wants a persistent machine |
| Docker container | A container on any host | Through the host, with the project directory mounted | Moderate | Reproducible, disposable sessions |
| OpenRouter Spawn and community projects | A VM or container they provision for you | SSH or a browser UI, depending on the project | Low to moderate | Trying OpenCode on a cloud machine quickly |
| GitHub Actions | GitHub-hosted runners | /opencode or /oc comments, schedules, workflow events | Low | Issue and pull request automation |
Replicas: best for teams running OpenCode in the cloud
OpenCode has no official hosted version, so the choice is between running and securing your own server or using a managed platform. Replicas runs OpenCode in a dedicated Linux VM per task, built from an environment your team defines once. There is no server port to expose, no password to configure, and no machine to patch.
A Replicas workspace is also more than a self-hosted OpenCode server, which gives you a terminal or the OpenCode web UI. Every workspace includes a Linux desktop with Chrome that OpenCode can drive to test its own work, and that you can watch or take over with your own mouse and keyboard. You also get terminals, in-place file editing with code intelligence, and preview URLs for apps the agent starts.
Tasks start fast because setup happens before you ask. Warm hooks run heavy setup such as dependency installs, builds, and Docker image pulls ahead of time, so each task claims a pre-warmed workspace instead of waiting on a fresh server.
Workspaces are multiplayer. Teammates open the same workspace, see who else is there and who is typing, follow the live session, and comment on diffs.
OpenCode authenticates with an OpenCode Go subscription, an Aster API key, or an OpenRouter key, set once for the organization or per person. Tasks start from the dashboard, Slack, Linear, GitHub, GitLab, a schedule, a webhook, the API, or the iOS app, and the same workspace can run Claude Code, Codex, Cursor, and other agents. Enterprise plans add SCIM, audit logs, static egress IPs, and dedicated or self-hosted deployment. Ellipsis also runs OpenCode in cloud sandboxes, triggered from Slack, GitHub, Linear, or cron.
A VPS or cloud VM: an OpenCode server behind SSH or a private network
Create a non-root user, install OpenCode, add your model provider key, clone the repository, and start OpenCode inside tmux so it keeps running after you disconnect. That is enough for terminal use over SSH.
For browser or remote-client access, run OpenCode as a server. In 1.x, opencode serve starts a headless HTTP server with an OpenAPI spec, and opencode web starts the same server with the web UI. Both bind to 127.0.0.1 by default. In 2.x, opencode service start runs a shared background server on localhost port 49374 with a generated password. Reach it from your laptop through an SSH tunnel, which the 2.x docs recommend, or over a private network such as Tailscale.
Keep the port off the public internet. In 1.x the server has no authentication unless OPENCODE_SERVER_PASSWORD is set, and neither version's docs cover TLS or reverse proxies. If you have to expose it, set a strong password and put a TLS-terminating proxy with its own authentication in front.
Docker: the official OpenCode image
OpenCode publishes ghcr.io/anomalyco/opencode for amd64 and arm64, with opencode as the entrypoint. The latest tag tracks 1.x, and 2.x releases have their own version tags. Mount the project directory and pass provider keys as environment variables.
A container per task keeps sessions out of each other's files, and cleanup means removing the container. Containers share the host kernel, so a VM is the stronger boundary for untrusted code.
OpenRouter Spawn and community projects
OpenRouter Spawn provisions a VM on providers such as DigitalOcean, Hetzner, AWS Lightsail, or Google Cloud, installs OpenCode connected to OpenRouter models, and opens an SSH session. Community projects package other setups. miantiao-me/cloud-code runs OpenCode on Cloudflare Workers and Containers, and pRizz/opencode-cloud is a Docker setup with passkey and TOTP login for AWS, Railway, and DigitalOcean.
These save setup time. Most are maintained by one person or a small team, and some ship with authentication off by default, so read the configuration before you expose anything.
GitHub Actions: OpenCode on issues and pull requests
opencode github install sets up the GitHub app, the workflow, and the secrets. OpenCode then runs on GitHub-hosted runners when someone comments /opencode or /oc on an issue or pull request, and it can also run on schedules and other workflow events. You supply a model provider key and the model to use.
The integration is documented for 1.x. Each run is bounded by the job and steered with further comments.
Replicas fit
When Replicas is the right way to run OpenCode in the cloud
Replicas is strongest when a team wants OpenCode in the cloud without anyone becoming its server administrator. Teams typically choose it when several of the following are true.
- You want OpenCode running in the cloud without anyone owning a server, a tunnel, or a password.
- You want each task isolated in its own VM rather than sharing one machine and its credentials.
- You want the agent to test its work in a real desktop and browser, and to take over that desktop yourself when needed.
- Teammates should be able to join the same workspace, follow the live session, and review together.
- You pay for models through OpenCode Go or OpenRouter and want those keys managed for the whole team.
- You want tasks from Linear, Slack, GitHub, GitLab, schedules, or webhooks to run against one environment definition.
- You want to use Claude Code or Codex for some tasks without a second setup.
Self-hosting
Checklist for a remote OpenCode server
A remote OpenCode server can read your code and run commands with your provider keys. These steps keep that access limited to you.
- Run OpenCode as a non-root user that can reach only the repositories and keys it needs.
- Keep the server bound to localhost and reach it through an SSH tunnel or a private network.
- In 1.x, set OPENCODE_SERVER_PASSWORD before allowing any network access. In 2.x, keep the generated password or set your own with opencode service set password.
- Store provider API keys in a file or secret manager readable only by the OpenCode user, never in the repository.
- Give parallel sessions separate Git worktrees or containers so they do not overwrite each other's files.
- Remember that share links sync the conversation to OpenCode's servers before you share a session about private code.
- Set spending limits with your model provider, since an unattended agent can run up usage.
FAQ
OpenCode cloud questions
Getting started with Replicas
Run OpenCode in the cloud with your team
Replicas includes a 14-day free trial with no credit card required. Connect a GitHub or GitLab repository, define the environment once, connect OpenCode with an OpenCode Go subscription or an OpenRouter key, and start a task from the dashboard, Slack, Linear, or a pull request comment. Each task runs in its own Linux VM and comes back as a pull request your team reviews.