The case for persistent sandboxes in AI code execution

Arun Raghunath — Fri, 05 Jun 2026 09:56:53 +0000

Every AI coding tool generates code. None of them solve what happens next.

Cursor writes your Python. Claude Code refactors your script. Windsurf
ships your feature. But running that code safely, in isolation, with
audit trails, without exposing your secrets, is still an unsolved problem.

That's what Jhansi.io is built for.

The mistake we made in v0.1

Our first execution model was simple. Send code as a string, run it in
an isolated container, return the output.

POST /v1/sandboxes/{id}/exec
body: { "code": "print('hello world')" }

It worked. But it had three fundamental problems.

Problem	Why it breaks
Single file only	No multi-file projects, no shared modules, no dependencies. Not how production code works.
Full payload on every run	Even if nothing changed, you resent everything. Wasted bandwidth, added latency.
No foundation for delta sync	If you're sending everything every time, there's nothing to diff against.

The insight

A sandbox should be a workspace, not a disposable container.

Give every sandbox a dedicated folder on disk. Files live there between
runs. Execution just says "run this file" — no payload, no resend, no waste.

This is the architecture shift in Jhansi.io v0.2.

What changed

Workspace per sandbox. Every sandbox gets a dedicated folder on disk
at creation time. Zero config locally, overridable in production via
PETRI_WORKSPACE_ROOT.

File upload API. Upload once. Upload only when something changes.

POST /v1/sandboxes/{id}/files

Files land in the sandbox workspace and persist between runs.

Exec by filename. No code in the request body. Just a filename.

POST /v1/sandboxes/{id}/exec
body: { "filename": "main.py" }

Jhansi.io mounts the workspace into a fresh isolated container and runs
the named file. The container dies. The workspace survives.

The flow

# Create once
curl -X POST /v1/sandboxes -d '{"language": "python"}'

# Upload when files change
curl -X POST /v1/sandboxes/{id}/files -F "file=@main.py"

# Exec as many times as you need
curl -X POST /v1/sandboxes/{id}/exec -d '{"filename": "main.py"}'

What this unlocks

The persistent workspace is the foundation for everything coming next:

Delta sync — detect file changes, upload only diffs
Auto dependency detection — parse imports, install packages invisibly
Multi-file projects — real codebases, not toy scripts

If you're building AI agents that generate and run code, we want you in
our design partner program. Early access at jhansiio.featurebase.app

Jhansi.io — Build it. Run it. Ship it.

I got tired of running Docker manually. So I built a sandbox for AI-generated code.

Arun Raghunath — Thu, 04 Jun 2026 09:18:31 +0000

I've been on sabbatical for a few months. Writing code. Building projects.

And running Docker manually. Again. And again.

docker run. Check what's up. docker stop. Forget one. Find it next week eating RAM. Repeat.

At some point I asked: why is this still manual? Why can't containers just spin up, run, and die when they're done?

Then I threw AI into the mix.

Now I'm not just running my code. I'm running code a model wrote. Code I haven't audited line by line. Code that might have os.system(f'rm -rf {user_input}') because the model had a bad day.

That's a different problem.

The question nobody wants to answer

Cursor, Claude Code, Windsurf, Copilot. They all generate Python, Node, Go.

None of them answer: where does that code actually run?

Best case: you paste it into your terminal and hope.

Worst case: you're piping untrusted eval() with access to your .env file, your AWS creds, and your customer database.

In a startup that's risky.

In fintech that's an FCA fine and a conversation with Legal you do not want to have.

I spent 18 years in banking. I watched teams ban AI coding tools outright because nobody could answer: "Where does the generated code run, and what can it touch?"

So I decided to build the answer.

What ships today: Petri

jhansi.io starts with Petri, the execution engine. It's live right now.

What it does:

Spins up an isolated Docker container per request
Runs Python, Node, or Go code
Returns stdout/stderr
Tears down the container. Zero state left behind.

The API:

POST /v1/sandboxes → Create sandbox, get sb_
POST /v1/sandboxes/{id}/exec → Run code, get output
DELETE /v1/sandboxes/{id} → Destroy it. Gone.

No Docker CLI. No Compose files. No "wait, is sad_fermat still running from Tuesday?"

Petri answers "where does code run". That's it. It does not touch secrets. It does not produce compliance audit logs.

Why existing tools don't cut it

E2B, Modal, Daytona are great tools. I use them. But they're SaaS only.

	E2B / Modal / Daytona	jhansi.io with Petri
Hosting	Public cloud only	Self-hosted or managed SaaS
Data residency	Your code runs on their infra	Runs in your VPC
Execution model	Stateful VMs in many cases	Ephemeral container per run
Who can use it	Startups	Startups, banks, anyone with a regulator

If you're a bank, you cannot send customer PII to a third party to execute. You need to self-host. You need control.

Petri gives you that. But execution is only 30% of the problem.

The roadmap: What I'm building next

Petri solves "where does it run". It doesn't solve "what can it touch" or "prove it to compliance".

That's why I'm building TenantVault and the Audit Layer.

TenantVault: Secrets injection where your AI agent can use a database password to run a query, but it can't read the password, print it, or exfiltrate it.

Audit Layer: Full execution traces. What ran, what files it touched, what network calls it made. Stream it to your SIEM.

I'm building those because 18 years in banking taught me you can't deploy AI codegen without them. "It ran in Docker" isn't enough when the FCA asks questions.

Full roadmap with ETAs: jhansi.io/roadmap

No vaporware. If it's not on the roadmap with a target date, we're not building it yet.

Where things stand

Petri is running. Python, Node, Go support. REST API. Sub-second cold starts.

Next up is the SDK so you can do this:


python
from jhansi import Sandbox

with Sandbox(language="python") as sb:
    result = sb.exec("print('hello from isolation')")
    print(result.output)

No SDK to share yet. I'm building in public because I want feedback before I lock the API. Especially from teams in fintech, healthtech, or anywhere "oops, it leaked" isn't an option.

## Follow along

I'll post technical deep-dives here and on GitHub as I ship:

1. Python + TypeScript SDKs
2. Self-hosted Docker Compose setup
3. TenantVault and audit streaming

**Jhansi.io — Build it. Run it. Ship it.**  
Because "where does this code run?" shouldn't be a rhetorical question anymore.

---

*Building in public. Star the repo on [GitHub](https://github.com/jhansi-io/jhansi or check the roadmap at [jhansi.io/roadmap](https://jhansi.io/roadmap). Questions? Drop them below.*

DEV Community: Arun Raghunath