Skip to main content
Version: 0.9.19

Updating Studio

When PrometheusRL publishes a new Studio release, you move your deployment to it with a single command: studioctl update. By default it auto-detects whether the release is a code-only change (just a new application image) or also changes infrastructure, and does the right thing. You can force either path with a flag. Updates reuse your saved configuration, so they are nearly hands-free.

Before you update​

  1. Download the new release bundle from the Console and unzip it.
  2. Read the release notes for that version.
  3. Run studioctl from the new bundle folder, with credentials for your existing deployment's account and region.

studioctl remembers your previous answers (stack names, domain, certificate, Cognito prefix, Neo4j mode), so updates pre-fill almost everything. For external Neo4j your password is re-entered (or supplied via environment variable) because it is never stored; for self-hosted Neo4j there is nothing to enter.

The update command​

python3 studioctl.py update

In the default auto mode, studioctl update:

  1. Compares the new bundle against what is currently deployed.
  2. Always pushes the new Studio image and re-syncs the web app.
  3. Determines whether any infrastructure templates changed. If not, it performs a fast code-only update (just rolls the services to the new image). If they did, it proceeds with an infrastructure update.

You can override auto-detection:

python3 studioctl.py update --image-only   # force code-only: new image + service roll, no stack changes
python3 studioctl.py update --infra         # force infrastructure: re-apply the stacks too

Code-only update (the common case)​

Routine version bumps usually change only the application. studioctl pushes the new image, optionally re-syncs the web app, and rolls the services. Each Studio service performs a rolling update, and a built-in safety mechanism monitors the rollout: if the new version fails to come up healthy, the update automatically rolls back to the previous version rather than leaving the service down. Your data stores, configuration, Neo4j, and networking are untouched.

Infrastructure update (when a release changes resources)​

When the release changes infrastructure (for example a new table or secret), studioctl computes a change set for each stack and shows you a reviewed summary of exactly what will be added, modified, or removed before anything is applied. Purely additive or in-place changes proceed once confirmed; any destructive change (a resource that would be replaced or deleted) is called out explicitly and requires a separate confirmation, so you are never surprised by data loss. Stacks that did not actually change resolve to a clean "no changes" and are left as-is.

Self-hosted Neo4j is carried forward across updates — its retained EFS storage and credentials are reused, so your graph survives the update. External Neo4j is untouched.

Updating single sign-on​

Changing your IdP metadata or attribute mappings does not require an image or infrastructure update — re-run just the SSO step:

python3 studioctl.py saml

See Single Sign-On (SAML).

After updating​

Browse to your domain to confirm the new version is serving, and check the Console license page — heartbeats continue across the update and the deployment should remain healthy. If a rollout did not go as expected, see Troubleshooting.