> ## Documentation Index
> Fetch the complete documentation index at: https://ekso.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Upgrading

> Update Ekso to the latest release with two commands. Data is preserved automatically across every upgrade.

Ekso ships releases multiple times a week. Updating an install is two commands. Your database, attachments, and backups are preserved automatically — there is no migration step you need to run.

## The update flow

Run these from the folder that contains your `docker-compose.yml` (the directory you unzipped the bundle into):

```bash theme={null}
docker compose pull
docker compose up -d
```

That's the entire procedure. The first command fetches new container images from Docker Hub. The second replaces your running containers with new ones based on those images, while keeping your data folders attached.

## What happens during an update

| Step                              | What changes                                                                                  | What stays                                            |
| --------------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| 1. `docker compose pull`          | Latest `eksoapp/app` and `eksoapp/worker` images downloaded                                   | Nothing on disk yet — just image cache populated      |
| 2. `docker compose up -d` (stop)  | Running containers stopped                                                                    | `./data/`, `./backups/`, `ekso.json` untouched        |
| 3. `docker compose up -d` (start) | Containers recreated from new images, attached to the same `./data/` and `./backups/` folders | Database files and attachments untouched              |
| 4. API boot                       | Schema migrations apply automatically against the existing database                           | Your data — migrations evolve the schema in place     |
| 5. API ready                      | New version serving on port 6050                                                              | Sessions invalidated only if `Secrets.JwtKey` rotated |

Total downtime is typically 10–30 seconds, dominated by the API's schema migration check on boot.

<Note>
  Schema migrations are forward-only and incremental. Skipping multiple releases — for example updating from 1.55 to 1.62 — runs all the migrations in between, in order, against your live data. There is no special procedure for catching up.
</Note>

## Release cadence

Ekso releases multiple times a week. Each release is published to Docker Hub as both a versioned tag (`eksoapp/app:1.59`) and updates the floating `:latest` tag. Customers running `docker compose pull` get whatever was tagged `:latest` at pull time.

This cadence is intentional — small, frequent releases land fixes and improvements quickly. It also means you should not be afraid to update; every release is the smallest possible step from the previous one, and `./backups/` keeps the last 14 days of your data on hand if anything ever needs reverting.

## Pinning a specific version

If you'd rather control when a customer install moves between releases, pin the image tags in your `docker-compose.yml`:

```yaml theme={null}
services:
  api:
    image: eksoapp/app:1.59      # pinned, not :latest

  worker:
    image: eksoapp/worker:1.59   # pinned, not :latest
```

After pinning, `docker compose pull` only fetches the pinned version (a no-op if you already have it), and `docker compose up -d` doesn't recreate the containers unless you change the tag. To upgrade, edit the version numbers and re-run the two-command flow.

Released version numbers are listed at [the Ekso changelog](https://ekso.dev/changelog).

## Taking a pre-upgrade snapshot

The bundled `backup` service writes a fresh snapshot when it starts. To get one immediately before upgrading, restart the backup container:

```bash theme={null}
docker compose restart backup
```

This produces a snapshot in `./backups/db/` and `./backups/storage/` (Quickstart) or `./backups/storage/` (BYOD). Use that snapshot if you ever need to roll back the upgrade you're about to do.

See [Data management](/guide/manage/data-management) for the full backup story.

## Rolling back to a previous version

A rollback has two parts: you need to revert both the **code** (the container images) and the **data** (the database and storage). Reverting only the code against post-upgrade data risks the older code being unable to read the newer schema.

```bash theme={null}
# 1. Stop the stack.
docker compose down

# 2. Pin the older version in docker-compose.yml.
#    Edit the `image:` lines to e.g. eksoapp/app:1.58 and eksoapp/worker:1.58.

# 3. Restore data from the snapshot you took before upgrading.
#    See Data management for restore commands.

# 4. Bring it back up.
docker compose up -d
```

If you didn't take a pre-upgrade snapshot, the most recent automatic snapshot from `./backups/db/` is your fallback — find the timestamp closest to (but before) the upgrade.

<Warning>
  You can't roll back schema-only without rolling back data. Pinning the image to an older tag *without* restoring a pre-upgrade snapshot leaves the older code looking at a newer schema — it won't recognize columns or tables that didn't exist in its day. Always pair an image-tag rollback with a data restore.
</Warning>

## BYOD — your external database

If you run [BYOD](/guide/install/byod) (your own Postgres or SQL Server), the upgrade flow is identical:

```bash theme={null}
docker compose pull
docker compose up -d
```

Schema migrations apply against your external database the same way they would against the bundled one. The Ekso user you configured needs `CREATE` rights for migrations to land — same requirement as first install. If you revoked elevated permissions after first boot, restore them before upgrading.

The bundled `backup` service in BYOD only snapshots attachments (`./data/storage/`). Database backups are your responsibility — take one with your usual DB tooling before any upgrade you're nervous about.

## See also

* [Data management](/guide/manage/data-management) — where data lives, automatic backups, and the restore commands referenced above
* [Configuration reference](/guide/install/configuration) — every field in `ekso.json`