sandboxd：把 AI 应用构建器装进自己的服务器，一条命令起一个沙箱
开源、自托管的人工智能应用程序构建器，代理在您自己的服务器上的隔离沙箱中构建真实的应用程序，每个应用程序都位于预览 URL 上。通过一个命令进行自托管。麻省理工学院。
秒懂
- 它是什么？
- sandboxd 是一个用 Go 写的自托管 AI 应用构建引擎，它把提示词变成隔离容器里的真实应用，并给每个应用一个预览 URL。本文拆解它的架构、上手方式、局限和适用场景。
- 适合谁用？
- 如果你想让 AI 编码代理在自己的服务器上构建应用，并且希望每个应用都有独立的隔离环境和预览 URL，sandboxd 值得一试。它适合有 Docker 和 Linux 基础的个人开发者或小团队，尤其是那些不想把代码和数据交给托管服务的用户。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 7 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是什么问题
市面上的 AI 应用构建工具，比如 Lovable、Bolt、v0，都有一个共同点：应用跑在别人的服务器上。你输入提示词，得到一个 URL，但代码、数据和基础设施都不在你手里。sandboxd 把这一套流程搬到你自己的服务器上。它用 Go 写了一个守护进程，接到一个 HTTP 请求后，会启动一个隔离容器，在里面运行 AI 编码代理，最后给应用分配一个预览 URL。目标用户很明确：想自托管、在意数据主权、或者想把这套能力嵌入自己产品的开发者。
核心机制：一个 Go 程序驱动 Docker
sandboxd 的架构刻意保持小。README 里说得很清楚：一个 Go 程序驱动 Docker，Traefik 处理 URL，SQLite 存状态，没有 Kubernetes，没有独立数据库，也没有消息队列。每个沙箱是一个私有容器，有自己的文件系统和资源限制。空闲的沙箱会休眠，按需唤醒，所以一台普通服务器能跑很多应用，而不是每个应用占一台虚拟机。这种设计的好处是部署简单，坏处是扩展性有限，所有状态集中在单机 SQLite 上，如果服务器挂了，所有沙箱都会受影响。
两种使用方式：API 优先，控制台可选
sandboxd 是 API 优先的设计，所有操作都是 /v1 调用。你可以完全不用 Web 控制台，直接通过 curl 或脚本驱动。控制台只是一个纯 /v1 客户端，方便不写代码的人用。README 给出的 API 例子很直接：先注册一个 agent 的 API key，然后创建沙箱，再提交任务。控制台提供聊天界面、文件编辑、git diff 预览和推送功能，适合快速上手。如果你要构建产品，直接调 API 就行，控制台不是必需品。
安装与启动：一条命令，但依赖 Docker
安装命令是 curl 管道执行 install.sh，它会构建镜像、启动栈，并打印控制台 URL 和生成的登录凭据。前提是 Linux 上装了 Docker 和 Compose 插件，macOS 通过 Docker Desktop 属于尽力支持。支持 amd64 和 arm64，包括 Apple Silicon 和 AWS Graviton。装完后控制台在 http://console.localhost，API 在 http://127.0.0.1:9090，健康检查是 curl /healthz 返回 ok。想无头运行，设置 SANDBOXD_CONSOLE=0 或加 --no-console 参数。升级用 ./upgrade.sh，会先备份数据库，健康检查新版本，失败自动回滚。
能跑什么：80 多个预置应用和自带仓库
sandboxd 不只是从零构建。它提供 80 多个预置应用，比如 Ghost、n8n、Gitea、Grafana、Metabase、Uptime Kuma、Jupyter、Keycloak，一键安装并分配 URL。也支持从 React/Vite、Next.js、FastAPI 脚手架开始，或者导入任意公开 Git 仓库，让代理直接改代码。README 强调，任何 Node、Python 或静态二进制应用都能直接跑，其他语言需要自带基础镜像或预设。这意味着如果你有一个自定义运行时，需要额外配置，不是开箱即用。
局限与失败模式
最明显的局限是单机依赖。SQLite 和 Docker 都在一台机器上，没有集群能力，也没有内置的多租户隔离策略。虽然每个沙箱是隔离容器，但宿主机层面的资源竞争无法避免。另一个问题是版本迭代快，最近发布频率很高，v0.3.18 到 v0.3.20 在几天内连续推出，说明 API 和功能还在变动，生产环境需要谨慎锁定版本。还有一点，README 提到 macOS 是 best-effort，意味着在非 Linux 环境可能遇到问题。如果你需要高可用或水平扩展，这个项目目前不是合适的选择。
替代方案：与托管服务的本质区别
最直接的替代是 Lovable、Bolt、v0 这类托管服务。它们的差异在于基础设施所有权：托管服务帮你管理服务器、扩展和备份，你只需要付钱；sandboxd 把这一切交给你，但你也承担运维责任。另一个接近的替代是 Dagger 或 NixOS 这类可复现构建工具，但它们不包含 AI 代理和预览 URL 机制，而是聚焦于构建流程本身。如果你只是想要一个 AI 编码代理跑在本地，可以直接用 Claude Code 或 OpenCode 配合 Docker，但那样你失去了 sandboxd 提供的沙箱生命周期管理、休眠唤醒和 URL 分配。
维护成本与许可证
项目是 MIT 协议，自托管免费，没有商业限制。升级脚本会自动备份和回滚，这降低了维护风险，但你需要定期运行 ./upgrade.sh --check 来查看版本。由于项目还在 0.x 阶段，API 可能不稳定，升级前应该阅读 release notes。文档提到云服务是可选，但自托管引擎始终是完整产品，这意味着你不会被强制绑定到厂商。维护成本主要在于 Docker 镜像的更新和 SQLite 数据库的备份，没有内置的备份机制，你需要自己处理。
编辑结论
如果你想让 AI 编码代理在自己的服务器上构建应用，并且希望每个应用都有独立的隔离环境和预览 URL，sandboxd 值得一试。它适合有 Docker 和 Linux 基础的个人开发者或小团队，尤其是那些不想把代码和数据交给托管服务的用户。不适合需要复杂多租户隔离、细粒度资源配额或生产级高可用的人，因为它的状态存于 SQLite，架构刻意保持单机。在采用前，先确认你的服务器能满足 Docker 和 Compose 插件的要求，并检查 v0.3.x 版本的 API 是否稳定，因为项目仍在快速迭代，升级脚本虽然会自动回滚，但新版本可能引入破坏性变更。
社区笔记