Reading · 5 min · Module 6, lesson 4 of 510 min left in this module
Module 6 · SecretsLesson 4 of 5
Goal: Choose a secret rather than a variable for sensitive values on ComputeSphere, and know what the console and API show once it's saved.
Key idea
On ComputeSphere, a value that grants access goes in as a secret, not a variable. Secrets are write-only: once saved, the console and the API show only the name, never the value. Your app still receives the real value when it starts.
You haven't deployed anything yet, so there's nothing to click here. Lesson 5.4.1 walks through the same screens once you have a service.
Where secrets go
Lesson 2.4.4 showed the two places values live: on a service, or shared across an environment so every service in it inherits them. Both places have a variables list and a secrets list:
A service: its Settings, in the Environment variables card, on the Secrets tab.
An environment: its Settings tab, in the Shared Variables & Secrets card.
Use lesson 2.6.1's test to choose. LOG_LEVEL is a variable; PAYMENT_API_KEY and DATABASE_URL are secrets.
What you see after saving
The console lists each secret by name, with dots where the value would be. Variables show their values in full; secrets never do.
The API follows the same rule. Asking for a service's variables returns every variable with its value, and every secret with an empty one:
So nobody with access to the project can read a secret back: not a teammate, not a script with an API token, and not you. Your app is the one place the real value arrives, as an ordinary environment variable (process.env.PAYMENT_API_KEY).
What that means for you
Keep the real value somewhere you control, such as a password manager. If you lose it, set a new one; ComputeSphere can't give the old one back.
To change a secret, enter the new value. It reaches the app on the next redeploy, as with any variable (lesson 2.4.4).
Rotating is the same move: set the new key, redeploy, then revoke the old key at the provider (lesson 2.6.3).