Compartment
Self-hosted deployment infrastructure for internal tools, private apps, and public services.
Docs · Quickstart · Developing locally · Contributing
What Is Compartment?
Compartment is a self-hosted deployment system for teams that need a controlled place to run software on their own infrastructure. It provides the runtime, URLs, access model, deployment history, and operations surface around applications that already live in normal repositories.
The project is CLI-first and repository-first. Add a compartment.yml, deploy from a checkout or connected Git repository, and run the result through a self-hosted control plane. If an app can build into a container image with Docker or Railpack, it can usually fit the Compartment model.
Why Teams Use It
Teams use Compartment when software that started as a script, internal app, worker, or AI-generated tool becomes useful enough that it needs a stable place to run.
- Share team software without ad hoc links, manual handoffs, or unclear ownership.
- Keep runtime control on infrastructure the team owns, without turning sustained compute or traffic into managed-platform spend.
- Govern access with SSO, RBAC, roles, and audit logs instead of informal permission paths.
- Run tools close to private services, data stores, and internal APIs while keeping workloads isolated.
- Move from repository code to a working app without building a custom platform stack first.
Quickstart
On the target server, install the CLI and initialize the Compartment system:
curl -fsSL https://compartment.dev/install.sh | sh -s -- --init-install
Prepare an application repository:
compartment init
The smallest descriptor looks like this:
name: internal-tools
services:
web: .
Deploy and inspect the result:
compartment deploy
compartment status
compartment logs
For branch-driven deploys, connect the repository through the Console or with compartment source connect git. See Deploy using Git for the full flow.
Repository Layout
| Path | Purpose |
|---|---|
packages/cli |
User-facing compartment command implementation. |
packages/sdk |
SDK client surface used by the CLI and other clients. |
packages/contracts |
Shared public contracts, schemas, paths, and generated reference inputs. |
packages/api |
Control-plane API, auth, persistence, migrations, and server-owned web serving. |
packages/console |
Vite and React browser control plane. |
packages/worker |
Deployment execution and background work. |
packages/node |
Runtime-node control surface for deployed services. |
packages/edge |
Hosted-app ingress and access enforcement boundary. |
public-docs |
Public Starlight documentation site. |
docs |
Internal architecture, package ownership, and operating specs. |
examples |
Example applications and descriptor fixtures. |
Developing Locally
Use the Node version pinned in .nvmrc and the pnpm version declared in package.json.
nvm use
pnpm install
cp .env.example .env
Local development expects PostgreSQL from COMPARTMENT_DATABASE_URL, plus caddy and railpack on PATH:
brew install caddy
curl -sSL https://railpack.com/install.sh | sh
pnpm dev
Read docs/specs/local-development.md before changing local runtime behavior.
Comments