-
Notifications
You must be signed in to change notification settings - Fork 0
Versioning and Rollbacks
NEXUS AI keeps version history at two levels:
- Builder checkpoints preserve source files during AI-assisted development.
- Deployment releases preserve deployable runtime versions for rollback.
Database contents, volumes, buckets, and external services have separate lifecycles and are not automatically rewound by a code rollback.
The AI App Builder creates a checkpoint after each file-changing assistant turn and each saved manual edit.
- A checkpoint contains the complete current file set.
- Restoring an old checkpoint creates a new checkpoint.
- History is not destructively rewritten.
- Deploying does not close the builder session.
Use builder history when the source or UI changed during a conversation but has not necessarily been released.
A deployment release records the image/source result and deployment configuration used for a rollout. New releases are created by deploy, redeploy, GitHub auto-deploy, and Builder deployment workflows.
Inspect the deployment in the dashboard or CLI:
nexus deploy get app
nexus deploy status appOpen a deployment, inspect its history, choose the intended healthy release, and confirm rollback.
# Roll back to the previous eligible release
nexus deploy rollback app
# Skip the interactive confirmation in controlled automation
nexus deploy rollback app --yesUse nexus deploy rollback --help for target-release options supported by the installed CLI.
An agent can call nexusai_deploy_rollback with deployments:create. The client should show the target deployment and require confirmation before changing production.
A rollback restores a prior application release through the deployment pipeline. It can restore application code/image and associated release configuration supported by the provider.
It does not automatically:
- reverse database migrations;
- restore database rows;
- restore deleted bucket objects;
- rewind filesystem volume contents;
- revoke or restore external credentials;
- undo actions performed by the application against third-party systems.
Secrets are resolved from the current organization/environment configuration during deployment operations. Do not assume an old image receives an old secret value.
Before a risky migration:
nexus db services app
nexus db backup <service-id>
nexus db backups <service-id>Then deploy, validate health and logs, and recover deliberately if necessary:
nexus deploy logs app --follow
nexus db restore <service-id> <backup-id> --yes
nexus deploy rollback app --yesThe order depends on migration compatibility. Prefer expand/contract migrations so both old and new application versions can run during rollback.
nexus deploy stop app
nexus deploy start appStop/start preserves the same deployment configuration and does not rebuild source. Use it for operational pause/resume. Use redeploy for a fresh rollout and rollback for a prior release.
nexus deploy redeploy app --waitRedeploy retains the deployment identity and URL where supported. It applies current source/configuration and attachment state. Use separate projects or deployments for development, staging, and production instead of repeatedly repurposing one deployment.
GitHub auto-deploy creates a new release for an accepted push. The dashboard records commit/branch context for GitHub-triggered deployments. Rolling back the runtime does not revert the Git branch; fix or revert the repository so the next auto-deploy does not reintroduce the problem.
- Volumes: persist independently from an app release; rollback does not restore files.
- Buckets: object state persists independently; use application-level object versioning/backup where needed.
- Database sidecars: data persists independently; use database backups.
- Standalone managed databases: use snapshots and non-destructive restore-to-new-database workflows.
- External databases: use the provider's backup and recovery controls.
- Deploy and test in staging.
- Back up stateful services.
- Use backward-compatible schema migrations.
- Release to production.
- Check health, logs, and critical user flows.
- Keep the previous release eligible for rollback.
- Roll back code only after deciding how to handle state changes.
- Reconcile the Git branch after an emergency rollback.
Auto-destroy removes an ephemeral deployment at its scheduled time; it is not rollback. Deployment deletion is also not rollback and may make the runtime unavailable immediately. Confirm attached databases and storage before deletion.
The deployment may not have an earlier eligible release, or the provider may no longer have the required artifact. Check deployment history and build logs.
Check current secrets, database schema compatibility, external dependencies, health port, and runtime logs. The failure may be outside the application image.
Revert or fix the source branch, or disable the binding temporarily while the incident is contained.