Self-Hosting E2B on On-Premise / Amazon Web Services

[G2G-7239]

Requesting official support and documentation for self-hosting E2B environments/agents on private infrastructure. This is critical for:

Data Privacy/Security: Maintaining sensitive data on-premise.

Customization & Control: Tailoring environments and resources.

Offline/Restricted Use: Operating in isolated networks.

Cost Optimization: Potential savings for high usage.

Integration: Seamlessly connecting with existing internal systems.

Proposed Solutions:
Docker-based Self-Hosting: Provide Dockerfiles and Compose configurations with instructions for building, running, configuring persistent storage, networking, and scaling.

General Linux Machine Setup: Offer detailed installation and configuration guides for direct deployment on Linux servers, covering dependencies and best practices.

Local API Interface: Clarify how a self-hosted instance would expose its API for local development and integration.

Use Cases:
Teams requiring data sovereignty.

Developers needing local, isolated E2B environments.

Organizations leveraging existing on-premise compute.

Additional Context:
Any existing plans or timelines for this feature would be valuable. Thank you for your consideration.

[linear]

E2B-2676 Feature Request: Self-Hosting E2B (Docker/Linux)

[mhykes]

I'm very interested in this feature. I'm willing to collaborate with whoever wants to take the lead. I'll happily test and provide feedback.

[sitole]

Hi, we are working on making E2B less dependent on Google Cloud, which has historically been our main deployment option. Currently, the main components (API, client proxy, template manager, and orchestrator) are all ready to be deployed on a general-purpose Linux machine without the use of any public cloud provider. Just keep in mind that orchestrator instances need to use the Linux KVM module, so Docker hosting is not enough, and the underlying machine (virtual or bare metal) needs to support (nested) virtualization.

We would be happy if someone from the community wants to help with documenting self self-hosting option. Besides running and spawning services for self-hosting, there are a few key parts that we have not resolved, because we are not using E2B on-premises. Mainly, I'm talking about self-managing network security (to restrict access from sandboxes to the local cluster network), load balancing.

Happy to help with writing docs for self-hoting here!

[mhykes]

What is the minimal suggested hardware configuration for testing self-hosting? Not for general use, just for POC.

[sitole]

What is the minimal suggested hardware configuration for testing self-hosting? Not for general use, just for POC.

We don't have hardcoded minimal suggestions, but 50 GB disk space, a minimum of 8 GB, and 4 CPU cores should be okay. Theoretically, we should run on a newer AMD64 processor with enabled virtualization, but not guaranteed. For testing, we are using an Intel Skylake platform (but this should not matter, just make sure the template is built on the same machine platform that will run the sandbox itself).

[midorifizz]

Hi, we are working on making E2B less dependent on Google Cloud, which has historically been our main deployment option. Currently, the main components (API, client proxy, template manager, and orchestrator) are all ready to be deployed on a general-purpose Linux machine without the use of any public cloud provider. Just keep in mind that orchestrator instances need to use the Linux KVM module, so Docker hosting is not enough, and the underlying machine (virtual or bare metal) needs to support (nested) virtualization.

We would be happy if someone from the community wants to help with documenting self self-hosting option. Besides running and spawning services for self-hosting, there are a few key parts that we have not resolved, because we are not using E2B on-premises. Mainly, I'm talking about self-managing network security (to restrict access from sandboxes to the local cluster network), load balancing.

Happy to help with writing docs for self-hoting here!

Hi, thanks for considering this feature!

I’d like to ask if there’s a specific branch where the self-hosting related work is being developed?
I’d love to look into the code and possibly contribute.

Thanks!

[sitole]

Hi, we are working on making E2B less dependent on Google Cloud, which has historically been our main deployment option. Currently, the main components (API, client proxy, template manager, and orchestrator) are all ready to be deployed on a general-purpose Linux machine without the use of any public cloud provider. Just keep in mind that orchestrator instances need to use the Linux KVM module, so Docker hosting is not enough, and the underlying machine (virtual or bare metal) needs to support (nested) virtualization.
We would be happy if someone from the community wants to help with documenting self self-hosting option. Besides running and spawning services for self-hosting, there are a few key parts that we have not resolved, because we are not using E2B on-premises. Mainly, I'm talking about self-managing network security (to restrict access from sandboxes to the local cluster network), load balancing.
Happy to help with writing docs for self-hoting here!

Hi, thanks for considering this feature!

I’d like to ask if there’s a specific branch where the self-hosting related work is being developed? I’d love to look into the code and possibly contribute.

Thanks!

All services (expect docker reverse proxy) are now ready to be run in any Linux machine. There is currently just non existing tooling around non-GCP deployments.

[thegpt4]

May I use oracle cloud to deploy self-hosting E2B? I have a free tier for 24G , 200GB, 4 cpu. It's an arm64 server.

[sitole]

May I use oracle cloud to deploy self-hosting E2B? I have a free tier for 24G , 200GB, 4 cpu. It's an arm64 server.

You can definitely try to host E2B in Oracle Cloud. We are officially not supporting their Docker repository (you can switch to Template Builder v2, which does not use it), and also, the S3-compatible storage provider must be validated to ensure it works properly there, because we are using some specific GCP/AWS features that are not part of the standard.

I also think a bigger service and AMD64 architecture with virtualization is needed.

[abcdefan]

Hi team! Thanks for the update on self-hosting progress. I understand that the core components (API, client proxy, template manager, and orchestrator) are now ready for general Linux deployment, with the remaining challenges being network security management, load balancing, and deployment tooling.

I have two questions:

1. Release Timeline: Do you have any rough timeline for when these remaining pieces (especially the deployment tooling and documentation) might be ready for community use?
2. Service Interface Design: For the external services integration (storage, database, load balancer, etc.), are you planning to support a plugin/adapter pattern where we can simply provide service endpoints in configuration? For example:

storage:
type: s3-compatible
endpoint: https://our-minio.company.com/
database:
url: postgres://our-db.company.com:5432/e2b

This would allow us to integrate with our existing infrastructure (MinIO, PostgreSQL, HAProxy, etc.) without deep code modifications.We're very interested in deploying E2B in our private datacenter and would be happy to contribute to the documentation or testing once the basic framework is ready!

[sitole]

Hi team! Thanks for the update on self-hosting progress. I understand that the core components (API, client proxy, template manager, and orchestrator) are now ready for general Linux deployment, with the remaining challenges being network security management, load balancing, and deployment tooling.

I have two questions:

1. Release Timeline: Do you have any rough timeline for when these remaining pieces (especially the deployment tooling and documentation) might be ready for community use?
2. Service Interface Design: For the external services integration (storage, database, load balancer, etc.), are you planning to support a plugin/adapter pattern where we can simply provide service endpoints in configuration? For example:

storage: type: s3-compatible endpoint: https://our-minio.company.com/ database: url: postgres://our-db.company.com:5432/e2b

This would allow us to integrate with our existing infrastructure (MinIO, PostgreSQL, HAProxy, etc.) without deep code modifications.We're very interested in deploying E2B in our private datacenter and would be happy to contribute to the documentation or testing once the basic framework is ready!

Hi,
For tooling, we are internally exploring ideas on how to develop an extensible yet reliable and testable system for deploying to different cloud providers. Part of this involves self-hosting, which will probably still require some additional steps, as we do not want to impose opinions about customers' network security, storage backends, etc. We don't have a specific timeline to share, but we're continuously working on it.

The orchestrator/template manager now supports adapters for GCP/AWS/local storage, and it is written in a way that allows extension with additional providers that use compatible APIs as needed. I'm not sure about the current state of Minio, but it probably supports byte-range reads, which are still not necessary for snapshots downloading to work properly and fast.

We are exploring ways to implement changes that will allow anyone to bring their own PostgreSQL and OAuth server (partially already possible).