On ComputeSphere: service variables and when a change needs a redeploy

You haven't deployed anything yet, so there's nothing to click here. This is the picture to carry into Path 5, where lessons 5.4.1 and 5.4.2 cover the same ground step by step.

Where values live

Each environment (say, staging and production) has its own shared variables and secrets, and every service in it inherits them. A service can set the same key itself, an Override, and its value wins. Production values never appear in staging.

There are two kinds of value:

• A variable is for settings that aren't sensitive, like LOG_LEVEL. Anyone on the project (the group of environments and services that make up one app) can read it.
• A secret is for anything that grants access, like API_KEY. It's write-only: once saved, nobody can read the value back.

Your app can't tell them apart. Both arrive as ordinary environment variables, read with process.env or os.environ as in lesson 2.4.2.

When a change takes effect

Saving a value stores it. The running app still has the values it started with, and only a redeploy starts it again with the new ones. Redeploys are rolling: new spherelets start before the old ones stop, so the app stays up.

• A service's variables or secrets: when you save in the console, it asks Apply changes? Save & redeploy applies the change. Save only saves it without applying it; the app keeps the old values until the next redeploy.
• Shared variables or secrets on an environment: saving redeploys every running service in that environment for you. A stopped service gets the new values when it's next started, and a cron job on its next run.
• NEXT_PUBLIC_… or VITE_… variables: these are copied in at build time (lesson 2.4.3), so they need a redeploy that builds again. On a service built from a repository, the console offers Save & rebuild when you save one.