Nehemiah: Firecracker microVMs with a VNC desktop, preinstalled agents, and a fork that clones live state

Each machine is a kernel, not a shared container

The isolation claim is the whole design. Every computer Nehemiah hands out is a real Firecracker microVM, a full machine with its own kernel, rather than a process in a shared container. Each VM is jailed and resource-capped, and it is restored from a memory snapshot in about 3 ms, which is where the boot time claim comes from. Lifecycle is on a TTL: a machine destroys itself when it is done, unless you flip keep alive, in which case one runs until you stop it. The server side of that switch is an environment variable, NEHEMIAH_ALLOW_PERSISTENT, so whether a machine can outlive its TTL is a decision the server makes rather than the client. Guests sit behind an egress firewall and are network-isolated from each other. The component that runs all of this is the host daemon in nehemiahd/, written in Go, and it is a separate program from the site, which matters for anyone reasoning about what runs where: the Go daemon runs the microVMs, and the TypeScript side talks to it over the REST and WebSocket API.

The one-command source installers now exit with a pointer

This is the sharpest change in the project and it is documented in the README rather than buried in a changelog. The earlier self-serve installers are no longer supported. There were two: `infra/setup.sh` for a Linux box reached over SSH, and `infra/local/setup-local.sh` for an Apple Silicon Mac running Lima. Both used to build the host from source. They cannot any more, because host bootstrap now installs Firecracker, the jailer and the kernel only from signed managed-release artifacts, and a source checkout has no way to supply those. What they do now is exit with a pointer to the managed runbook. For a reader who arrived expecting a clone-and-go sandbox, that is a real change in the cost of the first hour: what used to be a script on a spare box is now a provisioning run against approved bare-metal hardware. The two scripts are still in the tree, so their presence in a repository listing says nothing about whether they work. Treat any tutorial or tutorial-era blog post written before this change as describing a path that no longer runs.

Provisioning one host means a signed release and an enrollment grant

Nehemiah runs as a managed cloud rather than a local build: hosts are provisioned from signed release artifacts onto machines the control plane enrolls. The supported path stands up one approved Latitude.sh bare-metal host from a published release tag of the form v followed by a version number:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install

# provision one managed host from a signed release (needs operator inputs — see the runbook)
infra/latitude/provision.sh --config "${XDG_CONFIG_HOME:-$HOME/.config}/nehemiah/latitude-host.env"

The config path follows the XDG convention with a fallback to the home config directory, and the script takes operator inputs that the runbook supplies. The runbook at infra/latitude/README.md covers four things worth knowing before you touch it: the signed-release trust boundary, the one-use enrollment grant, the WireGuard overlay, and the canary checks to run before admitting workloads. That last one is the shape of the whole design, since a host is something you verify and then admit rather than something you start trusting. Billing is also explicit: a host is torn back down, and the meter stopped, with infra/latitude/teardown.sh. There is a convenience path for poking at it without any of that, a `dev:demo` npm script that runs bash infra/latitude/dev-demo.sh, which is what the monorepo offers before you have hardware.

The website demonstrates the product, it is not the service

boringcomputers.com is a demonstration, and the project says so in the first screen of its README. You run the real thing yourself, self-hosted with your own keys, and the site exists so you can see what the machines look like before you commit bare metal to it. That distinction matters for anyone who found the site first and assumed it was a hosted product with a sign-up form: there is no account to create and no per-machine price to compare, because you are paying for the Latitude.sh hardware and the WireGuard overlay rather than for someone else's control plane. The public documentation lives on the same domain, at /docs, and it holds the full REST plus WebSocket API. Apache 2.0 is the licence, with the NOTICE file at the top level of the repository. The pattern is the same one a lot of infrastructure projects use, and it cuts both ways: you get the whole thing including the daemon source, and you also get the provisioning runbook, the enrollment grant and the canary checks as your problem rather than the operator's.

Fork copies a running machine, live state and all

Fork is the feature that changes what you can do with an agent that has already done work. It clones a running computer, exact live state included, in about 35 ms. That number is the difference between a scratch machine and a branch: you can hand an agent a machine that has already downloaded and configured something, then fork it to try two more approaches without paying for the setup twice, and the original keeps running. Storage is the other half of that model. Persistent volumes are S3-backed and they outlive the machine, which means the file a run produced survives the TTL expiring and is there when the next machine attaches it. Files move in and out by drag and drop, and any port can be opened through the daemon, which is how the live URL handed back by the agent is reachable from your browser rather than only from inside the guest. Those three things, fork, persistent volumes and port opening, are what let a task produce something you keep instead of something you screenshot before the machine disappears.

Two ways in from an AI client: nehemiah-mcp and an Effect-native SDK

Any agent that speaks MCP can drive the machines, and the setup is a config entry rather than a plugin to build. The server is nehemiah-mcp, published from packages/mcp:

{
  "mcpServers": {
    "nehemiah": {
      "command": "npx",
      "args": ["-y", "nehemiah-mcp"],
      "env": { "NEHEMIAH_URL": "http://localhost:8080" }
    }
  }
}

Pointing NEHEMIAH_URL at your own host is the whole binding step, and running it through npx means nothing has to be installed into the client. Claude Desktop and Cursor are named as the clients this is aimed at, and the framing is that they spin up and drive your computers as a tool. For code rather than configuration there is nehemiah-sdk in packages/sdk, an Effect-native TypeScript client installed with npm install nehemiah-sdk, which is the surface to reach for when the machine lifecycle is part of your own program rather than something an agent does on request. The two surfaces sit on the same REST and WebSocket API described in the docs.

The desktop is VNC, and the coding agents are already installed

What arrives on a machine is a full Linux desktop with a browser, a terminal and apps, reachable over VNC, or a fast headless shell if you would rather not pay for the display. The environment is preinstalled rather than assembled per request: claude, codex, cursor and pi are on the machine, along with node, python, git and internet access, so an agent that needs a toolchain does not spend its budget installing one. The AI then has two ways to act, and the project presents it as a real choice. It can use the screen, clicking and browsing, which is the only way to drive a UI that has no API. Or it can write and run code and hand you a live URL, which is faster and leaves something inspectable behind. The example the README leads with is typing build a snake game and getting code that was written, run, and served back as a link to play. Neither mode requires the operator to define the task in advance, which is why the whole thing is framed as handing a machine to an AI rather than as a remote desktop with an API.

A Turborepo where the daemon is Go and the site is SvelteKit

The layout is an npm workspaces monorepo driven by Turborepo, and the split matters when you are trying to work out what you are about to compile. apps/web is the site, on SvelteKit. nehemiahd is the host daemon, in Go, and it is the piece that runs the microVMs. packages/sdk holds nehemiah-sdk, the Effect-native TypeScript client, and packages/mcp holds nehemiah-mcp, the MCP server. infra/latitude holds managed-host provisioning, which means the provision and teardown scripts, the image builds and the networking. Five root scripts cover the common loop: npm install for all workspaces, then npm run dev for the site, npm run build for a production build, npm run check to type-check, and npm run lint for prettier plus eslint, each one fanning out through turbo run. The package manager is pinned to npm 11.16.0 and turbo sits at ^2.5.0 as the only root dev dependency. The rest of the tree tells you where the unglamorous work lives: guest-agent, gateway, generated, scripts and docs directories, plus agent configuration directories and the NOTICE file that ships with the Apache 2.0 licence.

Editorial conclusion

Nehemiah is worth the operational weight when the task genuinely needs a whole machine, which means clicking through a UI, browsing, installing something, or serving a port, and not when a subprocess and a temp directory would do. The pieces that decide it are all in the open: a kernel per machine instead of a shared container, guest egress behind a firewall, machines that destroy themselves on a TTL unless you turn on keep alive, and persistent S3-backed volumes that outlive them. Read the cost side before planning a fleet, because the supported path is no longer a one-command self-serve install. `infra/setup.sh` and `infra/local/setup-local.sh` now exit with a pointer to the managed runbook, since host bootstrap installs Firecracker, the jailer and the kernel only from signed managed-release artifacts that a source build cannot supply, which means you stand up an approved Latitude.sh bare-metal host, work through the signed-release trust boundary and the one-use enrollment grant, run the canary checks, and remember that `infra/latitude/teardown.sh` is what stops the billing. Also weigh what the site on that domain is not: boringcomputers.com demonstrates the product, while the thing you run is yours, Apache 2.0 licensed, with your own keys. The repository has no GitHub releases and last pushed to main on 2026-09-19, so treat the release artifacts the runbook depends on as something you verify rather than assume.

Frequently asked questions

Official sources

1. boringcomputers/nehemiah on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README