What we shipped since May: three regions, IaC and Box beta

US West is live. Our Terraform/OpenTofu, Pulumi and Alchemy providers are published. Box is in open beta, and the ZCP work now includes proposals for changes to stage and production.

Our last blog post was the ZCP public preview in May. We've shipped quite a lot since then. The blog has some catching up to do.

We'll start with infrastructure as code, because reviewing an infrastructure change next to the code that needs it is something we care about a lot.

Your infrastructure, in the repository

We published the first releases of our Terraform/OpenTofu, Pulumi and Alchemy providers in late October. You can define projects, services and the configuration around them in code, review the changes, then apply them through the tool your team already uses.

The current releases are:

• Terraform/OpenTofu provider `0.1.2` for HCL and a plan/apply workflow.
• Pulumi `0.1.1`, with @zerops/pulumi and the higher-level @zerops/pulumi-app both published on npm at 0.1.1.
• Alchemy `0.2.0`, published on npm as @zerops/alchemy, for TypeScript/Effect infrastructure programs.

One detail we particularly like: the Terraform and Pulumi providers require you to choose the mode of a managed service explicitly. For PostgreSQL, that means postgresql:single@16 or postgresql:ha@16. Someone reviewing the configuration can see which one you're asking us to run.

That choice matters during updates too. Adopting the qualified type for the mode you already have updates the state; switching to the other mode replaces the service. The replacement belongs in the plan, where you can review it before applying. These are early releases against a beta API, so pin the versions and read the upgrade notes.

We go through the actual workflows in Terraform, Pulumi and Alchemy on Zerops.

Three places to run a project

You can now place a project in EU Central (prg1), US East (ny1) or US West (sea1). US West gives you a west-coast option alongside the two existing regions.

Choose the region when you create the project. The status page lists all three, and they're also available in the Challenge Launchpad.

Box beta: fork a sandbox, keep working

Box gives agents Firecracker microVMs inside your Zerops project. Each sandbox has its own kernel and memory, and a managed zbox@1 workspace VM hosts them. You can create sandboxes through an HTTP API, the console, CLI or MCP, then park, wake, snapshot and fork them.

The part we're most excited about is being able to fork a sandbox with its running processes, as long as the copy keeps the same size. The agent gets a copy of the environment with the setup work already done.

Billing is at the workspace level: CPU, RAM and disk, with no separate sandbox charge. Parking a sandbox releases its CPU and RAM reservations inside that workspace; the workspace resources remain billed.

Box is in open beta, so any Zerops user can create a workspace today. Workspace data isn't backed up yet, so keep anything you need elsewhere. The Box docs cover setup.

The sandbox comparison goes deeper into the isolation model and where Box fits.

ZCP and Mate

The public preview gave coding agents a way to work with Zerops infrastructure. We've continued building that in the ZCP repository, including the work on Mate.

ZCP `9.237.0`, released November 3, added Mate proposals for changes to an application's stage and production. `9.239.0`, released November 5, added MCP-server proposals. Mate itself is coming soon.

For ZCP today, the project is the permission boundary. One ZCP process works with one project, and its credential can grant deployments, environment changes, restarts, scaling and public-access changes. Most operations run without another ZCP-specific confirmation.

Our recommendation is to put ZCP in development or staging and keep production in a separate project without a ZCP service. We like automation. Production credentials still deserve some thought.

Less friction in zCLI

May's 1.1.0 release added zcli upgrade, update checks and prebuilt platform binaries for the npm package. To check without installing:

zcli upgrade --check

It exits non-zero when an update is available, which matters if you're calling it from a script.

September brought the Elasticsearch endpoint update in 1.1.1 and --no-wait for service push and deploy in 1.1.2. With that flag, the command returns once Zerops creates the process; your CI still needs to follow deployment completion. October's 1.1.3 added browser-based login and sudo mode through the OAuth device flow.

The zCLI changelog has the release details.

Swarm: a pool your code controls

Swarm gives your application a pool of containers or VMs through an HTTP API. Reserve one, run commands, release it. Your code controls the pool size; horizontal autoscaling is off.

That gives you a place to run your own CI jobs or other short-lived work with explicit control over capacity. Use the VM type for untrusted code, as the docs recommend.

Recipes that include the rest of the application

The August 8 to 9 Zerops Challenge brought recipes and ZCP together: choose infrastructure, authorize your coding agent, then build and deploy against it. The Launchpad keeps that walkthrough and its troubleshooting notes available.

We've also published a GitHub Actions example for branch and PR environments. It creates the app and worker together with PostgreSQL, cache, queue and object storage. Closing the PR or deleting the branch triggers cleanup. Stage and production keep their infrastructure while application code is redeployed.

This is the kind of preview we want when reviewing a change that touches a worker and the database. You can run the application with the services it uses. The PR environments article walks through the lifecycle and data handling.

The public recipes repository also includes WordPress, Umami and Mailpit alongside the framework examples. You can read how each environment is put together before deploying it.

Pick a recipe, look at its services and cost, and deploy an environment of your own.