Databunker

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting size.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 3000/tcp from the clients that will call the API. Databunker is an API service, so 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 SecureAnyCloud, and select Create.

On the Basics tab, 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 add a custom 3000/tcp rule.

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

To use the command line instead, 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
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:databunker-ubuntu-24-04:default:latest
az vm create --resource-group databunker-rg --name databunker \
  --image sac1647283583153:databunker-ubuntu-24-04:default:latest --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 that 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"}

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). First boot writes both 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=<set-at-first-boot> 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 sending a POST request with JSON and 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"

Step 7 - Read the record back (detokenization)

Look up a record 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.

Step 8 - Confirm that unauthenticated access is refused

The image locks record creation 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 - Verify the data is encrypted at rest

Store a record with a distinctive marker, then search the raw SQLite file for that plaintext. The marker 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 confirms that the personal data is stored as ciphertext, not plaintext.

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

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

Step 11 - Use the web console

Databunker includes 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.

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

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

Maintenance

• Configuration: settings live in /opt/databunker/conf/databunker.yaml (retention policy, SMS/SMTP for user access codes, UI branding). Edit the file, then restart the service with sudo systemctl restart databunker.
• Backups: 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: Ubuntu unattended-upgrades delivers OS updates. Apply the latest security updates with sudo apt-get update followed by a manual review.
• Retention: Databunker's own record-retention and expiry policies run automatically, according to the policy block in the config.

Support

SecureAnyCloud publishes this image and provides 24/7 support for it. If you have questions or run into issues, contact sales@secureanycloud.com.

Deploy on Azure

Launch Databunker on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com