Sandboxes & Infrastructure
Sandbox specs, shared volumes, lifecycle hooks, concurrent users, and persistent storage.
What are the sandbox hardware specs?
Default sandboxes run with up to 8 CPU and 8 GB RAM. For higher specs, contact support for a custom plan through E2B. Each sandbox runs Node 24 with git, curl, ripgrep, and GitHub CLI pre-installed.
What happens when two users write in the same chat?
Last user wins. Each API call spawns a separate Claude process. If two users send messages to the same thread at the same time, both will receive their own responses, but Claude's internal conversation file will only retain the history from whichever request finishes last.
For most applications this isn't an issue. If you need to handle concurrent users, use separate threads within the same sandbox — each thread has its own conversation history while sharing the same files and environment.
Can I share files between sandboxes?
E2B supports shared volumes backed by S3. This lets you mount a shared folder across multiple sandboxes — useful for shared skills, media libraries, or team assets. An alternative approach is to reuse a single sandbox with multiple threads instead of spinning up separate sandboxes per user.
You can also build a custom solution using a tool that uploads/downloads from S3 or Supabase Storage, giving the agent access to shared assets without needing a FUSE mount.
One sandbox with multiple threads vs. multiple sandboxes?
One sandbox, multiple threads — all users share the same filesystem and environment. Good when you want shared state (files, databases, running services). Use different threads to keep conversation histories separate.
Multiple sandboxes — fully isolated environments. Good when users do heavy compute (e.g. video rendering) and you don't want them competing for resources. Use shared volumes if you need common files across sandboxes.
Are there sandbox lifecycle hooks (onResume / onPause)?
Lifecycle hooks for sandbox pause/resume are on the roadmap. In the meantime, you can use startup scripts in your agent's template/ directory to run initialization logic (e.g. starting a file server) when the sandbox starts.
What happens when a sandbox times out?
Idle sandboxes are destroyed after a timeout period. The next message automatically creates a new sandbox. The agent URL stays the same. If you need to persist data across sandbox restarts, use environment variables, external storage, or shared volumes.