---
title: Versions and rollbacks | Runware Docs
url: https://runware.ai/docs/serverless/versions
description: Every change records an immutable version with a structured diff, and going back is the same operation as going forward.
relatedDocuments:
  - https://runware.ai/docs/serverless/deploying
  - https://runware.ai/docs/serverless/monitoring
  - https://runware.ai/docs/serverless/compute-and-scaling
---
## Introduction

A version is **an immutable record of what to deploy**: the image its build produced, the worker configuration, the environment, the endpoints and the volumes. Once written it never changes.

```bash
runware serverless apps versions my-app
```

## Everything records one

Not just a code change. **A configuration-only update produces a version too**, carrying the previous image forward rather than rebuilding it.

That is what makes the list a complete history: at any point you can see which code was running and what it was running with. **Every change leaves a version behind**, so every change can be accounted for later.

> [!NOTE]
> This is also why **raising a worker ceiling costs just a version**. The image is reused, so the change is recorded in seconds where a build would take minutes.

## The diff

Each version carries a structured comparison against the one before it, so what changed is there to read directly.

```json
{
  "versionNumber": 8,
  "changes": {
    "imageChanged": false,
    "workerConfig": [
      { "field": "maxWorkers", "from": "4", "to": "16" }
    ]
  }
}
```

`imageChanged` is the fastest thing to read: **false means this version reused the previous image**, so your code is exactly what it was. The rest names the fields that moved.

**Version 1 has no diff**, because it is the first. A name-only update produces `{ "imageChanged": false }` and nothing else, since empty collections are left out.

> [!NOTE]
> Environment variables appear in a diff **as keys only, never as values**. A version list is readable by anyone who can read the app, and a value that arrived through a secret has no business being visible there.

## Rolling back

There is no rollback operation. **You activate an older version**, and it is the same call as activating a newer one.

```bash
runware serverless apps versions activate my-app 7
```

**Nothing is rebuilt.** The image that version already pinned is re-applied, which is why a rollback takes as long as a rollout rather than as long as a build.

The rollout itself is careful in the same way a forward deploy is: **new workers have to become healthy before the old ones are drained**, so an activation that fails to come up leaves the app serving what it was already serving.

## Deleting one

A version can be deleted once nothing depends on it, and **its history is retained** even though the version stops appearing.

```bash
runware serverless apps versions delete my-app 3
```

A deleted version is omitted from listings, returns `404` when read, and **cannot be deployed**. That last part is the point: deletion is how you take a version out of the set anyone can roll back to.

> [!WARNING]
> The platform refuses to delete a version that is **active**, that is the app's **only remaining** one, that still has a worker that is not stopped, or that a **live rollout is targeting**. All four return `409`, and all four exist to stop you removing the thing currently keeping the app up.

## What a version does not carry

An app's **source** is not part of its version in the way the rest is. A version names the build that produced its image, and the image is what runs.

And **volumes are fixed when the app is created**, so while each version records the volume set, a rollback restores the same layout every time.