Kubernetes deployment infrastructure for internal tools, private apps, and public services.
Docs · Quickstart · Developing locally · Contributing
Compartment is a self-hosted Kubernetes deployment system for teams that need a controlled place to run software on their own infrastructure. It installs into an existing cluster or provisions a managed single-node Kubernetes host, then 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.
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.
Install the verified CLI and start the managed installation:
curl -fsSL https://compartment.dev/install.sh | sh
compartment installWhen no usable Kubernetes context exists, the CLI selects the managed-VM target, checks the host, shows one mutation
review, and requests sudo only after confirmation. Operators can instead select an existing cluster explicitly with
compartment install --target kubernetes.
Prepare an application repository:
compartment initThe smallest descriptor looks like this:
name: internal-tools
services:
web: .Deploy and inspect the result:
compartment deploy
compartment status
compartment logsFor branch-driven deploys, connect the repository through the Console or with compartment source connect git. See Deploy using Git for the full flow.
| 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/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. |
Use the Node version pinned in .nvmrc and the pnpm version declared in package.json.
nvm use
pnpm install
cp .env.example .envLocal development expects PostgreSQL from COMPARTMENT_DATABASE_URL, plus caddy, buildctl, docker, and
railpack on PATH. The Docker-compatible CLI and daemon run the loopback artifact registry; they are not an
application runtime target. BUILDKIT_ADDR must point at a reachable BuildKit daemon.
brew install caddy buildkit
curl -sSL https://railpack.com/install.sh | sh
pnpm devRead docs/specs/local-development.md before changing local runtime behavior.
Start with CONTRIBUTING.md. The short version:
- Keep changes package-owned and scoped to one behavior.
- Start new product behavior from the CLI command and shared SDK/API contract.
- Read the relevant file under docs/layers before editing a package.
- Update public docs when shipped user-visible behavior changes.
- Run the narrowest relevant lint, typecheck, and test commands for the package you touched.
Compartment is licensed under the Apache License 2.0.