Skip to content

Recover a Previous Version

Varity Team Core Contributors Updated June 2026

If a deployment breaks your app, the way to recover today is to redeploy a known-good version of your app. This guide covers the recovery flow and what to watch out for.

Recover by Redeploying a Known-Good Version

Section titled “Recover by Redeploying a Known-Good Version”

The reliable recovery path is to rebuild and redeploy a version you know works, under the same app name. Varity replaces the deployment at that URL with what you just built.

  1. Check out the last working version of your code

    In your project, return to the commit (or tag/branch) you know was healthy:

    Terminal window
    git checkout <known-good-commit>
  2. Build it

    Terminal window
    npm run build
  3. Redeploy under the same name

    Use the same --name you deployed with originally so the app URL stays the same:

    Terminal window
    varitykit app deploy --name my-app

    Your app at https://varity.app/my-app/ (static) or https://my-app.varity.app/ (dynamic) is replaced with the version you just built.

List your deployments to confirm what’s live and which app names you own:

Terminal window
varitykit app list

Inspect a specific deployment’s details:

Terminal window
varitykit app info deploy-1737491000

Check overall status:

Terminal window
varitykit app status

If the broken deployment introduced new environment variables that your code now depends on, redeploying the older code alone may not be enough. Check your environment variables after redeploying.

If your app ran database migrations between the broken version and the version you’re restoring, redeploying the older app code may leave the schema ahead of the code. Test your app after redeploying before considering it stable.

After redeploying, confirm the app is working:

Terminal window
varitykit app status

Open the URL in your browser and confirm the expected behavior is restored.