Why we're keeping Dopbase's secrets model small

Secrets managers have a habit of growing into much larger infrastructure platforms. Certificate management, machine access, identity, policy, and deployment controls can all end up inside the same product.

We built Dopbase for a narrower job: store application secrets and deliver the right environment to a process.

That leaves three main concepts:

Project
  └── Environment
        └── Secrets

A project is an application or service. An environment separates the values used in development, staging, or production. Each secret has its own record instead of being one line in an opaque file.

Keep what developers understand about .env

A .env file is hard to beat on one machine. The trouble starts when developers, CI jobs, and application servers each keep a separate copy. Values drift, old credentials remain active, and tracing a change means reconstructing what happened across several systems.

Dopbase treats .env as an import and export format rather than the storage model. An authorized user can update, audit, or reveal one secret without replacing an entire file.

The client always receives an explicit environment:

dopbase run payment-service/development -- npm start

Readable references such as payment-service/development work well at the terminal. Deployments can use an immutable environment ID so a rename does not silently change the target.

Keep self-hosting understandable

The Community edition packages the server, Admin UI, REST API, migrations, and command-line client in one executable. Start a local or self-hosted server with:

dopbase serve

Operating a secrets server still requires careful choices about TLS, master-key storage, backups, monitoring, and upgrades. One binary reduces packaging complexity. It does not remove those responsibilities.

The same client works with a local server or an independent self-hosted deployment. Dopbase Cloud will use the same client and model when it becomes available.

Leave unrelated infrastructure outside the product

Dopbase is not intended to become a certificate authority, SSH access platform, database proxy, identity provider, or Kubernetes management layer. Those tools solve real problems, but combining all of them would make Dopbase harder to understand, secure, and operate.

The product stays inside the application-secrets workflow: authentication, permissions, auditing, encryption, reliability, the REST API, the Admin UI, and the CLI.

Let people verify the implementation

Dopbase is open source under the Apache License 2.0. The public repository contains the Rust server and CLI, the Vue Admin UI, database migrations, tests, and product documentation.

Anyone can inspect how Dopbase stores encrypted values, separates master-key material, authorizes requests, and records audit events. Public code does not prove that software is secure, but it makes those claims available for review instead of asking users to accept them on trust.

Keeping the model small gives us a clear standard: a developer should be able to see where a value belongs and understand how it reaches the application.