Security Azure

Databunker on Ubuntu 24.04 on Azure User Guide

Last updated: 2026-08-08 | Product: Databunker on Ubuntu 24.04 LTS on Azure

Overview

Databunker is an open-source, self-hosted secure vault for personal and sensitive data (PII). It exposes a simple HTTP API that stores customer records encrypted at rest, replaces them with tokens (pseudonymization), and adds built-in support for consent management, a personal-data processing register, an access audit trail, and the GDPR right to be forgotten. It is a single Go binary backed by an embedded SQLite database, with a small built-in web console.

The cloudimg image builds Databunker 0.8.36 from source on Ubuntu 24.04 LTS, runs it as the databunker systemd service, and - critically for a vault - generates a unique master encryption key and API root token on the first boot of every VM. No secret is ever baked into the image and no records ship inside it. Backed by 24/7 cloudimg support.

What is included:

Databunker 0.8.36 (built from the pinned upstream source, MIT licensed) with its web console bundled into the binary
Embedded SQLite vault at /var/lib/databunker/databunker.db (a local 0600 file - there is no network database)
A per-VM master encryption key and API root token generated on first boot, recorded in /root/databunker-credentials.txt
databunker.service as a systemd unit, gated so it never serves before first boot has generated the per-VM secrets
The Databunker API and web console on port 3000
24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point. NSG inbound: allow 22/tcp from your management network and 3000/tcp from the clients that will call the API. Databunker is an API service - for production put it behind TLS termination and restrict 3000/tcp to trusted callers.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Databunker by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and a custom 3000/tcp rule. Review + create -> Create.

Step 2 - Deploy from the Azure CLI

Prefer the command line? Create the VM from the published image (replace the image URN with the one shown on your offer's plan page):

az group create --name databunker-rg --location eastus

az network vnet create --resource-group databunker-rg --name databunker-vnet \
  --subnet-name default

az network nsg create --resource-group databunker-rg --name databunker-nsg
az network nsg rule create --resource-group databunker-rg --nsg-name databunker-nsg \
  --name allow-ssh --priority 1000 --destination-port-ranges 22 --access Allow --protocol Tcp
az network nsg rule create --resource-group databunker-rg --nsg-name databunker-nsg \
  --name allow-api --priority 1010 --destination-port-ranges 3000 --access Allow --protocol Tcp

az vm create --resource-group databunker-rg --name databunker \
  --image <offer-image-urn> --size Standard_B2s \
  --admin-username azureuser --generate-ssh-keys \
  --vnet-name databunker-vnet --subnet default --nsg databunker-nsg \
  --public-ip-sku Standard

Step 3 - Connect to your VM

ssh azureuser@<vm-ip>

Step 4 - Confirm the vault service is running

The databunker.service unit starts automatically once first boot has generated the per-VM secrets. Confirm it is active and answering its health endpoint:

sudo systemctl is-active databunker.service
curl -fsS http://127.0.0.1:3000/status && echo

Expected output:

active
{"status":"ok"}

The Databunker vault binary version, the databunker-firstboot and databunker services enabled, the API and web console listening on port 3000, and the SQLite vault file with 0600 owner-only permissions

Step 5 - Retrieve your per-VM root token and master key

First boot generates a unique API root token (authenticates every API call and the web console) and a unique master key (encrypts every stored record). Both are written to a root-only file:

sudo cat /root/databunker-credentials.txt

Expected output (values are unique to your VM):

DATABUNKER_URL=http://<vm-ip>:3000/
DATABUNKER_ROOT_TOKEN=1a2b3c4d-....-............
DATABUNKER_MASTER_KEY=................................

Keep the master key safe. It is the only thing that can decrypt your vault - if you lose it, the stored records are unrecoverable. Store both secrets in your own password manager and treat this file as highly sensitive.

Step 6 - Store your first record (tokenization)

Create a user record by POSTing JSON with the root token. Databunker returns a token - a pseudonymous reference that replaces the raw PII:

XT=$(sudo grep '^DATABUNKER_ROOT_TOKEN=' /root/databunker-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1:3000/v1/user \
  -H "X-Bunker-Token: $XT" -H 'Content-Type: application/json' \
  -d '{"name":"Ada Lovelace","email":"ada@example.com","phone":"+15551230000"}' \
  | jq -r .token)
echo "New record token: $TOKEN"

Databunker refusing an unauthenticated create with an HTTP error, then accepting an authenticated create with the API root token and returning the pseudonymised record token

Step 7 - Read the record back (detokenization)

Look a record up by its token to return the stored PII:

XT=$(sudo grep '^DATABUNKER_ROOT_TOKEN=' /root/databunker-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1:3000/v1/user \
  -H "X-Bunker-Token: $XT" -H 'Content-Type: application/json' \
  -d '{"name":"Grace Hopper","email":"grace@example.com"}' | jq -r .token)
curl -s -X GET "http://127.0.0.1:3000/v1/user/token/$TOKEN" -H "X-Bunker-Token: $XT" | jq .

The response contains the record you stored, decrypted on the fly with the master key.

The Databunker console detokenising a record by its token to reveal the stored personal data, and the right-to-be-forgotten delete returning success

Step 8 - Confirm that unauthenticated access is refused

The image ships with record creation locked to the root token, so a request without a valid X-Bunker-Token is rejected:

curl -s -o /dev/null -w 'unauthenticated create -> HTTP %{http_code}\n' \
  -X POST http://127.0.0.1:3000/v1/user \
  -H 'Content-Type: application/json' -d '{"name":"Mallory"}'

A non-2xx status (for example 401) confirms the vault refuses anonymous writes.

Step 9 - Prove the data is encrypted at rest

Store a record with a distinctive marker, then search the raw SQLite file for that plaintext - it must not appear, because Databunker encrypts every record with the per-VM master key:

XT=$(sudo grep '^DATABUNKER_ROOT_TOKEN=' /root/databunker-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -X POST http://127.0.0.1:3000/v1/user \
  -H "X-Bunker-Token: $XT" -H 'Content-Type: application/json' \
  -d '{"name":"Encrypted Marker 4711","email":"marker4711@example.com"}'
echo -n "plaintext occurrences of the marker in the raw DB: "
sudo grep -a -c 'Encrypted Marker 4711' /var/lib/databunker/databunker.db || echo 0

A count of 0 proves the personal data is stored as ciphertext, not plaintext.

Proof that the stored PII is encrypted at rest: storing a marked record, then grepping the raw SQLite file returns zero plaintext matches and the record bytes are ciphertext

Step 10 - Exercise the right to be forgotten

Delete a record by its token and confirm the personal data is gone:

XT=$(sudo grep '^DATABUNKER_ROOT_TOKEN=' /root/databunker-credentials.txt | cut -d= -f2-)
TOKEN=$(curl -s -X POST http://127.0.0.1:3000/v1/user \
  -H "X-Bunker-Token: $XT" -H 'Content-Type: application/json' \
  -d '{"name":"To Be Forgotten","email":"forget-me@example.com"}' | jq -r .token)
curl -s -o /dev/null -w 'delete -> HTTP %{http_code}\n' \
  -X DELETE "http://127.0.0.1:3000/v1/user/token/$TOKEN" -H "X-Bunker-Token: $XT"
echo -n 'personal data still present after forget? '
curl -s -X GET "http://127.0.0.1:3000/v1/user/token/$TOKEN" -H "X-Bunker-Token: $XT" \
  | grep -q 'To Be Forgotten' && echo YES || echo NO

A delete -> HTTP 200 followed by NO confirms the record's personal data was erased.

Step 11 - Use the web console

Databunker ships a built-in web console. Browse to http://<vm-ip>:3000/, choose the Root Token method, and paste the DATABUNKER_ROOT_TOKEN from Step 5 to reach the admin views.

The Audit view shows the access trail - every operation that read or modified a record, who performed it and when:

The Databunker web console Audit view listing the access trail of operations that read or modified user records, with timestamps and the acting identity

Individual records are returned decrypted for authorized viewers, so you can inspect exactly what personal data is held for a subject:

The Databunker web console displaying a decrypted personal-data record with its name, email, phone and address fields

The Processing settings view manages your personal-data processing operations and their legal basis, supporting your GDPR record of processing activities:

The Databunker web console Processing settings view for managing personal-data processing operations and their legal basis

Maintenance

Configuration lives in /opt/databunker/conf/databunker.yaml (retention policy, SMS/SMTP for user access codes, UI branding). Edit it, then restart the service with sudo systemctl restart databunker.
Back up the SQLite vault at /var/lib/databunker/databunker.db and the master key at /etc/databunker/masterkey together - a backup of the database alone is useless without the key.
OS updates are delivered by Ubuntu unattended-upgrades. Apply the latest security updates with sudo apt-get update followed by a manual review.
Databunker's own record-retention and expiry policies run automatically per the policy block in the config.

Support

This image is published and supported by cloudimg with 24/7 support. If you have any questions or run into issues, contact us at support@cloudimg.co.uk.