通过兼容网关自建 E2B 代码沙箱
文章比较 E2B 自有开源运行时与 OpenDsec 兼容网关，重点演示后者的单机部署、SDK 接入、代码解释器配置及集群扩展。方案要求 Linux、systemd 和 cgroup v2，使用 Firecracker 微虚拟机还需支持 KVM。
原文暂未完整获取，基于公开信息的快读
E2B 代码沙箱可以怎样搬进内网？dev.to 的一篇文章对比了 E2B 自有开源运行时和 OpenDsec 兼容网关，重点演示后者如何在自己的服务器上接入 E2B SDK。现有节选覆盖单机安装、代码解释器和集群扩展，但兼容性说明并不完整。
目前能确认什么
两条路线需要分清：E2B 自有开源运行时支持单机自托管，部署到自有云账号的 BYOC 属于企业功能；OpenDsec 则通过网关提供 E2B API。
作者称，设置 E2B_API_URL、E2B_SANDBOX_URL 和 E2B_API_KEY 后，已有 SDK 代码可以接入网关。节选展示了创建沙箱、执行命令、读写文件和销毁沙箱，也提到 JS/TS SDK 支持。
主机需要 Linux x86_64、systemd 和 cgroup v2。使用 Firecracker 微虚拟机还需要 KVM；云主机则要支持嵌套虚拟化。微虚拟机提供独立内核的隔离环境，能否运行取决于底层主机条件。
代码解释器需要单独构建模板，构建过程会访问 apt 镜像源和 PyPI。集群方案则使用多个网关副本和负载均衡。
我的判断
这更适合作为现有 E2B 应用迁入内网的候选方案，不能直接视为完整替代。
优先核对的应是应用实际调用的 API：基础命令与文件操作有示例，其他选项的兼容范围还不清楚。节选在差异说明处截断，无法据此判断所有调用都能原样迁移，也没有完整性能数据可供比较。
另外，自托管和断网部署是两回事。代码解释器构建仍依赖外部软件源，隔离网络需要提前准备依赖。对程序员而言，第一步应核对目标机器的 KVM 条件，再用现有 SDK 调用验证兼容范围；仅修改三个环境变量，还不足以证明迁移完成。