ComputeSphereLearn
Console
Learning paths / Deploy on ComputeSphere / Configuration and secrets

Which changes need a redeploy

Reading · 5 min · Module 4, lesson 2 of 430 min left in this module

Module 4 · Configuration and secretsLesson 2 of 4

Goal: Predict whether a change reaches your running app straight away, on the next redeploy, or only after a new build.

3:11 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll know when a change reaches your running app, and what it takes to get it there. We'll change a variable, and watch it happen for real.

Here's our service, the sample API. It's Running, and it answers with a greeting. Right now it says Hello, world. That's its default, because no greeting is set yet. And API key set is false. It has no secret either.

[00:27] Save a variable

In the console, open the service's settings. Here's the Environment Variables card. Choose Edit, and add the greeting variable, set to Hello from ComputeSphere. Then Save.

The console asks, Redeploy to apply changes? There are two answers. Redeploy now saves the change, and rolls it out. Later only saves it. Let's choose Later, and see what that means.

[00:54] Saved isn't running

The variable is saved. Settings shows it, right here. But let's ask the app again.

Still Hello, world. Nothing is broken. Your app reads its variables once, when it starts. And it hasn't started with this one yet. So if Settings and the app disagree, redeploy first.

[01:16] Redeploy now

Let's add the secret too. On the Secrets tab, add the API key, with a made-up value. Save, and this time, choose Redeploy now. One rollout applies both changes. That's what Later is for: several changes, one redeploy.

Behind the scenes, new spherelets start next to the old one. The old one stops only once they're healthy. So your app stays up, and Running, the whole time. And here's the secret, saved. Just its name, and dots.

Let's ask one more time. Hello from ComputeSphere. And API key set is true. The key itself never shows up. The app only tells you it's there.

[02:01] Which changes need what

So, which changes need what? A service's variables or secrets, in the console: choose Redeploy now. From the CLI, the service redeploys for you. The environment's shared variables redeploy every running service in it, automatically. For the spherelet count, choose Apply now. No build, just more or fewer copies. And your code needs a new build. That's Redeploy, then Build and Deploy. The same goes for variables your framework copies into the build, like these.

And one catch. Restart isn't redeploy. Restart starts fresh spherelets exactly as last deployed, without your saved changes.

[02:47] Recap and your lab

So, a quick recap. A saved change isn't a running change. Your app picks up variables when it starts, so a redeploy applies them. And code needs a new build. Now it's your turn. Head to the lab, and give your own sample API a variable and a secret. I'll see you in the next lesson.

Key idea

A running app reads its environment variables once, when it starts. So a configuration change reaches it only when new spherelets start with it, on a redeploy, and a code change only after a new build.

You changed a variable and the app still shows the old value. Nothing is broken: the change is saved, but your app hasn't started with it yet.

Redeploys are rolling: new spherelets start next to the old ones, which stop only once the new ones are healthy. Applying a change doesn't take your app offline (lesson 5.7.2 shows how).

Change by change

You changeHow it reaches the app
A service's variables or secrets, in the consoleThe console asks Apply changes? Choose Save & redeploy
A service's variables or secrets, with csphcsph redeploys the service for you
The environment's shared variables or secretsSaving redeploys every running service in the environment automatically. A stopped service gets them when it's next started; a cron job, on its next run
The health checkRedeploy to apply changes? → Redeploy now
The spherelet countApply changes? → Save & redeploy. No build: it runs more or fewer copies of the same version
Your code, pushed to GitHubRedeploy → Build & deploy
A NEXT_PUBLIC_… or VITE_… variableSave it and choose Save & rebuild, or later Redeploy → Build & deploy, because these are copied into the build

Now or later

When you save, the console asks whether to apply the change now. Save & redeploy saves it and rolls it out. Save only saves it without applying it, and the app keeps the old values until the next redeploy. The health check card asks the same question with Redeploy now and Later.

Save only (or Later) is useful for several changes at once, say three variables and a health check: choose it for all but the last, and get one rollout instead of four.

The catch is forgetting. A saved value looks right in Settings while the app still uses the old one. If Settings and the app disagree, redeploy first.

Build & deploy or Deploy only

For a service built from a repository, Redeploy offers two options:

  • Build & deploy builds the latest commit on your branch, then rolls it out. Use it for code and for NEXT_PUBLIC_…/VITE_… variables.
  • Deploy only rolls out the image you already have with the current settings. It's faster, and enough for ordinary variables, secrets and health checks.

A service deployed from an image only has the second.

Check yourself

You saved a new variable and chose Save only. An hour on, the app still uses the old value. Why?
You change a shared variable on the staging environment. What happens to its running services?

In the docs