Cloud vs Self-Hosted
Choose the deployment path that fits your team in 60 seconds.
BlackLake runs in two modes: the hosted cloud control plane at
console.blacklake.systems and the
self-hosted install via npx blacklake serve on your own machine or
infrastructure.
Both modes use the same policy, approval, budget, cost, and receipt model. The difference is who runs the ops and what integrations are available out of the box.
Start with cloud if…#
Most teams should start here. Cloud is the fastest path to a working control plane with shared controls and no infrastructure burden.
| Situation | Why cloud fits |
|---|---|
| You want to start today | Sign up, copy an API key, point your MCP config — five minutes to first receipt |
| You need shared controls across your team | Workspaces, shared policies, shared approval queues, per-user API keys |
| You use OAuth-protected upstreams (Atlassian, Linear, Slack) | Cloud handles the OAuth handshake, token storage, and refresh — local cannot |
| You want approval delivery to email or mobile | Email fan-out and web push are cloud-only |
| You expect to need audit evidence for SOC 2 or similar | Managed retention archive, signed exports, compliance evidence packs |
| You'd rather not run the ops | No database to maintain, no upgrade cadence, no backup runbook |
Cloud is free while in beta. No credit card required.
Self-host or run locally if…#
Self-hosting is a legitimate path. Be explicit about the trade-offs.
| Situation | What it means in practice |
|---|---|
| Air-gapped requirement | Your environment has no outbound internet — cloud is not an option |
| Regulated industry without cloud approval | Procurement hasn't approved SaaS data-plane; self-host until it does |
| Evaluating with very sensitive data | Run locally first, migrate to cloud when you're confident in the data boundary |
| Paranoid prototyping | No problem — npx blacklake serve has the full control model locally |
When you self-host, you own:
- The database — SQLite for local; Postgres for production self-hosted. Backups, restore paths, and retention management are yours.
- The upgrade cadence — no automatic updates. Follow the changelog and apply migrations manually.
- The audit retention — no managed archive. Long-term retention requires your own export pipeline.
- The evidence pack generation — compliance packs are not automated; you export and organize manually.
- OAuth upstreams — not available without a public callback URL.
None of these are blockers for evaluation or for teams with the ops capacity to run them. They are explicit trade-offs, not omissions.
Moving from local to cloud#
When you're ready to move from local evaluation to a shared team workspace:
- Sign up at console.blacklake.systems
- Export your local policies as JSON from
GET /v1/policieson the local API - Import them into the cloud workspace via the console or
POST /v1/policies - Update your MCP config to point at the cloud endpoint instead of
localhost:3100 - Your evaluations history stays in the local SQLite — it does not migrate automatically
The policy model is identical. Receipts from the local workspace are verifiable
against the local server; receipts from the cloud workspace verify against
api.blacklake.systems. The two chains are separate.
Feature comparison#
| Feature | Cloud | Self-hosted |
|---|---|---|
| Policy, approval, budget, cost, receipt | Yes | Yes |
| MCP gateway | Yes | Yes |
| SDK govern() | Yes | Yes |
| blx shell wrapper | Yes | Yes |
| GitHub Action policy gate | Yes | Yes |
| Shared workspace (team) | Yes | Manual setup |
| OAuth upstream support | Yes | No |
| Approval email delivery | Yes | No |
| Mobile push approvals | Yes | No |
| Managed retention archive | Yes | No |
| Coverage and risk dashboards | Yes | Yes |
| Signed NDJSON/CSV export | Yes | Yes |
| Receipt verification endpoint | Cloud: api.blacklake.systems | Local: localhost:3100 |
| Database | Managed Postgres | SQLite (local), Postgres (self-hosted) |
| Upgrade management | Automatic | Manual |
The 80/20 answer#
Cloud is the right answer for roughly 80% of teams — fastest time to value, no ops burden, and the integrations that make approvals and exports actually usable in a team context.
Self-hosted is right when an external constraint (air-gap, procurement, sensitivity) makes cloud not viable. If you're self-hosting by preference rather than constraint, start in the cloud first — you can always export your policies and migrate later.
Questions? Contact us or read the cloud product page for more on what the hosted control plane gives you that local self-hosting doesn't.