Versions and rollbacks

Every change records an immutable version with a structured diff, and going back is the same operation as going forward.

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.

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.

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.

{
  "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.

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.

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.

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.

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.