dopbase serveServer
The server contains the API and Admin UI, stores encrypted secrets in SQLite, and handles authentication and audit records.
Open source
Secrets managerin a single file.
Dopbase packages the server, Admin UI, REST API, migrations, and CLI in one executable. It organizes credentials by project and environment, then passes them to an application without writing another.env file.
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 / developmentJust 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.
projectpayment-service
environmentdevelopment
environmentstaging
environmentproduction
DATABASE_URLSTRIPE_SECRET_KEYREDIS_URLOne executable, two roles
The server stores the data. The client requests it.
dopbase runClient
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.
