Platform Updates

When Strongly is updated to a new version, the resources that are already running were started by the previous version. The platform's parts of each one (the auth and egress proxies beside it, its volume sidecars, its platform settings) are the previous version's. Within a few minutes of an update, the platform brings every long-running resource up to the new version, through the same path that deploys it. Most resources need nothing from you.

What happens to each resource

Resource	After an update
App	A running app is restarted on the new version with no downtime: the running version keeps serving until the new one is ready. The restart runs as the user who deployed the app, so their access, budget and governance checks apply as they do to their own restart. A stopped app runs the new version when it is started.
Agent	Redeployed (stopped and started) as the user who started it, so it is unavailable for a moment. An idle on-demand agent is redeployed too, and idles again.
Deployed workflow	A running workflow's deployed version is deployed again: the version that was running, never your unsaved or undeployed changes. A stopped workflow is deployed again when it starts, whether you start it or a run starts it under its lifecycle policy.
Streaming workflow	Its deployed version is deployed again. Each running pod finishes its open sessions before it stops.
Tool	Activated again.
Registry model, self-hosted model	Updated in place: a running model keeps serving until its new pods are ready. A stopped or idle (scaled to zero) model is updated without being started, and runs the new version at its next start or wake.
Avatar	Updated while no session uses it. An idle avatar is updated without being started; a running one is updated between sessions (a session started meanwhile is told the avatar is busy).
MCP gateway	Your organization's gateway is updated in place. An idle gateway runs the new version when it wakes.
Add-on	Its probes and server settings are applied at once when it is stopped or they did not change. A running add-on whose settings changed keeps running and asks for a restart, because applying them restarts its database.
Workspace	A running workspace is never restarted for you: a restart ends its open notebooks, terminals and running processes. It asks for a restart instead. A stopped workspace runs the new version when it is started.

Restart needed

A resource that needs a restart before it runs the new version shows Restart needed in its list, and its page says so with a Restart button. This happens for:

• a running workspace;
• a running add-on whose settings the update changed;
• an app, agent or deployed workflow the platform could not restart for you, because the restart was refused for its user (they no longer have access to it, their budget is exhausted, or a governance gate holds it).

What a restart interrupts is shown before you restart:

Resource	Restarting it
Workspace	Ends its open notebooks, terminals and running processes. Files in /workspace and its volumes are kept.
Add-on	It is unavailable for a moment; its data is kept.
App	No downtime: it keeps serving while the restarted version starts.
Agent	It is unavailable for a moment (Agent Settings, Restart).
Deployed workflow	In the workflow builder, Restart needed beside the deployed version deploys that version again. Your unsaved and undeployed changes are not deployed.

The warning clears once the resource runs the new version.

In the REST API, Python SDK and STAN

A workspace, app or add-on record (GET /api/v1/workspaces/{id}, GET /api/v1/apps/{id}, GET /api/v1/addons/{id}) and a workflow's record carry platformUpdatePending: true while they need a restart. The usual restart applies the update: POST /api/v1/workspaces/{id}/restart, POST /api/v1/apps/{id}/restart, POST /api/v1/addons/{id}/restart, POST /api/v1/agents/{id}/redeploy, or for a deployed workflow POST /api/v1/workflows/{id}/deploy-version with its deployed version. Ask STAN which of your resources need a restart; it asks you before restarting one.