Platform maintenance
How Crucible applies variable and secret changes to a live full deployment and keeps its record in sync with what is running.
Change a live deployment safely
Changing configuration on a live product usually means editing infrastructure by hand, restarting the right services, and hoping the running state matches what you intended. On a full deployment, saving a variable on its Variables tab starts one tracked rollout instead. The toast reads "Variable update queued", and Redeploy runs the same rollout.
- Apply: Crucible updates the deployment's configuration and re-applies it when backend or frontend values changed.
- Roll secrets forward: A new Backend secret value becomes a new secret version, and Crucible disables the older versions.
- Restart: Services that read a changed value restart. Frontend changes trigger a fresh frontend build, because those values are compiled in.
- Reconcile: Crucible reads the live values back into its record, so what you see matches what is running.
Lite deployments apply variable changes directly, without this rollout. Project variables are shared defaults; each deployment picks them up on its next release. See Environment variables for variable types and scope.
One Temporal workflow owns the rollout. It edits the deployment's Terraform variables file, then re-applies infrastructure through the path that matches the deployment mode: an infrastructure-only Argo release on Kubernetes, or a Cloud Build release for Cloud Build deployments. It adds, enables, and disables Secret Manager versions, then restarts runtimes: a backend, frontend, or full Argo release on Kubernetes (GCP waits for the Kubernetes Secret to sync first), or a restart of only the Cloud Run services whose latest revision reads a changed secret. A child workflow pulls live values from the runtime and the Terraform variables and writes them back to the database. Frontend values must use the VITE_ prefix.