Skip to main content

Documentation Index

Fetch the complete documentation index at: https://ekso.dev/llms.txt

Use this file to discover all available pages before exploring further.

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): 
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

StepWhat changesWhat stays
1. docker compose pullLatest eksoapp/app and eksoapp/worker images downloadedNothing 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/ foldersDatabase files and attachments untouched
4. API bootSchema migrations apply automatically against the existing databaseYour data — migrations evolve the schema in place
5. API readyNew version serving on port 6050Sessions invalidated only if Auth.Jwt.Key rotated
Total downtime is typically 10–30 seconds, dominated by the API’s schema migration check on boot.
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.

​
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: 
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.

​
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: 
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 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. 
# 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.
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.

​
BYOD — your external database

If you run BYOD (your own Postgres or SQL Server), the upgrade flow is identical: 
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