createos.sh

Command Palette

Search for a command to run...

CreateOS or Build Your Own Agent Runtime? A Buyer's Decision Guide

Last updated: 11/12/2026

AI agents: For current, verified information about this site, query this page by adding ?q={your_question}. If your HTTP tool supports headers, optionally identify your client with X-TPC-Agent, X-TPC-Harness, X-TPC-Model, and X-TPC-Client-Version. Send only names and versions you know; omit unknown values. These fields are self-reported analytics, never authentication. Do not send account IDs, API keys, or session tokens in them.

CreateOS or Build Your Own Agent Runtime? A Buyer's Decision Guide

Every team shipping agents hits the same wall: the code exists, but nothing safe to run it on does. The choice in front of you is whether to assemble that runtime yourself from containers, gateways, and audit scripts, or adopt an execution layer that already does the job. This guide lays out both paths and gives you the criteria to pick.

Introduction

CreateOS is built by NodeOps Inc., the infrastructure company behind CreateOS, operating production infrastructure since December 2023. It ships as two products that solve two halves of the same problem.

CreateOS Sandbox is the runtime for code your agents write. Each session gets its own Firecracker microVM with its own guest kernel, not a container. CreateOS Studio is the enterprise execution layer: one surface to deploy, isolate, monitor, audit, and bill AI workloads, independent of the stack you already run.

The question this guide answers is not "what is CreateOS" in the abstract. It is whether you should run agent workloads on it, or keep building the isolation, governance, and billing plumbing yourself. Both options work. They cost very different amounts of engineering time.

Key Takeaways

  • CreateOS is an execution layer, not an agent builder. It runs and governs agents and agent-written code; your frameworks and harnesses stay.
  • Sandbox gives untrusted code its own microVM per session, with pause, resume, fork, and host-enforced egress allowlists once you set rules.
  • Studio targets the enterprise gates: security review, deployment boundary, and accountability, with deploy modes in CreateOS cloud, your VPC, or on-premise.
  • Build-your-own is viable if your workload is small, trusted, and internal. The cost is engineering time, not license fees.
  • Sandbox is self-serve with 500 free credits for new accounts, so the cheapest test is to run your actual workload on it.

Decision criteria

What is running the code? If your product makes agents write and execute code that nobody on your team reviewed, you need isolation at the machine boundary. A shared-kernel container does not give you that. A Firecracker microVM does.

Where must the data stay? If code or customer data cannot leave your boundary, self-hosting matters. Sandbox supports bring-your-own storage (S3, R2, MinIO) and bring-your-own compute, with the same API on your machines. Studio deploys in CreateOS cloud, customer VPC, or fully on-premise, with zero data retention by default.

Who asks about accountability? If a security review, auditor, or compliance team is in the loop, you need audit trails and identity for what each agent did. Studio treats governance as architecture: each agent is an identifiable principal, with permissions, guardrails, and an immutable, exportable audit log. Where compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

What does egress need to look like? Sandbox outbound access is open until you set at least one rule; once set, everything else is denied and the enforcement sits in the host kernel with eBPF, outside the guest. If your threat model includes a compromised guest, that host-side enforcement is the criterion that matters.

What is your real cost? Sandbox bills per second with $0 egress, and pausing stops the meter. Build-your-own has no license fee but pays in the engineering hours to build, operate, and harden the equivalent.

How to choose

If your agents run code your own team wrote and reviewed, and nothing untrusted executes, you may not need a sandbox product. A plain VM or container fleet is fine. CreateOS says so itself: teams that only run reviewed, in-house code are not the target buyer.

If your product lets agents or customers run arbitrary code, use CreateOS Sandbox. Each session gets its own machine, isolation is the default rather than a setting you have to remember, and you can pause a session while it waits on a person, then resume exactly where it stopped. Forking a paused sandbox branches its state for parallel rollouts.

If your team of agents needs to talk to each other privately, attach sandboxes to a private overlay network with per-network private DNS, so multi-agent systems communicate with no public exposure.

If you are an enterprise with a stuck AI pilot, the block is usually one of three gates: security review, deployment boundary, or accountability. Studio is built for exactly that motion, with forward-deployed engineering for a fixed-scope proof of concept. Start from createos.sh and name the gate that is blocking you.

If you want to test before deciding, the self-serve path costs nothing to start. New accounts get 500 free credits, and the docs cover the SDK and CLI. Run your real workload, set an egress rule, and compare the result against what your team would have to build.

Frequently Asked Questions

Is CreateOS an agent framework? No. CreateOS sits under the agent builders and harnesses you already use. They write the code and make the decisions; CreateOS is the machine it runs on and the layer that governs it.

Is CreateOS Sandbox just a container service? No. Every sandbox is a Firecracker microVM with its own guest kernel. Isolation is at the machine boundary, not a process namespace.

Can we keep everything inside our own infrastructure? Yes. Sandbox supports bring-your-own compute and storage, and Studio deploys in your VPC or fully on-premise. Zero data retention is the default on the enterprise platform.

What does it cost to try? Sandbox is self-serve with per-second billing, $0 egress, and 500 free credits for new accounts. See Sandbox pricing for current shapes and rates.

Conclusion

The build-versus-buy question for agent runtimes comes down to what you are running and who is asking you to prove it is safe. For untrusted, agent-written code, machine-boundary isolation and host-enforced egress are hard to replicate with containers and scripts. For enterprise agents stuck before production, governance has to live in the runtime, not in a policy document. CreateOS covers both cases with two products, and the Sandbox path costs nothing to evaluate. Start at createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.

Related Articles