Databunker: Self-Hosted Tokenization for Sensitive Customer Records

Why Databunker Moves PII Out of the Main Database

Databunker addresses applications that need to reference customer identity, health, financial, or KYC records without keeping those values directly in the primary database. Its intended users are backend teams adding a privacy-oriented data boundary to profiles, healthcare workflows, financial services, identity systems, and consent-related services. The project presents itself as a GDPR-oriented tool, while the README also describes CCPA, HIPAA, and PCI DSS use cases. Those are project claims, not an independent determination that deploying the software makes a particular system compliant.

The core problem is data concentration. A conventional application database commonly stores an account identifier beside fields such as an email address, phone number, name, or identity evidence. Databunker instead creates a separate encrypted vault. An application submits a sensitive record through the API and receives a UUID token. That token can be associated with the application record without reproducing the protected values in the main database.

The README also challenges storage encryption by itself. It argues that block encryption can leave plaintext exposed through API paths, GraphQL filtering, or SQL injection. Databunker responds by putting record operations behind its own API, encrypting records, indexing selected lookup values through hashes, and restricting bulk retrieval by default. These controls reduce the amount of sensitive material available to the application database, although the documentation does not provide an independent threat model or implementation-level explanation of every control.

Databunker's Token, Encryption, and Lookup Flow

The documented flow has four distinct stages. First, a client calls the Databunker API to submit a personal record. Second, Databunker encrypts the stored record and returns a UUID token. Third, the application persists that token if it needs to associate the vault entry with local application state. Fourth, authorized API calls retrieve a record by that token or through a supported indexed field such as login, email, or phone.

This arrangement creates two different representations. The application database can retain ordinary non-sensitive records plus a UUID reference. Databunker owns the sensitive representation, which the README says is encrypted with AES-256. Secure indexing supports lookups without presenting indexed values as the plaintext contents of the main database, although the available documentation does not specify the hash construction, normalization rules, collision policy, or secret-management procedure.

The vault is implemented in Go and exposes a REST API described as NoSQL-like. The repository lists an OpenAPI specification and supports MySQL and PostgreSQL. Its container exposes port 3000 and includes a health check. The Dockerfile builds a Go executable in an Alpine builder stage and copies the executable, configuration, runtime shell utilities, OpenSSL libraries, and certificate data into a smaller runtime image. The runtime runs as `appuser` and declares `/databunker/data` as a volume.

The security boundary is the API itself. README claims include authentication through `X-Bunker-Token`, fine-grained permissions, audit logging, injection protection by design, and disabled bulk retrieval by default. A deployment therefore depends as much on protecting API credentials, endpoint authorization, network access, and configuration as it does on record encryption.

Running the Container and Creating a First Record

The README's quickest documented path uses Docker and starts the image with the `demo` argument. The command publishes container port 3000 on the host and names the container `dbunker`. The reader should see a running container after the image has been pulled and started.

docker pull securitybunker/databunker
docker run -p 3000:3000 -d --rm --name dbunker securitybunker/databunker demo

The next request creates a user record. It sends the demo API token in `X-Bunker-Token`, declares JSON in `Content-Type`, and posts `first`, `last`, `login`, and `email`. A successful call returns a response that should include the created record's token or identifier, although the README does not show the exact response body.

curl -s http://localhost:3000/v1/user -X POST \
  -H "X-Bunker-Token: DEMO" \
  -H "Content-Type: application/json" \
  -d '{"first":"John","last":"Doe","login":"john","email":"[email protected]"}'

The record can then be requested by the indexed `login` value. The same API token is passed in the request header, and the path ends with the login created in the previous request.

curl -s -H "X-Bunker-Token: DEMO" -X GET http://localhost:3000/v1/user/login/john

The README identifies `http://localhost:3000` as the admin UI. The `DEMO` token and `demo` container argument are tutorial configuration, not documented production credentials or a production startup procedure. Before using real records, an operator needs a production configuration from `databunker.yaml`, database setup, non-demo credentials, and an assessment of persistence and backup behavior.

Database Deployment, Persistence, and Configuration Boundaries

The repository contains separate Docker Compose files for MySQL and PostgreSQL, SQL setup material, Helm charts under `charts/`, Terraform files, and environment-file generation scripts. This layout supports several deployment styles, but the available documentation does not state when those options were introduced or provide a release-specific upgrade sequence. The repository has no GitHub releases, so operators cannot infer a stable tagged upgrade path from the release history shown here.

The container declares `/databunker/data` as a volume. That establishes a location for persistent container data, but it does not by itself explain which files are written there, how encryption keys are supplied, how database records are backed up, or how a restore is verified. The README separately lists automated backups and high availability as technical specifications, yet it does not provide commands or configuration for either subject in the available text.

`databunker.yaml` is central to the runtime because the Dockerfile copies it into `/databunker/conf/`. The available excerpt does not expose that configuration file's keys, so no storage mode, database connection setting, encryption-key variable, or production authentication option should be guessed. The project also includes `health-check.sh`, which the Dockerfile invokes every five seconds after a 33-second start period, with a three-second timeout and three retries.

There is a maintenance concern in the build process. The Dockerfile installs `github.com/gobuffalo/packr/packr@latest`, so image rebuilds can depend on an unpinned tool version. This does not establish a defect, but it makes reproducible builds harder to assess from the file alone. Pinning and compatibility procedures would need to be verified in `BUILD.md` or the project's build configuration.

Where Databunker's Security Claims Need Verification

Databunker makes several broad protective claims that deserve careful scope. It says AES-256 encryption protects personal records, tokenization removes plaintext values from application storage, and hash-based indexing supports secure queries. It also says the design blocks SQL and GraphQL injection exposure and disables unrestricted bulk retrieval by default. The README does not explain whether Databunker itself accepts GraphQL input, whether injection protection applies to every stored field, or how a hash-index collision is handled.

Authentication is visible only at the level of the API token header in the quick-start example. The README also mentions fine-grained permissions and audit logging, while `API.md` is listed as a separate API reference. Without the contents of those files, it is not possible to verify token issuance, role definitions, token rotation, audit retention, session behavior, or authorization rules. A self-hosted deployment also adds infrastructure controls outside the vault, including network exposure, database access, operating-system hardening, certificate handling, backups, and secret storage.

The documentation's assertion that setup can be completed in under ten minutes conflicts stylistically with its own five-minute title, but this is not an important distinction. The larger issue is scope. A running demo container proves only that the image and API can start in the shown configuration. It does not establish encryption-key management, production availability, disaster recovery, retention workflows, or regulatory conformity. Compliance also depends on the surrounding application, contracts, procedures, access reviews, and the data itself. The README should be read as a statement of intended capabilities, not as the evidence needed for a compliance decision.

Databunker Versus Keeping Records in an Application Database

The relevant alternative is not another named vendor. It is the conventional pattern in which the main application database retains encrypted fields and performs direct lookups. That approach has fewer operational components because the application already owns its database, query layer, backups, and connection credentials. It can also support arbitrary SQL relationships without routing protected fields through a separate service.

Databunker takes a different architectural approach. It separates sensitive records behind a dedicated API, substitutes UUID tokens for references in the application database, and offers controlled lookup through hash-based indexes. This can reduce the number of plaintext PII fields exposed to the application's primary query surface. It also introduces another stateful service, another authentication boundary, and another set of consistency and recovery concerns. Cross-service deletion and update workflows must preserve the relationship between local tokens and vault records.

Databunker is the better fit when isolating sensitive records is an explicit architecture goal and the team can operate Docker plus a supported database. The conventional application database remains simpler for smaller systems that already have strong access controls, parameterized queries, field encryption, tested backups, and no need for a separate privacy vault. For payment-card tokenization specifically, the README directs users to Databunker Pro, which is outside the MIT project described here.

Maintenance Signals and MIT Upgrade Considerations

The repository is not archived, and its last push was on 2026-07-28. That supports describing the repository as recently changed, but the documentation does not identify a release cadence or a stable-release policy. There are no GitHub releases to map container images, database migrations, or API changes to versioned milestones. The checked-in `version.txt` may participate in the build, but its value and release process are not included here.

The MIT license permits use and modification under its terms, including commercial use as stated by the README. It does not itself establish regulatory compliance, suitability for protected data, or availability of enterprise functionality. Databunker Pro is specifically called out for credit-card tokenization and enterprise features, so adopters must confirm that the required capabilities exist in the edition they intend to deploy.

Upgrade planning must account for at least three repository surfaces: the Go API and UI, the MySQL or PostgreSQL state, and persistent container data. The presence of database setup scripts and compose files indicates deployment state beyond the binary, while the lack of release notes leaves migration and rollback requirements unspecified. The README does not document rollback, upgrade sequencing, encryption-key rotation, or version compatibility. Those details must be established from `INSTALLATION.md`, `API.md`, `databunker.yaml`, and applicable database migration files before replacing an existing deployment.

Editorial conclusion

Databunker is appropriate for teams that want to move sensitive customer records behind a dedicated, self-hosted API and can operate Docker, MySQL, or PostgreSQL. It is less suitable for teams expecting the MIT edition to include credit-card tokenization, enterprise controls, or enough configuration documentation to establish compliance without validation. Review databunker.yaml, API.md, the selected database configuration, authentication settings, backup procedures, and the boundary between Databunker and Databunker Pro before production adoption.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. securitybunker/databunker on GitHub