Steelkeep

Database backups. A clear path to recovery.

Self-hosted backups for eight database engines, with a web dashboard and native MCP access for your AI agents.

Get started · Database profiles · AI agents · Documentation

PostgreSQL · MySQL · MariaDB · MongoDB SQLite · Redis · ClickHouse · SQL Server

Why Steelkeep

Keep database connections, backup schedules, snapshots and recovery in one place. See what the worker is doing, inspect the archive it created, and review the destination before a restore writes data. Use the dashboard or give a scoped AI agent access to the same operations.

Related MCP server: spanning-mcp

Project status

Database profiles

Archives currently have a 2 GiB limit. Each profile has version, schema and consistency requirements; eight adapters do not imply arbitrary-version or cluster support.

MySQL/MariaDB refuse stored programs, views, triggers/events and non-InnoDB tables. MongoDB replica sets/shards and ClickHouse distributed/replicated tables need additional profiles. SQL Server BACPAC is logical portability, not native .bak, log-chain recovery or PITR. Source locking and maintenance requirements vary by engine.

Read the full profiles, native tooling and independent runtime evidence.

Self-host

You’ll need: Bun 1.4 for setup, Docker Compose, an S3-compatible bucket with credentials, and network access from the worker to the chosen database. Run setup as the intended non-root service owner. Native package pins are in Dockerfile.engines. SQL Server additionally needs the explicit x64 extension and applicable Microsoft terms; it is not silently downloaded by the default stack.

1. Prepare your installation

From a source checkout:

git clone https://github.com/grootbro/steelkeep.git
cd steelkeep
bun install --frozen-lockfile
bun scripts/setup-local.ts

2. Configure access

Edit .env before starting. Set exact database and S3 hostnames in STEELKEEP_ALLOWED_HOSTS. For HTTPS also set:

STEELKEEP_PUBLIC_HOSTS=backup.example.com
STEELKEEP_ALLOWED_ORIGINS=https://backup.example.com
STEELKEEP_SECURE_COOKIE=true

3. Build once and start

Keep the generated .steelkeep/key, .steelkeep/token and .steelkeep/metadata-password private. Setup preserves existing files. Build the web and multi-engine worker once, then start:

docker compose -f compose.selfhost.yaml pull database
docker compose -f compose.selfhost.yaml build migrate
docker compose -f compose.selfhost.yaml build worker
docker compose -f compose.selfhost.yaml up -d --no-build --pull never

The web server binds 127.0.0.1:4310 on the host. Put your HTTPS reverse proxy in front of that port; preserve the Host header and streaming responses. Metadata and archive storage are separate: the Compose file provisions PostgreSQL metadata, while you supply the S3 bucket. Worker-local SQLite files and ClickHouse shared disks need explicit mounts and allowlists described in engine profiles.

4. Create your account

Create a private, single-use setup link immediately before opening it:

docker compose -f compose.selfhost.yaml exec \
  -e STEELKEEP_SETUP_ORIGIN=https://backup.example.com \
  web bun scripts/setup-owner.ts

The link expires in five minutes and contains no installation key. Choose your name, email and password; later visits use ordinary sign-in. For loopback-only HTTP testing, use http://127.0.0.1:4310 and STEELKEEP_SECURE_COOKIE=false. See authentication.

Your first backup

1. In Connections, add your database and S3 storage; test both connections. Use a dedicated database role with the documented permissions.

2. Create a plan with that source and destination. Start manually or configure a timezone schedule.

3. Follow the actual worker phases in Jobs. Open the resulting snapshot to inspect size, SHA-256, availability and logs.

4. Test recovery into a separate empty destination. A stored archive and a successful restore validation are distinct results.

API and AI agents

Connect your MCP client to your installation:

https://backup.example.com/mcp

Create an agent in Configuration → AI agents, then give its token to your MCP client as a bearer credential. The default grant is read-only and expires in 24 hours. Tokens are shown once and stored hashed. Delegation cannot increase permissions or outlive its issuer; revocation includes descendants. No model-provider account is required.

read · configure · backup:run · restore:run · jobs:cancel · agents:manage · backup:delete · backup:download

See authentication and agent access.

How recovery stays deliberate

An empty-target review expires and is bound to the actor, source artifact, destination identity and permissions. SHA-256 is checked before restore writes. Unknown restore outcomes retain a destination reservation and are never automatically replayed; inspect partial data and prepare a fresh target.

Snapshot availability HEAD checks inspect object metadata, not downloaded bytes. Native downloads and restores verify complete bytes. Manual deletion requires a reviewed selection and explicit acknowledgement; ambiguous conditional deletes stay held without retry. See downloads, reviewed deletion and retention.

Documentation

Built with

TypeScript · TanStack Start / Router / DB · React · Elysia · Bun PostgreSQL metadata · Kysely · pg-boss · S3-compatible archives

The web dashboard, REST API and MCP server call the same application services. Native tools run in the worker.

Development

The synthetic development fixtures contain deliberately public disposable credentials. Never reuse them for real services. Follow architecture and development evidence and the guarded acceptance scripts; heavy native fixtures are opt-in.

bun run typecheck
bun run typecheck:acceptance
bun run test

Default tests do not start database fixtures. The CI workflow installs locked dependencies, runs both TypeScript checks and default tests, and builds the web application. See the GitHub CI results; these checks do not qualify native recovery.

Some historical acceptance harnesses deliberately require their original absolute checkout and fixture identities. They are operator-specific tools, not a portable test suite; don't remove their guards just to run them elsewhere. Native acceptance requires independent archive-byte and restored-data checks. Historical proofs don't automatically qualify newer source, packages or images. See the acceptance ledger, native tooling and parity tracker.

Contributing and license

See CONTRIBUTING.md and SECURITY.md. Steelkeep source is MIT licensed. Adapted Databasement interface material, fonts and optional Microsoft tooling retain their respective notices and terms. Salt.md was an interaction reference; its AGPL source/assets were not copied.