Skip to main content
Every app deployed as an incremental app release belongs to one deployment: the one whose releases it runs. Only that deployment can release it again. Ownership is per app, so several deployments can share a workspace as long as they deploy different apps.

​
Who can own an app

​
Who can take an app over

Taking an app over keeps its identity: the app ID, URL, volumes, and data stay. The previous owner’s retained releases can no longer be activated for that app; roll back through the new owner instead.

​
When a deployment is refused

A release that would take over an app it may not is refused before anything changes. When a GitHub connection or binding owns the app, the error names it:
Any other owner gives App web belongs to another active deployment: another local project, or an app no deployment can take over. Deploy under a different name or to another workspace, and keep .rig.lock so your project keeps its identity. When rig deploy from your machine is refused because a GitHub connection deploys the apps, it deploys nothing and exits with a conflict error. First it stores the values it resolved for the manifest’s secrets - from your environment and .env files - in the connection’s runtime secrets, for the names that rig.yaml on the connected branch declares, and lists the names it stored. The next push deploys with them.

​
Move apps to a GitHub connection

  1. Connect the repository to the workspace in the console and choose incremental deployment. In the review, enter the manifest’s secrets under Runtime secrets: a push never reads your .env files. See Deploy from GitHub.
  2. Save the configuration. Its first deployment takes over the apps with the same names.
  3. Run rig ci status --repo OWNER/REPO and check that every declared secret shows set.
If that first deployment fails because a required secret has no value, the apps still belong to your local project and rig deploy still deploys them. Open the connection’s configuration, add the value under Runtime secrets, and save again; saving redeploys the branch head. Once the connection owns the apps, rig deploy from the project directory updates its runtime secrets from your .env files instead of deploying.

​
Move apps back to rig deploy

Disconnect the repository in the workspace’s GitHub deployment settings, or run rig ci unlink --repo OWNER/REPO --workspace WORKSPACE for a GitHub Actions binding. The next rig deploy from the project directory takes the apps back, and reads secrets from your environment and .env files again. Rigbox keeps the disconnected connection’s runtime secrets for that workspace and repository, so reconnecting restores them.