New Python SDK simplifies secure code execution on jhansi.io

Last month, running code on jhansi.io meant juggling sandbox IDs, manual cleanup, and curl commands. Now it’s as simple as installing a package and writing a short script. The new Python SDK, live today, wraps the platform’s secure execution engine behind clean Python APIs and automatic resource management.

A cleaner path to isolated code execution

jhansi.io has always let users run code inside isolated Docker containers through its HTTP API. But until now, developers had to handle HTTP calls, container lifecycle management, and manual cleanup—or risk leaking resources. The newly released SDK removes that complexity. A few lines of Python now replace the old workflow:

from jhansi import Sandbox

with Sandbox(language="python") as sb:
    sb.upload_file("main.py")
    result = sb.exec("python main.py")
    print(result["output"])

The SDK manages sandbox creation, file uploads, execution, and cleanup automatically. No manual intervention required.

Why context managers prevent cloud leaks

When AI agents or scripts create sandboxes programmatically, forgetting to delete them can lead to lingering containers and wasted storage. The SDK’s context manager solves this by guaranteeing cleanup, even if an error occurs during execution:

with Sandbox(language="python") as sb:
    # sandbox created here
    sb.upload_file("main.py")
    result = sb.exec("python main.py")
    # sandbox deleted here — even if exec raises an exception

This pattern eliminates manual cleanup steps and removes a common source of cloud waste.

Docker-in-Docker solved with shared volumes

Self-hosting the execution engine, Petri, revealed an unexpected challenge: Petri itself runs inside Docker, but it needs to spawn additional Docker containers to execute user code. This created a Docker-in-Docker problem that required two fixes.

First, the Docker socket had to be mounted into Petri’s container so it could manage other containers:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock

Second, Petri’s workspace folders had to be accessible to both the host and the spawned sandboxes. Simply mounting a workspace path wasn’t enough—Docker looks for paths on the host, not inside Petri’s container. The solution was to share the same path on both sides:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock
  - /tmp/petri-workspaces:/tmp/petri-workspaces
environment:
  - PETRI_WORKSPACE_ROOT=/tmp/petri-workspaces

Now Petri can create workspace folders inside its container and mount them into sandbox containers reliably.

Getting started in minutes

To run the execution engine locally or deploy it to a server, follow these steps:

• Clone the repository

git clone 
cd petri
docker compose up

• Install the SDK

pip install jhansi

The full documentation is available at docs.jhansi.io for API reference, examples, and advanced configurations.

What’s coming next

The team has outlined three major milestones for the platform:

• v0.6 — A persistent registry to keep sandboxes alive even after Petri restarts
• v0.7 — Streaming execution for real-time output as code runs
• MCP server integration — Directly connect Petri to Cursor and Claude Code, letting these tools use jhansi.io instead of their own cloud execution services

The MCP server integration stands out as the most anticipated update, promising tighter integration with popular AI coding assistants.

To stay updated on the project’s progress, star the repository on GitHub.

The SDK’s arrival marks a turning point for developers who need secure, isolated code execution without the operational overhead. As AI-driven development accelerates, tools like jhansi.io make it easier to build, test, and deploy code at scale—without compromising safety or simplicity.