Deploy your own Scribase
Run the real control plane — project lifecycle, verified backups, branch previews, the export bundler — inside your own Kubernetes cluster or on one VPS. Built for agencies running several client backends who need everything to live inside their own (or their client's) infrastructure, not ours.
Pick the one that matches your infrastructure
Kubernetes — Helm chart
The control plane (management API with its backup/export/import workers, the reconcile operator, and the Envoy gateway) as a real Helm chart, plus an optional shared data plane (auth, REST, storage, realtime) for single-cluster installs.
helm install scribase ./deploy/helm/scribase \
--set config.domain=backend.yourcompany.com \
--set dataPlane.enabled=trueSource: deploy/helm/scribase (Chart.yaml, values.yaml)
Kubernetes — kustomize base
The same control plane as plain manifests: namespace, RBAC and service accounts, the control-api and operator Deployments, secret-sync, a one-shot migration Job, the edge-functions router, and NetworkPolicies — for teams that standardize on kustomize over Helm.
kubectl apply -k deploy/kustomize/baseSource: deploy/kustomize/base (control-api.yaml, operator.yaml, network-policy.yaml, …)
One VPS — docker compose single-box
Many client projects on one host: each environment runs scale-to-zero in its own container, a Caddy router wakes it on the first request and stops it after it goes idle, and only one locked-down runtime-agent process ever touches the Docker socket. Built for a single low-cost box, not a cluster.
docker compose -p scribase --env-file .env \
-f docker-compose.yml \
-f docker-compose.single-box.yml \
-f docker-compose.shared-services.yml up -dSource: deploy/compose/docker-compose.single-box.yml
Not a stripped-down fork
- The real control plane: project/environment lifecycle, verified backups and restores, the export bundler, branch previews, and the usage/billing adapters (metering only — you decide whether to wire a biller at all).
- Least-privilege operator roles: in the single-box profile, only runtime-agent touches the Docker socket, with no network and a fixed request set; nothing else reaches the Docker or Kubernetes API directly.
- The same CLI and APIs as the hosted product — a BYOC install is not a stripped-down fork, it is the same binaries pointed at your cluster or box.
- The same full export bundle any time (crates/export): your own install already is the "take the servers" promise, start to finish.
Scribase BYOC
From $399/mo per cluster or box
Covers the control plane license, the Helm chart and kustomize base, and direct support standing it up. Your own infrastructure cost (the cluster or VPS itself) is separate — you are not paying us for compute you are already running. By agreement today, not self-serve checkout; email support@scribase.com with your target infrastructure and we will scope it.
Questions people ask
How is this different from the authenticated export bundle?
The export bundle (console → Export, or the public schema-only tool at /tools/export-database) gives you a one-time snapshot of a single project. BYOC runs the full, ongoing control plane yourself — new projects, branches, backups and restores keep happening on your own infrastructure, indefinitely.
What does BYOC cost?
Scribase BYOC starts at $399/mo per cluster or box: the control plane, the Helm chart and kustomize base, and direct support getting it running. It is billed separately from hosted per-project pricing (this plan runs on your infrastructure, not ours) and is by agreement rather than self-serve checkout today — email support@scribase.com with your target infrastructure (cluster size, or a single VPS) and we will scope it.
Which path should I pick — Helm, kustomize, or single-box compose?
Helm or kustomize if you already run a Kubernetes cluster (Helm if you want one chart and values.yaml, kustomize if you standardize on plain manifests). Single-box compose if you are putting several client projects on one modest VPS and do not want to run a cluster at all.
Do I still get backups and point-in-time recovery self-hosted?
Yes — the backup/restore workers are part of the control plane in every deploy path, not a hosted-only add-on. You own the storage target they write to.