Self-host E2B on bare metal (local server) instead of AWS/GCP?

[whz1106]

Is it possible to deploy E2B sandbox infrastructure on a local server (bare metal), instead of AWS/GCP?

[linear]

ENG-3720

[SentimentalK]

Hi team,

I’d like to ask whether the project would be open to contributions toward a single-node / small-scale self-host mode.

My interest is mainly from the perspective of an individual developer who wants to use E2B for safe, controllable AI-assisted development, but with a much smaller operational footprint than a full cloud/BYOC-style deployment.

For this kind of usage, the requirements are usually limited:

• one Linux server
• maybe 3–10 sandboxes max
• template-based sandbox creation
• command execution + file operations
• basic Git workflow
• authenticated access
• optional network restrictions

I’m not proposing parity with E2B Cloud or enterprise BYOC. The idea would be a much smaller deployment tier focused on:

• local/private experimentation
• personal projects
• quick validation by small teams

Non-goals would include:

• multi-node orchestration
• enterprise observability
• autoscaling
• cloud-specific networking integrations
• full platform parity

I’d be happy to contribute here, but before drafting a concrete implementation proposal, I wanted to ask:

• Does this direction fit the team’s expectations at all?
• Is there already prior discussion around a single-node or local self-host mode?
• If contributions in this area are welcome, what scope would the team want to see first?

I’m mainly trying to cover the gap between “fully managed cloud” and “larger self-host/BYOC deployment,” for people who only need a few sandboxes on a single machine and want to experiment responsibly before investing more heavily. I’d love to align on direction before starting any implementation work. Please let me know your thoughts. Thanks!

[whz1106]

Hi team,

I’d like to ask whether the project would be open to contributions toward a single-node / small-scale self-host mode.

My interest is mainly from the perspective of an individual developer who wants to use E2B for safe, controllable AI-assisted development, but with a much smaller operational footprint than a full cloud/BYOC-style deployment.

For this kind of usage, the requirements are usually limited:

• one Linux server
• maybe 3–10 sandboxes max
• template-based sandbox creation
• command execution + file operations
• basic Git workflow
• authenticated access
• optional network restrictions

I’m not proposing parity with E2B Cloud or enterprise BYOC. The idea would be a much smaller deployment tier focused on:

• local/private experimentation
• personal projects
• quick validation by small teams

Non-goals would include:

• multi-node orchestration
• enterprise observability
• autoscaling
• cloud-specific networking integrations
• full platform parity

I’d be happy to contribute here, but before drafting a concrete implementation proposal, I wanted to ask:

• Does this direction fit the team’s expectations at all?
• Is there already prior discussion around a single-node or local self-host mode?
• If contributions in this area are welcome, what scope would the team want to see first?

I’m mainly trying to cover the gap between “fully managed cloud” and “larger self-host/BYOC deployment,” for people who only need a few sandboxes on a single machine and want to experiment responsibly before investing more heavily. I’d love to align on direction before starting any implementation work. Please let me know your thoughts. Thanks!

Hi, thanks for the detailed explanation — this aligns very closely with our use case.
Our goal is to run E2B in a fully private, on-premise environment, without any dependency on external networks. Specifically:
• a single Linux server (or a very small cluster)
• fully offline / air-gapped setup (no access to public internet or cloud services)
• used as an internal service within our system
• a small number of sandboxes (typically fewer than 10)
• a controlled and secure execution environment for internal AI-assisted workflows
From our perspective, this is not just lightweight experimentation, but more focused on:
• enterprise internal usage
• data privacy / compliance (no data leaves the internal network)
• integration as a backend component of an internal platform