Nehemiah: on-demand Firecracker microVMs you can hand to an AI, self-hosted with your own keys
On-demand Linux computers you can hand to an AI — real Firecracker microVMs with a browser, terminal, coding agents, and an AI that drives them.
At a glance
- What is it?
- Nehemiah is an Apache-2.0 system that spins up real Firecracker microVMs, each a full Linux machine with a browser, terminal and coding agent, that boot in milliseconds and self-destruct when done. It is self-hosted with your own keys; the hosted site is only a demo site.
- Who is it for?
- Use Nehemiah if you want to hand an AI a genuine, isolated, disposable Linux machine, a real Firecracker microVM with a browser, terminal and coding agent that boots in milliseconds and self-destructs, kept on infrastructure you control with your own keys: the microVM isolation and the self-hosted model are its real strengths over a container sandbox or a hosted service.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 38 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
A real disposable Linux machine to hand an AI
Nehemiah gives you on-demand Linux computers you can hand to an AI. The README is specific about what each one is: a real Firecracker microVM, a full machine with its own kernel, that boots in milliseconds, does its thing, and self-destructs when done, or stays up as long as you want. It is open source under Apache-2.0 and self-hosted with your own keys, and the hosted boringcomputers.com is a demo site, not the product, you run the real thing yourself.
The user is someone building agent workflows who wants to give an AI a genuine, isolated computer, with a browser, terminal, coding agent and a desktop, rather than a constrained sandbox or a shared environment. The README's demo, asking for a snake game and getting a booted desktop where the AI writes and serves the game at a live URL, illustrates the intent: a throwaway full machine per task.
What makes it substantial is that these are real microVMs, not containers pretending to be machines. Firecracker provides hardware-virtualized isolation with its own kernel, which is stronger isolation than a container, and the millisecond boot and self-destruct model is what makes per-task disposable machines practical. Self-hosting with your own keys is the other key property: the isolation and the data stay on infrastructure you control.
Why Firecracker microVMs, not containers
The choice of Firecracker is the technical heart. Firecracker is the microVM technology built for serverless workloads, giving each machine its own kernel and hardware-level isolation while still booting in milliseconds. For handing a machine to an AI, that isolation matters: an agent doing arbitrary work, running code, browsing, installing things, is exactly the case where you want a real VM boundary rather than a shared kernel.
The disposable model follows from the fast boot. Because a microVM boots in milliseconds, spinning one up per task and destroying it afterward is cheap enough to be the default, which is the README's self-destructs when done behavior. That gives a clean machine for each job with no state carried over, which is both a safety property, nothing persists to leak into the next task, and a simplicity one.
Each machine is a full environment: the README describes a desktop with a browser, a terminal, a coding agent and more, so the AI is not operating a bare shell but a real computer it can use like a person would. That combination, a genuine full desktop machine, isolated by a microVM, disposable, self-hosted, is what distinguishes Nehemiah from a code-execution sandbox or a container-based agent runner.
Self-hosting it with your own keys
Nehemiah is meant to be run on your own infrastructure. The README's setup starts with a clone and install:
git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm installfrom which you provision a managed host from a signed release, which the README notes needs operator inputs described in its runbook. Because it runs real Firecracker microVMs, self-hosting requires a host capable of Firecracker (Linux with KVM), and the your-own-keys model means you supply the credentials for whatever the machines and agents use, keeping them on your infrastructure.
The emphasis on self-hosting is deliberate and repeated: boringcomputers.com is a demo site, and you run the real thing yourself. That is the right framing for a tool whose whole value is isolated machines you control, since a hosted version would put the isolation boundary and the data on someone else's infrastructure.
The provisioning-from-a-signed-release approach, with a runbook for operator inputs, indicates this is meant to be run as real infrastructure rather than a toy, which matches the seriousness of running microVMs. The CI badge and the runbook suggest the operational path is documented rather than left to chance.
The limitations: real infrastructure to operate
The honest limitation is that Nehemiah is infrastructure, not an app. Running real Firecracker microVMs means you need a capable Linux host with KVM, and you are operating a system that provisions and destroys machines, which is more involved than installing a desktop tool. The self-hosted, your-own-keys design is a strength for control and privacy but a cost in operational effort: you run it, secure it and maintain it.
That also bounds who it is for. Someone who just wants a hosted sandbox to run an agent in will find Nehemiah heavier than a managed service, because the point is that you host it yourself. The demo site exists precisely because most people will want to see it before committing to running the real infrastructure.
Giving an AI a real, network-capable Linux machine is powerful and carries the responsibility that comes with it: even with microVM isolation and disposal, an agent with a full machine and your keys can take real actions, so the isolation boundary and the credentials you provide are the things to configure carefully. The README's disposable, self-destruct model and the microVM boundary are the mitigations, but operating it responsibly is on the person running it.
Against a container sandbox or a hosted agent VM service
The alternatives are a container-based code sandbox and a hosted agent-VM service. A container sandbox is lighter and easier to run but shares the host kernel, so its isolation is weaker than a microVM, which matters when an AI runs arbitrary code. A hosted service gives you agent VMs without operating anything, but the isolation and your data live on the provider's infrastructure, and you bring less control.
Nehemiah's difference is real microVM isolation, a full disposable machine per task, self-hosted with your own keys, so you get VM-grade boundaries and keep everything on infrastructure you control. The cost is that you operate real infrastructure needing a Firecracker-capable host. Choose a container sandbox when lighter isolation is acceptable and you want minimal setup. Choose a hosted service when you would rather not run infrastructure and accept the provider holding the boundary. Choose Nehemiah when you want to hand an AI a genuine, isolated, disposable Linux machine and keep the isolation and the keys on your own infrastructure, and you are willing to run it yourself.
Apache-2.0, self-hosted operation, and where to start
Nehemiah is Apache-2.0, which permits commercial use and derivatives with attribution and carries the patent grant, the right license for infrastructure teams will self-host and adapt. Combined with the your-own-keys, self-hosted model, that means the whole system, machines, isolation and credentials, stays under your control, which is the core value proposition.
Operating it is the maintenance reality: it provisions from signed releases with a runbook, so updates and operation follow that documented path, and running real microVMs means keeping a Firecracker-capable host healthy. The CI badge indicates the project verifies its builds.
The concrete first step is to look at the demo site to understand the experience, then set up a small self-hosted instance following the runbook: clone the repo, `npm install`, and provision one managed host from a signed release with the operator inputs the runbook specifies, on a Linux host with KVM. Hand a simple task to one microVM, watch it boot, do the work and self-destruct, and confirm the isolation and your-own-keys handling match your requirements before scaling it up, since the whole point is keeping the boundary and the credentials on infrastructure you control.
Editorial conclusion
Use Nehemiah if you want to hand an AI a genuine, isolated, disposable Linux machine, a real Firecracker microVM with a browser, terminal and coding agent that boots in milliseconds and self-destructs, kept on infrastructure you control with your own keys: the microVM isolation and the self-hosted model are its real strengths over a container sandbox or a hosted service. It is the wrong choice if you want a light, zero-infrastructure sandbox, since it runs real microVMs and you operate it on a Firecracker-capable Linux host. Start by viewing the demo site, then self-host a small instance per the runbook (git clone, npm install, provision one host from a signed release on a KVM Linux host), and confirm the isolation and your-own-keys handling before scaling up.
Frequently asked questions
What is each Nehemiah machine?
The README says each is a real Firecracker microVM, a full Linux machine with its own kernel, a browser, terminal and coding agent, that boots in milliseconds, does its work, and self-destructs when done or stays up as long as you want.
Is Nehemiah hosted or self-hosted?
Self-hosted. The README says it is open source and Apache-2.0, run with your own keys on your own infrastructure, and that boringcomputers.com is only a demo site; you run the real thing yourself, provisioning hosts from signed releases per the runbook.
Why does Nehemiah use Firecracker microVMs instead of containers?
Firecracker gives each machine its own kernel and hardware-level isolation while booting in milliseconds. For handing a full machine to an AI running arbitrary code, that VM-grade boundary is stronger than a container's shared kernel, and the fast boot makes disposable per-task machines practical.
Community notes