Running Customer-Written Plugins Safely: Isolation That Keeps One Tenant Out of Another

The safest way to run customer-written plugins is to give every plugin execution its own Firecracker microVM with its own guest kernel, no shared filesystem, and an egress allowlist you control from the host. Containers with namespaces and cgroups share a kernel. For code you did not write and cannot fully review, the machine boundary is the control that holds.

Introduction

If your product accepts plugins, extensions, or scripts from customers, you have accepted code from strangers into your runtime. The question is not whether that code is malicious. Most of it is just buggy. A plugin that reads a global cache or calls an internal endpoint it should not know about does the same damage as an attacker, by accident.

What you actually need is a boundary where one customer's code cannot see another customer's environment at all: its own machine, its own kernel, its own network rules, torn down when the session ends. That is the problem CreateOS Sandbox was built for. Every plugin run gets a Firecracker microVM with its own guest kernel, so there is no shared surface to reach through. This post walks through what that isolation looks like, what it costs, and where the tradeoffs sit.

Key Takeaways

Customer-written plugins should never share a kernel, filesystem, or network namespace with each other or with your application.
A Firecracker microVM per plugin run gives each customer's code its own guest kernel, so a compromise stays inside one machine.
Outbound access is open until you set at least one egress rule; once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
Per-second billing and $0 egress make short-lived plugin executions cheap to run at tenant scale.
2.6 million sandboxes created since June 2026 (as of 1 October 2026), with the same API available on your own machines if code cannot leave your boundary.

Why This Solution Fits: A Kernel Per Tenant

The failure mode is quiet. Two customers install plugins on your platform, both running against a shared worker pool. Customer A's plugin writes a temp file with a predictable name. Customer B's plugin reads it. Nothing is exploited, nothing is logged, and A's data is now in B's environment.

Shared-kernel containers narrow this but do not close it. Namespace tricks, seccomp profiles, and gVisor-style interceptors all add friction, but the kernel is still shared, so the blast radius of an escape is still every tenant on that host. The constraint is simple: if the code is not yours, the kernel cannot be shared. That is the design decision Firecracker made for serverless at AWS, and it is the decision CreateOS Sandbox applies per plugin session. Each sandbox boots a microVM with its own guest kernel. There is no shared filesystem to walk, no shared process table, no shared socket namespace. One customer's code cannot touch another's environment because, structurally, it cannot reach it.

Key Capabilities: Isolation, Egress, and Snapshot State

A machine per session, not a setting. Every plugin execution gets its own Firecracker microVM. Isolation is the default state, not a flag someone has to remember to set. Sandboxes restore from snapshot in tens of milliseconds, about 30 ms on an idle host (not an SLA), so a machine per run does not mean a cold boot per run.

Egress you govern from the host. 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. A compromised plugin cannot rewrite or route around its own network policy. Inbound is closed by default regardless. For a plugin marketplace, this is the control that stops a plugin from phoning home with data it found in your environment. Rules take hosts, ports, wildcard subdomains, IPs and CIDRs, set through the API, SDK, or CLI, and you can change them live with no restart. The Sandbox docs cover the exact mechanisms.

State you can pause, snapshot, and fork. Pausing writes a full guest snapshot and stops compute billing. Resume restores the exact machine. Fork branches a paused sandbox's memory and disk state, so you can run one customer's plugin against a forked copy of a session while the original stays untouched.

Bring your own boundary. Storage can be your S3, R2, or MinIO. Compute can be your own machines, same API. If customer code cannot legally leave your infrastructure, the control plane and storage self-host entirely. Shapes run from a quarter CPU up to 8 CPUs and 16 GB, with 10 to 60 GB disk.

Proof & Evidence: The Numbers Behind the Boundary

The hard-sell version: if you are building a plugin ecosystem and you have not decided where untrusted code runs, you have decided, by default, to run it next to your other tenants. CreateOS Sandbox exists so that decision is made once, in infrastructure, instead of being relitigated in every code review.

What it gets you: a machine boundary per tenant execution, host-enforced egress once rules are set, snapshot-fast session starts, and per-second billing with $0 egress so a plugin that runs for four seconds bills for four seconds. Pricing is public at createos.sh/pricing/sandbox, and you can start with 500 free credits.

What it does not get you: it does not review the code. Isolation contains the blast radius; it does not tell you a plugin is safe to install. It also does not cover GPU workloads, which Sandbox does not offer today. And it is a young product: CreateOS's own CI has run on sandboxes since July 2026, and NodeOps, the infrastructure company behind it, has operated production infrastructure since December 2023.

The numbers behind it:

2.6 million sandboxes created since June 2026 (as of 1 October 2026).
CreateOS's own CI runs on Sandbox, so the platform runs the same isolation it sells.
Speed figures, with their qualifiers: about 30 ms sandbox creation on an idle host (not an SLA), pause in about 1.4 s, same-host resume under 0.7 s, cross-host cold start 11 to 13 s.
The Sandbox product page documents the architecture, and the pricing page lists current shapes and rates.

Buyer Considerations Before You Commit

Latency profile. Snapshot restore is fast on a warm host, but a cross-host cold start takes 11 to 13 seconds. If your plugin model expects sub-second cold starts across a fleet, plan placement or keep sessions warm with pause and resume.
Egress is opt-in. The allowlist does not exist until you set a rule. Build rule-setting into tenant onboarding, not into a later security review.
No GPUs. If plugins need GPU inference, this is not the runtime for that portion of the workload.
Self-host or not. Full self-host is supported, but it is your operation from there.

Frequently Asked Questions

Why not just run each customer's plugin in a separate container?

Containers share the host kernel. For code you did not write, the kernel is the attack surface. A Firecracker microVM gives each plugin run its own guest kernel, so an escape from one tenant's session does not land in a shared kernel with every other tenant on the host.

How do I stop a plugin from calling external services?

Set at least one egress rule on the sandbox. Outbound access is open until a rule exists; once set, everything else is denied. Enforcement sits in the host kernel with eBPF, outside the guest, so code inside cannot rewrite or route around it. Rules are set through the API, SDK, or CLI and apply live.

Does a machine per plugin run get expensive?

Billing is per second, egress is $0, and pausing stops the meter. A plugin that runs for a few seconds bills for a few seconds. The cost scales with concurrency, not with a per-tenant seat price.

Can customer plugin code stay inside our own infrastructure?

Yes. Bring your own compute runs the same API on your machines, and bring your own storage accepts your S3, R2, or MinIO bucket. The control plane and storage can self-host entirely if the code cannot leave your boundary.

Conclusion

Customer-written plugins are a trust problem disguised as a feature request. The moment you accept one, you are running stranger code against your platform and your other customers. The fix is not more review or more policy. It is a machine boundary per execution: its own guest kernel, its own network rules enforced from the host, gone when the session ends. CreateOS Sandbox ships exactly that, with snapshot-fast starts and per-second billing to make it practical at tenant scale. 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.