The Secrets guide

Secrets keeps the keys your apps need: database addresses, payment keys, email API keys, and the rest of a .env file.

Each environment, such as Development, Staging and Production, has its own key, so access to one never opens another.

Everything in Secrets belongs to a project: its secrets, servers, keys and certificates. Pick it with Project at the top of any Secrets page, and every page follows it. All projects shows everything you are in.

• A project’s admins add servers, keys and certificates; its members use them and ask for access.
• The company owner and its admins see every project in the company, even ones they are not in, and can join any of them as an admin in one step.
• Joining gives the servers, keys and certificates at once. The secrets stay sealed until someone who holds the keys passes them on from the project’s People tab. The project’s admins are told.
• Insights lists what needs attention across the projects you look after: keys only one person holds, things about to end, rotations that stopped, leaks found in code and access nobody uses. Each line opens the place to fix it.

A machine is a server, a CI job or a script that reads secrets without a person. Each gets its own token, reads only the environments you choose, and shows in Activity every time it reads.

• Start any command with its secrets: dbrij secrets run -- npm start. The token stays out of the command.
• Export them as .env, JSON, YAML or a Docker env file, compare with a local .env, or push a file into an environment.
• In GitHub Actions, log in with GitHub instead of storing a token: only the key half is saved as a repository secret.
• On AWS, Google Cloud, Azure or Kubernetes, a machine can log in as the identity its cloud already gave it, so no login secret is stored on it at all.
• From your own code, use the Dbrij Secrets library for Node, Python or Go. Each keeps serving the last good copy if Dbrij cannot be reached for a moment.
• An AI assistant in your editor can call an API with a key it never sees: list on the key the hosts it may go to, and it is sent nowhere else.
• Moving from dotenvx? Push the encrypted file with the command line: it opens it on your machine with your own key, and the key never leaves.
• People can use the command line too, after dbrij login: it asks for your vault passphrase once and remembers it on that device for a few hours.

An environment is sealed: only the people and machines holding its key can open it. For Dbrij to put values into a deploy or replace a key for you, an admin lets Dbrij open that environment, for the reasons they choose, in Settings. Every time Dbrij opens it, the reason is in Activity.

• In Connections, link a Hosting service to an environment. Every deploy gets its values, the service’s own variables still win on a name both set, and a change redeploys it, at most once every two minutes.
• If a deploy with new values fails, the service goes back to the last version that ran and stays there until you send the latest again. The change stays in Secrets for you to fix.
• Move a service’s own variables into Secrets in one step. Its old variables are kept for 30 days and can be put back.
• A secret holding a Send, Ping, Resolve, Finance or Developer API key can rotate on a schedule. The old key keeps working until every reader has the new one and the grace period has passed.
• A Postgres or MySQL database outside Dbrij can have its password rotated too: the rotation switches between two of its users, so the app always has one that works.
• Instead of keeping a database password, lease a user of a Hosting Postgres or MySQL for an hour with dbrij secrets lease and the name an admin gave the database in Connections. It is removed when the lease ends, and every lease is in Activity.
• In the company vault, Use in an app copies a password into Secrets. One unlock opens both.
• When somebody leaves the company, their keys go at once and the admins get a task listing what to replace.

A sync keeps one folder of an environment in step with a service outside Dbrij: GitHub Actions, GitLab CI, the hosting and edge platforms you may also deploy on, AWS Secrets Manager and Parameter Store, Google Cloud Secret Manager, Azure Key Vault, Coolify, Supabase, or a .env file on your own server over SSH. Add an integration shows the full list.

• Add the service once, in Integrations: a token you make there, or for GitHub the GitHub you already connected in Dbrij. Choose which projects may use it, so nobody adds the same access twice. Dbrij checks it with the service before saving it, keeps it sealed, and never shows it again.
• An admin lets Dbrij open the environment for syncs in Settings: the values are opened only in the memory of each run, and every opening is in Activity.
• Choose the folder (and the folders inside it), where it goes, and how names look there, for example APP_{key}. Only names that fit are ever touched: anything else in the destination is left alone.
• Before the first run, see exactly what it would create, change and delete. Two folders giving the same name, or a name the service refuses, stop the run before anything is written.
• After every change it runs again once things are quiet for ten seconds. Where a service only reads variables when it deploys, the sync can start a deploy and waits until it is live.
• Every six hours it checks the service against what it delivered. Drift can be overwritten, brought into Dbrij where the service shows values, or left.
• A busy service is tried again at 1, 5 and 30 minutes and 2 hours. A refused token pauses every sync of its integration with one alert; a renamed or deleted target stops its sync. Admins are told by email, and a company channel can follow the project to hear it in Chat.

In a company project, protect an environment such as Production in Settings, then choose who approves its changes under Approvals: project admins, people you name, or anyone given a role that may approve.

• A save to a protected environment becomes a request. Its approvers are asked by email and with a card in Chat, see exactly what changes, and the last approval needed applies it as one change.
• Nobody approves their own change unless you allow it. A request nobody approves closes on its own after the days you choose.
• If a secret it changes was saved again in the meantime, nothing applies: whoever proposed it brings it up to date, and its approvals start again.
• In an emergency, a person you named applies it at once with a reason, after confirming it is them. It is marked in History, and every approver and admin is told.
• Anyone in the company can ask for access to an environment, for a few hours or until it is taken away. Approved, it starts at once and ends on its own.
• Approve changes and access from your phone too: in the Dbrij app, open Company, then Secrets approvals. Values never leave the web.
• Ask somebody outside for a value with a link. They paste it, it is sealed in their browser to a key only you hold, and you save it into an environment.
• Give any secret a date to be replaced by, or a reminder every few days. Insights lists what needs attention: old secrets, unused access, idle machines and environments with too few key holders.

• A template is a value built from other secrets, like a database address made from its user, password and host. Type ${ in a value to pick the names, then save it as a template.
• It can use a secret in another folder or another environment, and it is filled in where it is read, on your machine. One you cannot read is an error that names it, never an empty value.
• A folder can import other folders, so /api gets everything in /shared without copying it. Its own values win.
• Deleting a secret a template uses warns you first, and names the template.

• Run dbrij secrets scan to find secrets written into a folder, its staged changes or its history. It can also put itself in front of every commit, so a secret is caught before it is saved.
• Every push to Dbrij Source is scanned. A repository warns by default; its settings can block the push instead. Secrets found lists what was pushed, never the value.
• Plant a decoy key in an environment under a name an intruder would try. It opens nothing, and the moment anybody uses it the admins are told.
• Download a project’s Activity as CSV or JSON for any dates your plan keeps. On Business, stream it as it happens to an address of your own, signed so you can trust it.

• Every save is kept as a version, with who made it and when.
• Open any change in History and put back what was there before it. The restore is a change too, so it can be undone.
• Each secret has its own list of versions; any one can be put back into the editor.

• People are billed; machines, pipelines and servers are free on every plan.
• Free holds 3 people and 3 projects. Team and Business are priced for each person in your projects.
• Every safety feature is on every plan: roles, temporary access, approvals, history, the activity trail and its export, rotation, leases, decoys and share links. Streaming the trail is on Business.
• On Team and Business, key operations and recorded server hours grow with each person. Past the key operations you are told and nothing is refused; past the recorded hours new sessions wait for the next month, and breaking glass always works.
• The company owner is not billed for a project they joined only to look after it.
• A limit only stops something new. Reading values, deploys and syncs already running never stop, and nothing is deleted when a plan gets smaller.
• Choose or change the plan from Plan on the Secrets home, or from Billing.