← Back to list

Running Code Safely: A Practical Look at Daytona, E2B, and Python Sandbox Execution

There’s a moment that eventually hits anyone building developer tools or AI-driven assistants: “How do I run user‑submitted code without…

Yash Jain in AlgoMart · 2025-12-03 04:32 · 50 claps · 4.3 min read paywalled
#e2b #sandbox #daytona #python #docker
Open on Medium ↗
Wiki topics: AI · AI · General ☁️ · DevOps & Cloud 🏃 · Running & Endurance

Running Code Safely: A Practical Look at Daytona, E2B, and Python Sandbox Execution

Blog Thumbnail

Blog Thumbnail

There’s a moment that eventually hits anyone building developer tools or AI-driven assistants: “How do I run user‑submitted code without burning my entire machine down?”

It doesn’t matter whether that code comes from a student learning Python, an AI model generating snippets, or a real user exploring your feature. Executing code directly inside your backend is a shortcut to becoming a cautionary tale on Hacker News.

That’s where platforms like Daytona and E2B come in. Both give you isolated, disposable environments you can spin up quickly. But they solve the problem in slightly different ways, and depending on what you’re building, you may end up using one or even both.

This post breaks down what these tools are, why you might want them, and a simple way to hook them into your Python workflows.

What Daytona Is

Daytona

Daytona

Daytona is basically “developer workspaces — but scripted, reproducible, and cloud-based.”

If you’ve used GitHub Codespaces, the vibe is similar, but Daytona is:

  • vendor‑agnostic
  • self-hostable
  • focused on reproducible workspace environments

Where it gets interesting for us is this: Daytona lets you spin up containerized development environments programmatically.

Each environment is:

  • isolated
  • temporary
  • consistent
  • capable of running real-world code safely

This makes it a great fit for testing generated code, onboarding developers, or running teaching environments.

What E2B Does

E2B

E2B

E2B solves a slightly different problem: ephemeral sandboxes optimized for running AI‑generated or untrusted code.

Think of it as:

  • super lightweight
  • boot instantly
  • kill instantly
  • safe to hand to an AI agent
  • safe to hand to a random user

Where Daytona tries to feel like a full workspace, E2B tries to feel like a tiny disposable VM whose only job is:

“Run this code. Don’t trust it. Don’t let it escape.”

If you’re building an AI coding assistant, or letting users run code on your platform, E2B is one of the cleanest options available.

When To Use Which

Daytona feels better when you want:

  • a developer environment
  • multi-step workflows
  • debugging or exploration
  • live editing + execution
  • containerized environments tied to repos

E2B shines when you want:

  • fast execution
  • no state
  • ephemeral sandboxes
  • AI agent integration
  • completely untrusted input

If your app needs both workspaces and execution environments, these tools can actually complement each other instead of competing.

Integrating E2B Into Python (Simple Sandbox Example)

E2B exposes a Python client. The flow is usually:

  1. Create a sandbox
  2. Send Python code to execute
  3. Get back stdout, stderr, and results
  4. Destroy sandbox or reuse briefly

Here’s a minimal example:

from e2b import Sandbox

# Create isolated environment
sandbox = Sandbox()

# Run arbitrary Python code
result = sandbox.run_python("""
import math
x = math.sqrt(144)
print("Result:", x)
""")

print("Output:", result.output)
print("Errors:", result.error)

# Clean up when done
sandbox.close()

What I like most about this is that the sandbox spins up fast. Even for tiny tasks, the overhead stays low enough that you can use it inside a live LLM toolchain.

Integrating Daytona Into Python (Launch a Workspace and Execute Code)

Daytona doesn’t “run code” out of the box the way E2B does. What it does give you is a programmatically reproducible workspace, which you can then execute commands inside via SSH or its API.

Here’s a lightweight integration flow using the Daytona CLI from Python:

import subprocess
import json
import time

# Start a Daytona workspace (ensure `daytona` CLI is installed locally)
workspace_name = "my-python-sandbox"
subprocess.run(["daytona", "up", workspace_name])

# Wait for workspace to initialize
time.sleep(5)

# Run a command inside the workspace
cmd = ["daytona", "exec", workspace_name, "--", "python3", "-c", "print(40+2)"]

result = subprocess.run(cmd, capture_output=True, text=True)

print("Workspace output:", result.stdout)

This relies on the Daytona CLI but can be wrapped in any Python backend — Flask, FastAPI, Django, or an AI agent system.

For more structured patterns, Daytona also exposes “workspace templates” that define environments. If your project needs the exact same dependencies each time, you define them once and recreate environments effortlessly.

Combining Daytona + E2B In Real Systems

Here’s a pattern I’ve actually seen in production AI tooling:

  • Daytona provides persistent workspace environments for development
  • E2B handles the dangerous “run this user code” task
  • Your backend routes requests to the correct system based on trust level

For example:

  • If a paying customer wants a full coding workspace → Daytona
  • If your AI wants to validate a code snippet → E2B
  • If a user is experimenting with small code → E2B
  • If you want to give the user a multi-file environment → Daytona

You don’t have to choose between them. They solve different tiers of the “don’t break my server” problem.

Real-World Examples of When These Shine

AI coding assistants

Agents generate code → sandbox executes safely → results return to agent.

Educational platforms

Students get isolated environments → no machine setup needed.

SaaS developer tools

Onboard new engineers with Daytona → run arbitrary snippets with E2B.

Security-conscious applications

Sandboxing is non-negotiable when handling unknown code. You don’t want Python’s eval() anywhere near your real server.

Final Thoughts

If you’re building anything that involves code execution — whether for AI tools, developer platforms, or interactive learning — sandboxing isn’t optional anymore. Daytona and E2B are two of the strongest tools for this job, each covering different corners of the problem space.

E2B gives you a clean, disposable execution bubble. Daytona gives you a reproducible, full-blown workspace. Together, they solve problems that used to require painful custom infrastructure.

Thanks a lot for reading this.

I always enjoy hearing what people think, so if something here stood out to you or you just want to share your thoughts, drop a comment. I’m always around to chat.

If you want to stay in touch or see more of what I’m doing, you can find me here:

Let’s keep learning, creating, messing up, fixing things, and growing together.


메타데이터
post_id
f55d2cbb094a
slug
running-code-safely-a-practical-look-at-daytona-e2b-and-python-sandbox-execution-f55d2cbb094a
url
https://medium.com/algomart/running-code-safely-a-practical-look-at-daytona-e2b-and-python-sandbox-execution-f55d2cbb094a
canonical_url
https://medium.com/algomart/running-code-safely-a-practical-look-at-daytona-e2b-and-python-sandbox-execution-f55d2cbb094a
author_url
https://medium.com/@yashjainio
status
ok
fetched_at
2026-07-11 06:37:13