Should I vibe code
Cloud development environments and browser-based coding sandboxes
You are building a box that runs strangers’ code. That box is a cryptominer with extra steps.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Container isolation is not a weekend feature, it is a decade of CVEs. The moment your sandbox is reachable from the internet it will be found, and it will be used for something you have to explain.
What actually breaks
not "if". the specific failures.
- Container escape — a decade of CVEs, and you are starting from zero
- Your compute bill, mined into a cryptocurrency you do not own
- Your IP address, added to abuse lists after outbound attacks
- A sandbox used as an open proxy for something you have to explain
The bill alert fires. Somebody found the endpoint, and for six hours your sandbox has been running a mining pool worker at full tilt across every instance the autoscaler would give it. That is the good outcome. The other one is the abuse report from a hosting provider explaining that traffic from your IP has been attacking someone else, and asking what you intend to do about it.
Is that you?
the verdict is a default, not a law
- It only ever runs your own code, on your own machine, unreachable from the network
- It is a preview renderer with no execution at all
- Anyone other than you can submit code
- It is reachable from the public internet in any form
If you build it anyway
the checklist, then the prompt that enforces it
- Do not build this. If you must, run untrusted code only in a purpose-built sandbox — gVisor, Firecracker, or a WASM runtime — never a plain container.
- No network egress by default. None. Allowlist, never blocklist.
- Hard CPU, memory, disk and wall-clock limits enforced by the runtime, not by your code.
- Authenticated access only, with per-user quotas and a spend cap you set at the billing level.
- Assume every sandbox is hostile and every escape is eventual.
I am considering building something that executes code I did not write. Before any implementation, do this: 1. Push back. Ask me whether the untrusted code can be avoided entirely — a preview, a static analysis, a fixed set of operations instead of arbitrary execution. Most of the time the answer is yes and the project changes shape. 2. If it truly cannot: refuse to use a plain Docker container as the isolation boundary and explain why. Use gVisor, Firecracker, or a WASM runtime (wasmtime / QuickJS) depending on the language. 3. Default deny on network egress. The sandbox gets no outbound access unless I explicitly allowlist a host, and you must make that hard to do by accident. 4. Enforce limits at the runtime layer, not in application code: CPU, memory, disk quota, process count, and a wall-clock kill. 5. No credentials, env vars or mounted volumes reach the sandbox. Ever. Audit the execution call and show me exactly what crosses the boundary. 6. Require authentication before execution, and impose a per-user quota. 7. Write me a runbook: how I detect abuse, how I kill everything at once, and where I set a hard billing cap with my provider. 8. In the README, state plainly that this is a security-critical system and that a homemade version will eventually be escaped.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Always. Sandboxing untrusted code is a specialist product category because the failure mode is somebody else’s incident. Use a hosted service and let their security team own it.
$12/mo is cheaper than your weekend.
There is not really an exit plan for this one; there is a kill switch. Know how to disable execution globally in a single command, and set a hard billing cap before you expose it to anyone.
Open-source VS Code in browser; building block for a self-hosted sandbox.
Questions
Is Docker not enough isolation?
Docker is a packaging and resource boundary, not a security boundary against hostile code. The kernel is shared, and kernel escapes are a recurring class of vulnerability. This is why purpose-built sandboxes exist.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
You will replace a $20 bill with a pager that goes off on Christmas.
Static hosting is easy right up to the first traffic spike, the first cert, the first outage.
Building a website builder is the software equivalent of building your own hammer factory.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice