Databunker 0.8.36

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick Databunker 0.8.36 on Ubuntu 24.04 as the software version, select your Region, and choose Launch through EC2. Choose m5.large, your key pair, and a security group as described above.

To launch with the AWS CLI instead, replace the values in angle brackets:

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=databunker}]'

First boot takes a few seconds after the instance is running. To use your own name from the start, put it in /etc/sac/databunker-domain with user data (for example a cloud-init write_files entry). Otherwise, first boot uses the instance's public DNS name, or its public IP address if it has no DNS name.

Operating system SSH user

Ubuntu 24.04 ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

systemctl is-active databunker-firstboot databunker nginx

active active active

Only SSH, HTTP and HTTPS are public, and Databunker listens on the loopback address:

sudo ss -tln | grep -E ':(22|80|443|3000) '

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* LISTEN 0 511 0.0.0.0:443 0.0.0.0:* LISTEN 0 4096 127.0.0.1:3000 0.0.0.0:* LISTEN 0 511 [::]:80 [::]:* LISTEN 0 4096 [::]:22 [::]:* LISTEN 0 511 [::]:443 [::]:*

Run a local health check, which is answered only on the loopback address, to confirm that Databunker can reach its vault:

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/status

200

sudo cat /root/databunker-credentials.txt

The file (root only, mode 0600) contains this instance's address, the SHA-256 fingerprint of its certificate, and the API root token:

# Databunker 0.8.36 - written on first boot by databunker-firstboot.service. Unique to this instance. DATABUNKER_URL=https://ec2-54-164-141-163.compute-1.amazonaws.com/ DATABUNKER_TLS_SHA256=EE:16:5A:E9:...:(64 hex digits in pairs) DATABUNKER_ROOT_TOKEN=<the 36-character root token> ...

The root token is the administrator credential. Keep it secret, and give your applications their own copy through your secrets manager.

The master key that encrypts every record is /etc/databunker/masterkey (mode 0600, root). Back up the master key off the instance, and keep it apart from your vault backups. Without it, nobody, including SecureAnyCloud, can decrypt the vault.

sudo stat -c '%a %U:%G %n' /etc/databunker /etc/databunker/masterkey /var/lib/databunker/databunker.db /root/databunker-credentials.txt

750 root:databunker /etc/databunker 600 root:root /etc/databunker/masterkey 600 databunker:databunker /var/lib/databunker/databunker.db 600 root:root /root/databunker-credentials.txt

The certificate is self-signed and unique to your instance, so your browser and clients warn about it. Check that its SHA-256 fingerprint matches DATABUNKER_TLS_SHA256 before you trust it. Do not add it to your operating system's trust store. For production, replace it with a certificate from a certificate authority (Step 8).

The certificate is an end-entity certificate for this instance's names only:

openssl x509 -in /etc/ssl/databunker/databunker.crt -noout -subject -ext basicConstraints,keyUsage,extendedKeyUsage,subjectAltName

subject=CN = ec2-54-164-141-163.compute-1.amazonaws.com, O = sac X509v3 Subject Alternative Name: DNS:ec2-54-164-141-163.compute-1.amazonaws.com, IP Address:54.164.141.163, IP Address:172.31.82.9 X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication

Every privileged call carries the root token in the X-Bunker-Token header. On the instance, put the header in a file that only you can read, so the token never appears on a command line. Use the instance's own certificate as the trust anchor:

U=$(sudo sed -n 's/^DATABUNKER_URL=//p' /root/databunker-credentials.txt) ( umask 077;
sudo sed -n 's/^DATABUNKER_ROOT_TOKEN=/X-Bunker-Token: /p' /root/databunker-credentials.txt > ~/databunker-token.hdr ) curl -s --cacert /etc/ssl/databunker/databunker.crt "${U}status"; echo

OK

Without the token, Databunker refuses to store a record:

U=$(sudo sed -n 's/^DATABUNKER_URL=//p' /root/databunker-credentials.txt)
curl -s --cacert /etc/ssl/databunker/databunker.crt -w ' %{http_code}\n' -H 'Content-Type: application/json' \
  --data '{"login":"alice","email":"alice@example.com"}' "${U}v1/user"

Access denied 403

With the token, create a record, read it back by its token and by its login, update it, and delete it:

U=$(sudo sed -n 's/^DATABUNKER_URL=//p' /root/databunker-credentials.txt) C="curl -s --cacert /etc/ssl/databunker/databunker.crt -H @$HOME/databunker-token.hdr"
R=$($C -H 'Content-Type: application/json' --data '{"login":"alice","email":"alice@example.com","name":"Alice Example","phone":"+447700900123"}' "${U}v1/user"); echo "$R"
T=$(python3 -c 'import json,sys; print(json.loads(sys.argv[1])["token"])' "$R") $C "${U}v1/user/token/${T}"; echo $C "${U}v1/user/login/alice"; echo $C -X PUT -H 'Content-Type: application/json' --data '{"name":"Alice Smith"}' "${U}v1/user/token/${T}"; echo $C "${U}v1/user/token/${T}"; echo $C -X DELETE "${U}v1/user/token/${T}"; echo $C "${U}v1/user/token/${T}"; echo

{"status":"ok","token":"72563461-dbe9-3006-01b5-c7c18858bbf6"} {"status":"ok","token":"72563461-dbe9-3006-01b5-c7c18858bbf6","data":{"email":"alice@example.com","login":"alice","name":"Alice Example","phone":"+447700900123"}} {"status":"ok","token":"72563461-dbe9-3006-01b5-c7c18858bbf6","data":{"email":"alice@example.com","login":"alice","name":"Alice Example","phone":"+447700900123"}} {"status":"ok","token":"72563461-dbe9-3006-01b5-c7c18858bbf6"} {"status":"ok","token":"72563461-dbe9-3006-01b5-c7c18858bbf6","data":{"email":"alice@example.com","login":"alice","name":"Alice Smith","phone":"+447700900123"}} {"status":"ok","result":"done"} {"status":"ok","token":"72563461-dbe9-3006-01b5-c7c18858bbf6","data":{}}

Your application keeps only the record token, and the record itself is stored encrypted. Deleting a record ("forget me") erases its data and keeps an empty stub plus the audit trail. Every access is recorded:

U=$(sudo sed -n 's/^DATABUNKER_URL=//p' /root/databunker-credentials.txt)
curl -s --cacert /etc/ssl/databunker/databunker.crt -H @$HOME/databunker-token.hdr "${U}v1/audit/admin" | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["total"], "audit events; latest:", d["rows"][0]["title"])'

13 audit events; latest: delete user record by token

Your counts and the latest event will differ from this output.

Upstream's API documentation describes the full API (consents, legal bases, processing activities, sessions, shared records, user apps). Lookups by e-mail or phone put that value in the request path, and Databunker also writes the path to its own service log. Prefer lookups by token.

Browse to the DATABUNKER_URL address, choose Root Token as the login method, paste the root token, and choose Login.

The console opens on the data-subject requests page. Audit lists every operation on user records. Processing settings manage legal bases (consents) and processing activities.

The console keeps the root token in your browser's local storage for the session. Choose Logout when you are done.

Some console pages load their table and JSON viewer scripts and icons from public CDNs (cdnjs.cloudflare.com, use.fontawesome.com, stackpath.bootstrapcdn.com) without integrity pins. For routine work, prefer the API, or use the console from a browser that you trust.

The configuration is /etc/databunker/databunker.yaml, and it contains no secret. Record creation requires the root token, and every outbound feature is empty:

sudo grep -E '^( create_user_without_access_token| notification_url| server| host| port| url)' /etc/databunker/databunker.yaml

create_user_without_access_token: false notification_url: "" url: "" server: "" port: "" host: "127.0.0.1" port: "3000"

After a change, run sudo systemctl restart databunker. Keep create_user_without_access_token: false on any instance that is reachable from a network you do not control.

What is reachable without the root token. By Databunker's design, the following are reachable: /status, the console's static pages, and /v1/sys/uiconfiguration and /v1/sys/cookiesettings (the console's settings). Recording a consent for an e-mail or phone is also reachable (POST /v1/agreement/<legal-basis>/email|phone/<id>), so a website can capture consent without a login. This route is rate-limited to 30 per minute per client address.

Two kinds of capability links are reachable, and their UUID is the credential: shared records (/v1/get/<record-id>) and expiry links (/v1/exp/retain|delete/<token>). Everything else needs the root token.

Prometheus metrics are only on the loopback address (http://127.0.0.1/v1/metrics), and the public /v1/metrics returns 404.

nginx limits each client address to 50 API requests per second (burst 200). The address is the real TCP peer. A forged X-Forwarded-For header neither changes it nor appears in the log, and the access log replaces every path parameter with :redacted:

sudo grep -E 'limit_req_zone' /etc/nginx/conf.d/sac-databunker-maps.conf
sudo tail -3 /var/log/nginx/access.log | sed -E 's/^[0-9.]+ /<client-ip> /'

limit_req_zone $binary_remote_addr zone=db_api:10m rate=50r/s; limit_req_zone $db_consent_key zone=db_consent:10m rate=30r/m; <client-ip> - - [29/Oct/2026:11:33:45 +0000] "GET /v1/prelogin/:redacted HTTP/2.0" 403 146 "curl/8.5.0" <client-ip> - - [29/Oct/2026:11:33:45 +0000] "GET /v1/metrics HTTP/2.0" 404 146 "curl/8.5.0" <client-ip> - - [29/Oct/2026:11:33:45 +0000] "POST /v1/agreement/:redacted HTTP/2.0" 200 15 "curl/8.5.0"

To change the limits or the 2 MiB request size, edit /usr/local/lib/sac/databunker/nginx-site.tmpl or /etc/nginx/conf.d/sac-databunker-maps.conf, run sudo databunker-set-domain --boot, then sudo systemctl reload nginx.

Point a DNS record (for example vault.example.com) at the instance, then run the following command:

sudo databunker-set-domain vault.example.com

nginx then serves that name, and the instance's EC2 name and addresses keep working. If the certificate is still the SecureAnyCloud self-signed one, a new self-signed certificate is issued for the new name. The credentials file is updated.

To use a certificate from a certificate authority, replace /etc/ssl/databunker/databunker.crt (full chain) and /etc/ssl/databunker/databunker.key (mode 0600, root), then run sudo systemctl reload nginx. The databunker-set-domain command never overwrites a certificate that is not SecureAnyCloud's own. Check the current name and fingerprint with sudo databunker-set-domain --show.

Databunker can let the people whose data you hold sign in with a one-time code sent by e-mail or SMS. That needs a mail or SMS gateway, so on this image nginx closes the login routes (/v1/prelogin, /v1/login, /v1/captcha):

U=$(sudo sed -n 's/^DATABUNKER_URL=//p' /root/databunker-credentials.txt)
curl -s --cacert /etc/ssl/databunker/databunker.crt -o /dev/null -w '%{http_code}\n' "${U}v1/prelogin/email/alice@example.com/123456/00"

403

Before you open the login routes, note their limits. Upstream's login codes are 6 digits with no attempt limit and are written to Databunker's own log, and its captcha is weak.

To open the login routes, configure smtp: (or sms:) in /etc/databunker/databunker.yaml and restart Databunker. Then replace /etc/nginx/sac/databunker-selfservice-off.conf with an empty file and run sudo systemctl reload nginx. The upstream demo identities (test@securitybunker.io and phone 4444, which always receive the code 4444) stay blocked either way.

Upstream's GET /v1/sys/backup returns nothing for this SQLite vault, so the image ships a helper that takes a consistent online copy while Databunker keeps running:

sudo databunker-backup

BACKUP_OK /var/backups/databunker/databunker-20261029T113345Z.db 147456 bytes (records encrypted; back up /etc/databunker/masterkey separately)

The copy (mode 0600, root) holds every record encrypted. Copy it off the instance, and store it separately from /etc/databunker/masterkey, which you must also copy off the instance.

To restore onto an instance, stop Databunker, put the copy in place as the databunker user, keep the master key that encrypted it, and start Databunker again:

sudo systemctl stop databunker
sudo install -o root -g root -m 0600 /path/to/masterkey /etc/databunker/masterkey
sudo -u databunker sh -c 'rm -f /var/lib/databunker/databunker.db-wal /var/lib/databunker/databunker.db-shm; cat > /var/lib/databunker/databunker.db' < /path/to/databunker-backup.db
sudo systemctl start databunker

The root token of the instance that made the backup works against the restored vault.

Databunker is MIT licensed. The image ships its licence, the exact source reference and the build record:

cat /usr/share/doc/sac-databunker/SOURCE.txt sed -n '1,4p' /usr/share/doc/sac-databunker/BUILD-INFO

sac Databunker 0.8.36 appliance - source and third-party notices Databunker (MIT licence, LICENSE-databunker-MIT.txt, Copyright (c) 2020, 2021 Yuli Stremovsky): https://github.com/securitybunker/databunker/tree/1d96827d1cd6faf880f918595cdd104511aa8b7b Upstream publishes no tags or releases; that commit (master, 2026-07-28) carries version.txt 0.8.36. Built from that commit with go1.27.3; no Go source file is changed. Changes (tree-delta.txt, BUILD-INFO): - golang.org/x/image v0.45.0 and golang.org/x/mod v0.40.0 (in-range updates of indirect modules; go.mod/go.sum here); - two files of the embedded web console replaced under the same paths because their licences forbid redistribution: site/fonts/comic.ttf (Microsoft Comic Sans MS, the captcha font) is DejaVu Sans Bold from Ubuntu fonts-dejavu-core 2.37-8 (Bitstream Vera licence, LICENSE-dejavu-fonts.txt), and site/GeoLite2-Country.mmdb (MaxMind GeoLite2) is DB-IP IP to Country Lite 2026-10. IP Geolocation by DB-IP (https://db-ip.com): the DB-IP IP to Country Lite database is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). Databunker is a trademark of its respective owner; sac is not affiliated with or endorsed by it. Databunker 0.8.36 - sac rebuild of the pinned upstream commit source: https://github.com/securitybunker/databunker.git commit 1d96827d1cd6faf880f918595cdd104511aa8b7b (master, version.txt 0.8.36; upstream publishes no tags or releases) (MIT) toolchain: go version go1.27.3 linux/amd64 command: packr v1.30.1; CGO_ENABLED=0 go build -trimpath -buildvcs=false -ldflags="-s -w -buildid= -X main.version=0.8.36-1d96827d1cd6-sac"

Databunker publishes no tagged releases. Version 0.8.36 is upstream commit 1d96827d1cd6 on its master branch, which this image pins. SecureAnyCloud builds the binary from that commit on a separate build host with the current Go toolchain, and the image never contains a compiler. govulncheck reports no known vulnerability in the result.

Two console files are replaced for licensing: the captcha font (DejaVu Sans) and the IP-to-country database (IP Geolocation by DB-IP, licensed under CC BY 4.0). Nothing else changes.

All product and company names are trademarks or registered trademarks of their respective holders. SecureAnyCloud is not affiliated with or endorsed by them.