dopbase serve Server
The server contains the API and Admin UI, stores encrypted secrets in SQLite, and handles authentication and audit records.
Secrets management for developers
Secrets manager in a single file.
Drop your .env and keep your secrets in a safe place. Dopbase
organizes them by project and environment, then loads the right values into
your application process with one command.
Dopbase is open source by design. its encryption, storage, and secret delivery mechanism are fully inspectable.
# one executable, two roles
$ dopbase serve
# import an existing environment
$ dopbase init api development --from .env
# run without writing secrets to disk
$ dopbase run api/development -- npm start
resolved context
api / development Just run
- 01Serve
Run a local server or use a remote Dopbase endpoint.
- 02Connect
Point the command-line client at that server.
- 03Manage
Organize secrets by project and environment.
- 04Run
Deliver that environment to an application process.
Why Dopbase
A .env file works until its copies start drifting apart.
One file on one machine is simple. Once a team, its CI jobs, and its servers all have separate copies, values drift and old credentials hang around. It also becomes difficult to tell who changed what.
Dopbase keeps the familiar key and value model, then adds encrypted storage, access controls, audit records, and process delivery.
The Dopbase model
Project. Environment. Secret.
A project represents an application or service. Environments separate development, staging, and production values. Each secret has its own record instead of being hidden inside one opaque file.
project payment-service
environmentdevelopment
environmentstaging
environmentproduction
DATABASE_URL STRIPE_SECRET_KEY REDIS_URL One executable, two roles
The server stores the data. The client requests it.
dopbase run Client
The client connects to the server, selects an environment, and passes its values to an application process.
Choose who runs the server
Self-hosting is part of the product.
Practical guides
Secrets management and safer AI coding
How to keep secrets out of an AI coding workspace
Use fake values for routine agent work, isolate credentialed tests, and deliver restricted development secrets only after reviewing the code.
Why development should not use production secrets
Separate development and production credentials so a mistake on a laptop, test runner, or coding agent cannot reach live systems.
Committed a secret? Revoke it before cleaning Git history
Deleting a committed secret does not disable it or remove it from Git history. Revoke or rotate it first, then clean the repository.
