Skip to content
bucker

Self-host: Community Edition

Bucker Community Edition is error ingest and triage, self-hosted, on four containers. Everything to run it lives in selfhost/; this page is the product-level answer to "what do I get, and what stays in the cloud".

cd code/selfhost
./bootstrap.sh

Four containers

postgres · api · worker · web.

Postgres is the database, the queue (SELECT … FOR UPDATE SKIP LOCKED) and the vector store, so there is no broker, no ClickHouse and no separate vector service. That is a deliberate architectural commitment, not a shortcut: the design doc's verdict on cloning Sentry's stack — 20–40 containers, a 16–32 GB floor — is that its heaviness created an entire competitor segment. A self-host that is not genuinely small backfires.

A test fails the build if a fifth service appears in the compose file.

The commercial boundary

Two capabilities stay in Bucker Cloud.

Sandbox fix verification — cloud only

Verifying a fix means executing your code and an LLM-authored patch in an isolated sandbox. CE ships no sandbox provider: the isolation, the compute budget and the spend metering are things we operate and pay for. Starting a remediation run in CE returns 403 with an explanation; reading run history and configuring the suite still work.

Cross-tenant fix memory — cloud only, and not built yet

Retrieval of "another tenant already fixed something that looks like this". A single-tenant install has no cross-tenant corpus, so there is nothing to retrieve from — and the capability is not implemented in any edition yet; the design defers it pending a consent model. The gate exists so the first implementation cannot ship into CE by accident.

Within-project remediation memory is included in CE and is what powers similar-issue suggestions there.

Everything else is in CE

Grouping and the issue lifecycle · the ≤500-token error essence and progressive hydration · anti-injection trust labelling and quarantine · the one alert routing engine (email, Slack, webhooks) · release health and crash-free rates, not paywalled · the staged-rollout guardian · cron and uptime monitors · session replay · RCA · agent identity, budgets and approvals · SSO and SCIM (subject to plan features) · the MCP server · agentic observability.

How the gate behaves

BUCKER_EDITION=ce turns on one request hook (api/src/modules/edition/plugin.ts, deriving its matcher from the feature table in domain/src/modules/edition/). A gated call gets a 403 whose message names the capability, the reason and the documentation anchor — never a crash, never a 404 that sends you debugging your reverse proxy.

Ask the server what it will refuse, before you hit it:

curl -s http://localhost:4000/edition
{
  "edition": "ce",
  "features": [
    { "id": "sandbox_verification", "name": "Sandbox fix verification",
      "enabled": false, "reason": "…", "docs": "…" },
    { "id": "cross_tenant_fix_memory", "name": "Cross-tenant fix memory",
      "enabled": false, "reason": "…", "docs": "…" }
  ]
}

An unset or unrecognised BUCKER_EDITION resolves to cloud — the hosted deployment is the default. Anything that is not cloud/hosted/enterprise resolves to CE, so a typo in a self-hoster's .env fails toward the gate rather than through it.

Footprint, honestly

selfhost/README.md carries the measured numbers and — just as importantly — states which ones were not measured. The short version: the Postgres side of the 2 GB VPS target is measured and comfortable; the three Node services have not been measured in their containers, because the images have not been built in the environment this was written in. The claim will not be made until someone runs it.

Retention runs by default

Two schedulers run inside the worker container, on by default — CE's worker runs the exact same @bucker/workers process the cloud deployment does (selfhost/Dockerfile's worker target builds it from source), and docker-compose.yml sets neither variable below, so neither is disabled:

  • RetentionScheduler (workers/src/retention/scheduler.ts) provisions tomorrow's day partitions, archives days past each project's hot window, drops the partitions once archived, and expires cold blob objects — hot/cold tiering and partition management, not merely a schema built for it. RETENTION_ENABLED=false turns the whole pass off; RETENTION_DROP_ENABLED=false keeps it archive-only, which is the safer setting to run with until you have verified the archived objects on a fresh install.
  • ComplianceRetentionScheduler (workers/src/compliance/scheduler.ts) enforces each org's retention window on audit logs, spans, log records and replay segments — deleting the blob before the row it is keyed from, so a deleted replay recording's bytes are never left orphaned in object storage. COMPLIANCE_RETENTION_ENABLED=false turns it off.

Deliberately not in CE

  • No object storage. Envelopes ride inline in Postgres, capped at 1 MiB — the max and the inline threshold are set equal so nothing can exceed it. Replay, warehouse exports and DSR bundles do still use the blob store and fall back to each container's own disk, which api and worker do not share; CE opts out of the production refusal with STORAGE_ALLOW_LOCAL=true. Point STORAGE_PROVIDER=s3 and S3_* at your own bucket to close it.
  • No reverse proxy or TLS. Put your own in front; bundling one would make this five containers and take the decision away from you.
  • No backups, no HA. One Postgres, one volume, your pg_dump.

Upgrading

git pull && docker compose build && ./bootstrap.sh

bootstrap.sh is idempotent: it fills in only blank secrets, runs migrations in a one-off container with the api stopped, and skips first-admin creation when the account exists. Migrations are forward-only — back up first.