Proposal: Add Alibaba Cloud self-hosting support

Summary

Hi E2B team,

First of all, thank you for building and open-sourcing E2B. We think the project is very valuable for AI coding agents and code execution workflows, and we have seen interest from users who would like to run E2B in their own cloud environments.

We are currently running a self-hosted E2B deployment on Alibaba Cloud and would like to contribute Alibaba Cloud self-hosting support upstream if this is useful for the project and aligned with your roadmap.

For context, Alibaba Cloud, also known as Aliyun, is Alibaba Group’s cloud computing platform and a major cloud provider in China and the Asia-Pacific region.

Our goal is to keep the upstream architecture and core runtime behavior unchanged, and contribute Alibaba Cloud-specific functionality as isolated provider, deployment, and documentation support.

Non-goals

We would like to avoid changing:

• the public E2B API contract
• Firecracker, orchestrator, and template build core logic
• scheduler, NBD, networking, or other high-blast-radius runtime internals
• behavior of existing AWS, GCP, or local self-hosted deployments

Proposed Scope

If this direction makes sense, we can contribute the work incrementally.

1. Alibaba Cloud Deployment Support

• Resource Orchestration Service (ROS), Alibaba Cloud’s infrastructure-as-code service similar to Terraform or AWS CloudFormation, for provisioning E2B infrastructure
• ECS node pools for API/control, orchestrator/runtime, and template builder nodes
• VPC and SLB/NLB - networking and load balancing for E2B services
• RAM Role / STS-based credentials
• Redis for caching and coordination, and PostgreSQL for persistent E2B metadata

2. Alibaba Cloud OSS Storage Provider

• OSS implementation for template, snapshot, rootfs, and related artifacts
• range reads and large-object upload support
• ECS RAM Role based credentials

3. Alibaba Cloud ACR Artifacts Registry Provider

• use ACR as the template build image registry
• support the template build image handoff path, where a build image is pushed to ACR and later pulled by the template builder
• support RAM Role / ACR token based authentication
• support repository creation, or document repository prerequisites if maintainers prefer not to create repositories automatically

4. Self-hosting Documentation

• Alibaba Cloud prerequisites
• required ECS instance capabilities for Firecracker/KVM
• required RAM permissions
• deployment steps
• smoke test steps
• troubleshooting notes for storage, registry, and template build paths

Proposed Contribution Plan

We do not want to submit a large, hard-to-review PR.

If the maintainers are open to this direction, we would prefer to start with a small design/docs PR first, then follow up with focused implementation PRs.

A possible PR sequence could be:

1. Design/docs for Alibaba Cloud self-hosting support
2. OSS storage provider with tests
3. ACR artifacts registry provider with tests
4. ROS-based deployment skeleton
5. Self-hosting documentation and smoke test steps

We are happy to adjust the scope, naming, directory layout, provider interfaces, and PR order based on maintainer preference.

Validation Plan

We plan to validate the Alibaba Cloud provider with:

• API health check
• sandbox create/connect/delete
• pause/resume
• template build
• template build from an existing image
• private registry / ACR pull path
• basic concurrent sandbox creation
• regression checks to make sure existing AWS, GCP, and local behavior remains unchanged

Questions

Would Alibaba Cloud self-hosting support be something you would be open to accepting upstream if we keep it isolated to provider, storage, registry, deployment, and documentation layers?

If yes, would you prefer that we start with a small design/docs PR before implementation?

We would also appreciate guidance on preferred naming, directory layout, provider interfaces, and PR order.

Start by reviewing the existing provider, storage, registry, and deployment interfaces, then compare them with the proposed Alibaba Cloud scope. A first contribution should be a maintainer-approved design/docs PR that defines the provider boundaries, naming, directory layout, PR order, and validation plan before implementation begins.