Unattended installation

The browser-based setup is the easiest way to install Databunker Pro by hand. For automated, repeatable deployments — CI/CD pipelines, infrastructure-as-code, container orchestration — Databunker Pro exposes a POST /autoinstall endpoint that performs the same first-time setup without a browser. This guide shows how to complete the install programmatically and capture the generated credentials.

Before you start

Databunker Pro deployed (see Docker Compose or Kubernetes / Helm).
The DATABUNKER_SETUPKEY environment variable set on the Databunker Pro container — this enables the /autoinstall endpoint (details below).
A reachable database. If you use a dedicated / managed database (e.g. AWS RDS), create the databunkerdb database and roles first — see Using an external database.
(Optional) a Databunker Pro license key. Without one, Databunker Pro runs in Trial mode.

How it works

Unattended installation is three HTTP calls against the Databunker Pro service:

GET /status — wait until the service is up.
GET /dbstatus — check whether setup is still required ({"installed": false}).
POST /autoinstall — perform the setup and return the credentials.

Setup endpoints are ephemeral. While the vault is not yet installed, Databunker Pro runs a small setup server that hosts /dbstatus, /setup, and /autoinstall. As soon as setup completes, that server shuts down and the container restarts in normal operational mode — where only the regular API (/status, /v2/*) is served and /dbstatus returns 404. That 404 is expected: it means the vault is already installed. (/dbstatus only ever returns a boolean installed flag — no sensitive data.)

The install runs once: call /autoinstall only when /dbstatus explicitly returns installed: false; treat a 404, a connection error, or any other response as “already installed — skip.”

Enable the setup endpoint

The /autoinstall endpoint is only available when a setup key is configured. Set DATABUNKER_SETUPKEY (and the persistent DATABUNKER_WRAPPINGKEY) in the container environment before starting Databunker Pro — for Docker Compose, in .env/databunker.env:

# Enables unattended install
DATABUNKER_WRAPPINGKEY=<48-hex-character wrapping key>
DATABUNKER_SETUPKEY=<a long random secret>

# Database connection
PGSQL_HOST=postgresql
PGSQL_PORT=5432
PGSQL_USER_NAME=bunkeruser
PGSQL_USER_PASS=<database password>
PGSQL_DATABASE=databunkerdb
PGSQL_SSL_MODE=disable

# Redis connection
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_USER_NAME=default
REDIS_USER_PASS=<redis password>

DATABUNKER_SETUPKEY is only needed to run the unattended install — once the vault is installed you can remove it, and the setup endpoint stays disabled. DATABUNKER_WRAPPINGKEY, on the other hand, must persist for the life of the vault: it is the wrapping key that unlocks the encrypted database on every start, so the container cannot open the vault without it. The PGSQL_* and REDIS_* keys point the container at your backing stores.

DATABUNKER_SETUPKEY only matters during the install, which is a one-time operation: anyone who reaches the service with it can install the vault, so use a long random value. Once the vault is installed the setup endpoint is disabled and the key stops being sensitive — you can safely remove it.

Then reference that file from the Databunker Pro service in docker-compose.yml:

services:
  databunkerpro:
    image: securitybunker/databunkerpro:latest
    restart: unless-stopped
    env_file:
      - .env/databunker.env
    entrypoint: /bin/sh
    command: -c "/databunker/bin/databunkerpro -db databunkerdb -conf /databunker/conf/databunker.yaml"
    volumes:
      - ../conf/databunker.yaml:/databunker/conf/databunker.yaml
    ports:
      - "3000:3000"

DATABUNKER_WRAPPINGKEY and DATABUNKER_SETUPKEY are loaded from .env/databunker.env, so the /autoinstall endpoint is enabled as soon as the container comes up.

Run the unattended install

Wait until Databunker Pro is ready

Poll GET /status until it returns 200 OK:

until curl -fsS http://localhost:3000/status >/dev/null; do sleep 2; done

Check whether setup is required

curl -s http://localhost:3000/dbstatus

Only {"status":"ok","installed":false} means setup is needed. Any other outcome — installed: true, a 404 (the setup server has already shut down), or a connection error — means the vault is already installed, so skip /autoinstall.

Run autoinstall

Send the setup key (and optional license key) as form fields:

curl
Python

SETUPKEY=$(grep '^DATABUNKER_SETUPKEY=' .env/databunker.env | cut -d= -f2-)

curl -s -X POST http://localhost:3000/autoinstall \
  --data-urlencode "setupkey=$SETUPKEY" \
  --data-urlencode "licensekey=$LICENSEKEY"   # optional; omit for Trial mode

Use --data-urlencode (not -d): license keys are base64 and may contain + or /, which -d would corrupt.

import time
import requests

BASE = "http://localhost:3000"
SETUPKEY = "..."      # value of DATABUNKER_SETUPKEY
LICENSEKEY = ""       # optional; leave empty for Trial mode

# 1. wait until ready
for _ in range(30):
    try:
        if requests.get(f"{BASE}/status", timeout=5).ok:
            break
    except requests.ConnectionError:
        pass
    time.sleep(2)

# 2. install only if the vault explicitly reports installed=false.
#    A 404 / error means the setup server is gone -> already installed -> skip.
def needs_install() -> bool:
    try:
        return requests.get(f"{BASE}/dbstatus", timeout=10).json().get("installed") is False
    except Exception:
        return False

if needs_install():
    body = {"setupkey": SETUPKEY}
    if LICENSEKEY:
        body["licensekey"] = LICENSEKEY
    resp = requests.post(f"{BASE}/autoinstall", data=body, timeout=30).json()
    assert resp.get("status") == "ok" and resp.get("root_token"), resp
    # 3. persist resp securely — see next step
    save_credentials(resp)
else:
    print("Databunker Pro already installed — skipping autoinstall")

Save the generated credentials

On success the response contains the vault credentials:

{
  "status": "ok",
  "root_token": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "wrapping_key": "...",
  "shamir_keys": ["...", "...", "...", "...", "..."]
}

Store all of these in your secrets manager immediately.

These secrets are shown once and cannot be retrieved again. The root_token is your admin credential — you pass it as the X-Bunker-Token header on every administrative API call. Losing it means re-installing.

Verify

The setup server restarts the container in normal mode. Confirm it is serving, then use the root token for API calls:

curl -fsS http://localhost:3000/status

curl -s -X POST http://localhost:3000/v2/SystemGetSystemStats \
  -H "X-Bunker-Token: $ROOT_TOKEN"

Using an external database

The bundled Docker Compose project provisions the databunkerdb database and its roles automatically. When you point Databunker Pro at a dedicated / managed database (AWS RDS, Cloud SQL, Azure Database), create them yourself first — connect as the database master user and run:

CREATE ROLE bunkeruser NOSUPERUSER LOGIN PASSWORD '<password>';
CREATE ROLE mtenant NOSUPERUSER NOLOGIN;
CREATE ROLE madmin BYPASSRLS NOSUPERUSER NOLOGIN;
CREATE DATABASE databunkerdb OWNER bunkeruser;
-- then, connected to databunkerdb:
GRANT ALL ON SCHEMA public TO bunkeruser;
GRANT mtenant TO bunkeruser;
GRANT madmin TO bunkeruser;

Point the container at the database with the PGSQL_HOST, PGSQL_USER_NAME, PGSQL_USER_PASS, and PGSQL_SSL_MODE environment variables, then run the unattended install as above.

If you run multiple Databunker Pro instances against one shared database, they must all use the same DATABUNKER_WRAPPINGKEY (only one instance runs /autoinstall; the others start against the already-installed database). The wrapping key must persist across restarts, or the vault cannot be reopened.

Next steps

Update your license key at any time after install.
Rotate and back up your master (wrapping) key and Shamir key shares.
Learn how to issue scoped credentials in the Authentication reference.

Get started

Installation

Administration

Concepts

Comparisons

Migrations

How-tos

Developer tools

Unattended installation

Before you start

How it works

Enable the setup endpoint

Run the unattended install

Verify

Using an external database

Next steps

​Before you start

​How it works

​Enable the setup endpoint

​Run the unattended install

​Verify

​Using an external database

​Next steps

Before you start

How it works

Enable the setup endpoint

Run the unattended install

Verify

Using an external database

Next steps