OpenComputer: serverless agents as a project you build, watch, and version

An agent is a folder in your repo, not a console you log into

OpenComputer describes itself as the easiest way to build and deploy an agent, and the README puts the model plainly: build, steer, and deploy serverless agents as code, where an OpenComputer project contains one or more agents that run in the cloud. The project is a directory in your repository. Creating one with `npx @opencomputer/cli init my-agent` produces a hello-world layout, and the README shows the shape:

my-agent/
├── opencomputer/
│   ├── project.ts
│   └── agents/
│       └── hello-world/
│           └── agent.ts
└── package.json

The `opencomputer/` tree holds the cloud agent definitions and is designed to grow to multiple agents in one project. A browser application can live in the same repository, but it has its own development and deployment lifecycle, which is the separation that keeps a frontend rebuild from touching your agent deployment. The audience is a developer who wants agents to be reviewed, versioned, and shipped through the same pull request process as the rest of their code.

Watch mode is the core loop, and the first run binds your project

The development loop is a watch flag on the deploy script:

npm run deploy -- --watch

On the first run of that command you choose an existing project from your account or create a new one, and that binding is reused on later runs. The CLI talks to `https://app.opencomputer.dev` by default, and the README is specific about when to change that, saying to pass `--api-url` or set `OPENCOMPUTER_API_URL` only when intentionally targeting another service. While the watch is running you edit the agent function, its tools, its connections, and its routing, then test from the dashboard or from the CLI. This is the part that makes the project feel like a development tool rather than a deployment form, and the reuse of the project binding is what removes the repeated manual selection.

Publishing an alias is how you get an immutable deployment

When the project is ready, the README gives the publish command:

npm run deploy -- --alias production

Deployments are versioned, and that is the safety property. The dashboard project view exposes the debug playground, deployments, sessions, schedules, webhooks, memory, database, secrets, and connections, while keeping infrastructure details behind the OpenComputer API. Two things follow from that separation. The set of things you can see and drive from the dashboard is deliberately small and deliberate, and everything about how the infrastructure is actually provisioned stays behind the API. For a team deploying agents to production, the alias naming is the release mechanism, so the question of what a version means is worth settling early.

Two CLIs, and the TypeScript one is the one to use

The README states that the TypeScript `opencomputer` CLI is focused on managed agents and is separate from the legacy Go `oc` CLI. The common commands are listed as:

opencomputer whoami
opencomputer init my-agent
opencomputer agents
opencomputer session "Say hello"
opencomputer deploy --watch
opencomputer deploy --alias production
opencomputer run hello-world "Say hello"

The command set is worth reading carefully because it describes the whole product surface. `whoami` tells you which account the CLI is acting as. `init` scaffolds a project. `agents` lists what you have. `session` starts a session with a prompt, which is how you drive an agent from a terminal. `deploy` has the watch and alias forms. And `run` executes a named agent locally in the project with a prompt. The distinction between `session` and `run` is the interesting one, since one goes through the platform and the other appears to run an agent from the project directory.

The control plane underneath is Go, and it is a large dependency surface

The repository is not only a TypeScript CLI, and the `go.mod` at the root is a useful indicator of the scale of the platform behind it. The module is named `github.com/opensandbox/opensandbox`, and the dependency list spans several cloud providers at once, with the AWS SDK v2 for S3, EC2, Lambda microVMs, Secrets Manager, and SSM, the Azure SDK for compute, network, key vault secrets, and blob storage, plus Stripe, WorkOS, NATS, Redis, Postgres via pgx, gRPC, Prometheus, and Sentry. The Makefile matches, building a control plane server, a sandbox worker, and an in-VM agent, with separate cross-compilation targets for Linux ARM64 and AMD64, and the agent built as a static binary. The `SELFHOSTING.md` file at the root and the `deploy/` and `cloudflare-workers/` directories suggest the platform can be run outside the hosted service, which is the question to answer before building on it.

Where OpenComputer is the wrong choice

Two limits are visible in the README and the release history. The first is version maturity. The releases listed are v0.6.0.47, v0.6.0.48, and v0.6.0.49, three releases in September 2026, and the CLI is described as separate from a legacy Go CLI, which is the shape of a project in the middle of a migration rather than one with a settled interface. A team that plans to build a large internal platform on the CLI surface should expect the command set to move. The second is the hosting dependency. The default target is the hosted service at app.opencomputer.dev, and the agent model depends on that service for sessions, memory, secrets, and schedules. If your requirement is agents that run entirely inside infrastructure you control with no external calls, the self-hosted path is the one to evaluate first.

Editorial conclusion

OpenComputer fits a team that wants agents written as code, deployed to a managed cloud, and versioned so a release is a named, immutable deployment rather than whatever was on the server that morning. It is the wrong choice if you need to run agents entirely on your own infrastructure without depending on the hosted service, and it is the wrong choice if you want a single stable CLI, because the README states the TypeScript CLI is separate from the legacy Go CLI and that the tool is still at a 0.6 version line. Before you adopt it, read SELFHOSTING.md in the repository and decide whether the managed path or the self-hosted path is the one you want, because that choice determines most of what you build on top.

Frequently asked questions

Official sources

1. diggerhq/opencomputer on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases