Deployments · Secret managers

Secret managers

Keep your secrets in the secret manager you already use and point a service at them. ComputeSphere reads each value when the service deploys, stores it encrypted and never shows it. Your secret manager stays the place you change it.

How it works

Step	What happens
Connect	You connect a secret manager to your account with a credential that can read it, and choose the projects and environments that can use it.
Reference	On a service or an environment, a secret is set from a secret manager: its name in your service, plus the key to read.
Deploy	Every deploy, redeploy, restart and build reads each referenced value again and stores it encrypted with the service's other secrets.
Run	The running service gets the value like any other secret variable.

A change reaches your service on its next deploy or restart. Changing a value in your secret manager doesn't restart anything on its own: redeploy or restart the service when you want the new value live.

Supported secret managers. Each has its own page with the steps to connect it:

Secret manager	Sign-in method	What you choose	Guide
Doppler	Service token	A project and a config	Connect Doppler

Your account's secret managers

Connect a secret manager once and use it in as many projects as you choose. Your account's owners and admins connect and change these in Settings → Secret managers.

1. Open Settings → Secret managers and click Connect a secret manager.
2. Fill in the Name, Type, settings and credential (each secret manager's page lists them: Doppler). A name is used once in your account.
3. Under Where it can be used, choose All projects, including new ones or Choose projects. For each project, pick all its environments or some of them. A secret manager can be allowed in up to 500 projects.
4. Click Connect. ComputeSphere tests the connection first: if the secret manager doesn't accept it, nothing is saved and the message says why.

All projects, including new ones covers projects created later by your account's owners or admins.

A new credential or new settings are tested the same way before they're saved. Leaving the credential empty keeps the stored one, unless the new settings point somewhere else: then enter the credential again. The stored credential is never sent to a new address.

In a project, the Secret managers page lists the secret managers the project can use, and Add secret offers them. Project members can use them; only your account's owners and admins connect or change them, in Settings → Secret managers.

Take a project or environment off the list with Where it can be used. This is refused while secrets there still read from it: each project or environment that still has secrets reading from it shows how many. Remove those secrets, or set them to values, then try again.

Secret managers your projects connected before show in Settings → Secret managers too, and are changed there.

Every connect, change, change to where it can be used, test and removal shows in your account's audit log.

When a project moves to another account

• A secret manager only that project uses moves with it, unless it's set to All projects. Before the transfer, the sending account sees which ones move: their credentials stay encrypted and are never shown, and the receiving account can use their connections. To keep one out of the transfer, disconnect it first.
• A secret manager the project shares with other projects, or one set to All projects, stays with the sending account, and the project leaves its list.
• The transfer waits while secrets in the project still read from a secret manager that stays. Point those secrets at another secret manager, or remove them, first.

Use a secret from a secret manager

On a service:

1. Open the service, then Settings → Variables → the Secrets tab.
2. Under From a secret manager, click Add secret.
3. Enter the Name the service sees (for example DATABASE_URL), choose the Secret manager, and enter the Key: the secret's name in that secret manager. It defaults to the name you entered.
4. Click Save. The service redeploys and reads the value.

On an environment: open the environment's shared variables and add the secret the same way. The environment's services redeploy and each one gets it, except a service that sets a secret with the same name itself: the service's own value wins.

When you create a service: on the Variables step, open the Secret variables tab and import a .env with links (below). The service's first deploy reads them.

When you add a service to another environment: secrets the service reads from a secret manager come over as the same links, so the new environment follows the secret manager too. Secrets with values are asked for again. The secret manager must be one the new environment can use.

Each secret from a secret manager shows its state:

State	Meaning
Synced	The last read worked. The service runs the value it read.
Using last value	The secret manager didn't answer at the last read. The service keeps the last value it read, and the console shows since when.
Can't read	The secret manager gave a definite answer, for example the key no longer exists or the token was revoked. The message says which.

Import a .env with links

To link many secrets at once, import a .env file on a service's Secrets tab, on an environment's shared secrets, or on the New service form. A line can set a value, as before, or link the name to a secret in a secret manager:

# Reads DATABASE_URL from app-doppler
DATABASE_URL=ref://app-doppler
# Reads STRIPE_LIVE_KEY from app-doppler, as STRIPE_KEY
STRIPE_KEY=ref://app-doppler/STRIPE_LIVE_KEY
# A value, saved as written
FEATURE_SALT=a-value

1. Open the service, then Settings → Variables → the Secrets tab, and click Edit.
2. Click Import .env and paste the file.
3. Check the rows under the box. Each row shows Value or Link (with the secret manager and key), and its button switches it to the other.
4. Click Import, then Save. Choose Save & redeploy to deploy now (or Save & rebuild when the change has to reach the build), or Save only to deploy later.

On an environment, open its shared variables, then the Secrets tab, click Edit, and follow the same steps. When you click Save, the environment's services restart once with the links and the values together.

How a line is read:

• NAME=ref://<secret manager> links NAME to the secret of the same name in that secret manager.
• NAME=ref://<secret manager>/<key> reads <key> instead. Everything after the secret manager's name is the key, slashes included.
• A quoted value is a value. DOCS_LINK="ref://app-doppler/x" saves the text ref://app-doppler/x.
• A link to a secret manager the project can't use is an error on its row, never saved as a value. A key can't contain #.

Link all to a secret manager turns every pasted value into a link with the key set to its name, and removes those values from the page at once. It leaves out:

• names that start with DOPPLER_, which set up the Doppler CLI rather than your app;
• names that look like a secret manager's own credential, such as VAULT_TOKEN or AWS_SECRET_ACCESS_KEY. Click Include to import one as a link.

When you save, the links are saved first, all or nothing. If a secret can't be read, nothing is saved, and its row says why. Then the values are saved. With Save & redeploy, one deploy then delivers both. A save takes up to 100 links.

A value you turn into a link never leaves your browser: only the link is sent.

When the secret manager doesn't answer, or says no

No answer (an outage, a timeout, rate limiting): the deploy goes ahead with the last value read, and the secret shows Using last value. There's no time limit on the last value: a long outage on the secret manager's side doesn't take your service down.

A definite answer (the key was deleted, access was revoked, the token no longer signs in): the deploy is refused before anything changes, and the version that's running keeps serving. The deploy's error and the secret's Can't read state say which secret and why. Fix it in your secret manager, or change or remove the reference, then deploy again.

Values are never shown

ComputeSphere never shows a secret read from a secret manager: it's not in the console or API responses. There's no Show value for it. To check a value, look in your secret manager. (Your own application can still print it, as with any secret variable.)

Remove a secret manager

Open Settings → Secret managers, choose Remove from the secret manager's menu, and confirm. Removing is refused while secrets still read from it: remove those secrets, or set them to plain values, first. After removal, services and environments can't read from it, and its stored sign-in details are deleted.

Current limits

• One secret manager type today. Doppler is the secret manager you can connect. More types get their own page here as they open.
• No live sync between deploys. A change in your secret manager reaches the service on its next deploy or restart.
• Console and API. The CLI has no commands for secret managers.

Next

• Connect Doppler: the service token, the project and config, and Doppler's own errors.
• Environment variables: plain and secret variables, scopes, and shared variables across an environment.
• Service actions: redeploy and restart a service.
• Security: how secrets are stored and protected.