Upgrade

./ophiolite-ops upgrade <registry>/ophiolite-server:<new release>

This asks the new image what its first start would do, backs up the deployment (before-<release>-<time> in the backups volume), switches .env to the new image and replaces the server container with one from the new image; the database and the evaluation sign-in provider are left running. If the backup fails, nothing is upgraded: the same server is started again and .env still names the old image. The new release applies its migrations before anything else runs and then records itself as the installed release. The command returns only after that: it asks the server every 2 seconds and says release <new release> recorded. If the new release has not recorded itself within 600 seconds (OPHIOLITE_UPGRADE_WAIT in the environment changes the limit), it stops with an error that names the release still installed; .env already names the new image, and docker compose logs server says why the server has not finished.

The release gate. Every image lists the releases it can start from (upgrades_from in its release.json). A start refuses, before writing anything, when the database was last run by a release that is not listed. This applies to every start, including starting an older image by editing .env by hand: a downgrade is not supported. If you need to go back, restore the backup taken before the upgrade into a new deployment with the old image.

./ophiolite-ops upgrade-check shows the installed release and what the configured image’s next start will do.

From a pilot installation. Deployments installed with tools/pilot/pilot.py are not upgraded in place into the image. Upgrade the pilot with its own procedure, then move the project into a packaged deployment (Recovery and moves).

Registered applications (the release that carries E33)

This release adds three database migrations, which the upgrade applies in order: 20261011-applications.sql, 20261011-application-consents.sql and 20261011-application-credentials.sql. Each is idempotent and creates new tables only; no existing row changes, and every session and access key keeps working.

Registered applications are off until an owner registers one (Organization → Applications; Let colleagues sign in to your application). Registration by the application itself (RFC 7591) stays off unless the gateway setting application_registration names the organization and the owner whose registrations wait for approval.

2026.10.83 — invitations find you

2026.10.83 upgrades from 2026.10.82 and every release that one upgrades from. It adds five database migrations, which the upgrade applies in order: 20261009-invitation-discovery.sql, 20261009-invitation-declined.sql, 20261009-verified-address.sql, 20261009-join-found.sql and 20261009-onboarding-sessions.sql. Each is idempotent and moves no data: pending invitations stay pending, and mail queued before the upgrade is still sent.

Finding invitations by a person’s verified address is off until you turn it on in the gateway identity settings (invitation_discovery: off, issuer or domains). People who signed in before the upgrade discover nothing until their next sign-in, because the address their provider verified is kept only for sign-ins begun after it. Invited people can now decline an invitation; the inviter’s list shows Declined.

2026.10.32 — shale volume from gamma ray

2026.10.32 upgrades from 2026.10.31 and every release that one upgrades from. It has no database migration: the managed schema gains one table, the calculation request journal, which the server creates on start; no existing table changes. People with the permission to run calculations can calculate shale volume on a log they may build on (Shale volume from gamma ray).

2026.10.31 — operator commands on Podman

Copy this release’s deployment/package/ophiolite-ops into your deployment directory first (it is part of the release package; upgrade changes the server image, not the tool you run), then upgrade as above. With this tool, backup, export-project, import-project and upgrade start the server they stopped again without recreating the evaluation sign-in provider or the database, so on rootless Podman they no longer leave the deployment down. No database migration.

2026.10.27 — reading a connected source from code

2026.10.27 upgrades from 2026.10.26 and every release that one upgrades from. It has no database migration and changes no answer the server gives: the source routes keep their behaviour, and their nested documents are now described in the API reference. People with a project access key can read the SQL well tables they selected with the Python SDK and ophiolite sources (Read a connected source in Python). ophiolite-ops dev up also prints a read key for the sandbox administrator, labelled “ophiolite operator”.

2026.10.26 — joining an organisation

2026.10.26 upgrades from 2026.10.25 and every release that one upgrades from. It adds one database migration, 20261001-invitation-links.sql, which the upgrade applies: links replaced by a resend, and what a browser is doing with an invitation (kept for an hour; an outcome is kept an hour longer only to show it). Invitations created from now on last seven days; those created before keep their expiry. Mail queued before the upgrade is sent in the new wording. A link replaced by a resend before the upgrade answers “no longer available” rather than “replaced”. A Join page left open across the upgrade cannot continue: open the link from the email again. Revoking a sign-in on the account page now also ends that browser session, so it frees a place for a new one. Too many lookups of invitation links from one address answer 429 RATE_LIMITED with Retry-After (errors).

The sign-in provider settings joining relies on (sign in with the email address, one account per address, the Workspace’s post-logout addresses /organizations and /join) are applied by deployment/workspace-identity/configure_join.py, and its sign-in events are kept for 14 days. Those events name people who tried to sign in, including failed attempts; keep them no longer than you need.

2026.10.17 — platform hardening

2026.10.17 upgrades from 2026.10.16 and every release 2026.10.16 upgrades from. It adds no database migration. A database the server briefly cannot reach is retried and then answered 503 with Retry-After (see the Podman known issue under Install); SQL sources retry the same way; wells lists and extents are much faster for large projects, with the same results.

2026.10.16 — test-only

2026.10.16 upgrades from 2026.10.15 and every release 2026.10.15 upgrades from. Nothing a deployment runs changes: one Platform test now waits for PostgreSQL to release a closed worker’s lock before checking that another worker takes over webhook delivery.

2026.10.15 — sandbox wells

2026.10.15 upgrades from 2026.10.14 and every release 2026.10.14 upgrades from. It changes no server, protocol or database: ophiolite-ops dev up now ends with each sandbox person seeing the wells of the provinces they may read. A sandbox made with an earlier release keeps no wells; ophiolite-ops dev reset remakes it (new keys and tokens).

2026.10.14 — sign-in token and project access key wording

2026.10.14 upgrades from 2026.10.13 and every release 2026.10.13 upgrades from. It adds no database migration and changes no protocol: the sign-in fallback now reads Use a sign-in token, and the keys on the account page are Project access keys (existing keys keep working).

2026.10.13 — developer kit

2026.10.13 upgrades from 2026.10.12 and every release 2026.10.12 upgrades from. It adds no database migration. Refusals keep their error text and gain code, remedy, docs and request_id; every answer carries X-Request-Id. Requests the API description does not allow (an unknown type for a field, a missing required field) are now refused with 422 or 400 naming the field, where earlier releases sometimes accepted or failed later.

2026.10.12 — wells on a map

2026.10.12 upgrades from 2026.10.11 and every release 2026.10.11 upgrades from. It adds no migration file: at its first start the gateway adds the row column to associations (existing ones keep naming a whole revision) and builds the location index from every existing association, before it serves anything. The gateway converts coordinates with pyproj, which the image already carries.

2026.10.11 — derived publication

2026.10.11 upgrades from 2026.10.10 and every release 2026.10.10 upgrades from. It adds no database migration. People can publish a file they computed themselves from exact versions of project data (publications/derive); it is read like an upload of its type and starts private to its author.

2026.10.10 — stored revision manifests

2026.10.10 upgrades from 2026.10.9 and every release 2026.10.9 upgrades from. It adds no database migration. At its first start the gateway records which data each revision was derived from and marks every existing revision as written before stored manifests, before it serves anything; those revisions serve exactly the manifest they served before. New revisions store their manifest once, and every read checks it against the stored data: a manifest that no longer matches, or was removed, is refused as a conflict rather than served. Moving a project from an earlier release marks its revisions the same way.

2026.10.9 — webhooks

2026.10.9 upgrades from 2026.10.8 and every release 2026.10.8 upgrades from. It adds no database migration. Project administrators can ask Ophiolite to notify an address when a project changes (Settings → Notifications). Addresses must be https:// and on the public internet; the gateway sends the notifications itself, so its host needs outbound HTTPS to those addresses.

2026.10.8 — project events

2026.10.8 upgrades from 2026.10.7, 2026.10.6, 2026.10.5, 2026.10.4, 2026.10.3, 2026.10.2, 2026.10.1 and 2026.9.2. It adds no database migration: the gateway creates the event log’s tables in its managed schema when it starts. At that first start it also moves the inbox onto the log, copying every existing notice with its read state before it serves anything; people see the same inbox. Applications can now follow a project’s changes (Build > Project events and synchronisation). Events are kept for 30 days by default (OPHIOLITE_EVENT_RETENTION_DAYS); a restore or a project move starts a new epoch, and clients resynchronise.

2026.10.7 — application reach

2026.10.7 upgrades from 2026.10.6, 2026.10.5, 2026.10.4, 2026.10.3, 2026.10.2, 2026.10.1 and 2026.9.2. It adds one database migration, 20260930-capability-three-reach.sql, which the upgrade applies. Python sign-ins (capability 3) now also list the projects and organisations they reach and read the project’s wells, data, sources and activity; they gain no new writes. Because a sign-in keeps exactly the reach it was approved for, the upgrade ends capability-3 sign-ins approved or pending before it: the application asks again, and the consent screen names the project and says what the application may read and, with write, upload, publish and share. Capability 1 and assistant sign-ins are unchanged.

2026.10.6 — access keys

2026.10.6 upgrades from 2026.10.5, 2026.10.4, 2026.10.3, 2026.10.2, 2026.10.1 and 2026.9.2. It adds one database migration, 20260929-access-keys.sql, which the upgrade applies. People can create access keys for their own scripts and notebooks on the account page (Access keys): each key is for one project, reads or reads and publishes, lasts up to a year and is shown once. A key never does more than its owner can do now; blocking someone revokes their keys for that project, and offboarding revokes them for every project of the organisation. Scripts use a key with ophiolite login --key or the OPHIOLITE_ACCESS_KEY environment variable.

2026.10.5 — import recipes

2026.10.5 upgrades from 2026.10.4, 2026.10.3, 2026.10.2, 2026.10.1 and 2026.9.2; it adds no database migration. Petrel “Points with attributes” and OpendTect x y z horizon exports can be uploaded with their companion files (a README, CRS metadata) and are read through an import recipe: what each column is, which markers mean missing, and which file line decides each field of context. Every decision is kept with the upload. A project that requires complete scientific context now applies that rule to every typed upload, not only to maps: an upload with an undecided field is refused and names the field, so declare it or add the file that states it.

2026.10.4 — the public site

2026.10.4 upgrades from 2026.10.3, 2026.10.2, 2026.10.1 and 2026.9.2; it adds no database migration. The image carries the Ophiolite public site. Every deployment serves its pages (for example /product/) and the documentation at /docs/. Set "public_site": true in config.json to show the site at / to people who are not signed in; signed-in people still land in the Workspace. Sign-in has its own address, /sign-in. Add public_site to config.json only after the upgrade has finished: the release you upgrade from checks the configuration first and refuses a key it does not know.

2026.10.3 — rehearsal fixes

2026.10.3 upgrades from 2026.10.2, 2026.10.1 and 2026.9.2; it adds no database migration.

• Python sign-ins may now read wells, wellbores and lineage and import portable bundles. A sign-in approved before this release keeps exactly what it was approved for; people run ophiolite login again and approve the new request, whose card says what it allows.
• The packaged example raises limits.upload_bytes to 32 MiB; set it in your config.json if you import bundles whose results exceed your current limit. A refusal now names the limit.
• ophiolite-ops connection-ca keeps the certificate of a private certificate authority for remote PostgreSQL sources, and configure connection-admin refuses a target the server would refuse.
• ophiolite-ops client-kit writes the Connectors package and QGIS plugin of this release.
• The evaluation sign-in provider keeps its data in a volume and takes its port from OPHIOLITE_IDENTITY_PORT; copy its two files again from the release.

2026.10.2 — sign-in and sessions

2026.10.2 upgrades from 2026.10.1 and from 2026.9.2 (which also runs the 2026.10.1 catalog move below). Sign-in now lasts seven days without use and thirty days in all, and returns to the page you were on. Every browser session from before the upgrade ends once: people sign in again. An evaluation provider prepared with an earlier kit keeps its shorter limits until apply_policy.py --evaluation is run (see Install).

2026.10.1 — the transition release

What changes for people and clients: release notes.

1. Packaged upgrades are supported from 2026.9.2. A legacy pilot deployment needs its separate pilot migration procedure; do not just pull the new source and restart it.
2. Obtain the qualified image and matching release files. Pause connector/QGIS publication during the maintenance window. Run ./ophiolite-ops upgrade <qualified-image-reference>; the command creates a pre-upgrade backup before switching versions. Image publication is separate from approving these notes; no public registry download is claimed here.
3. Keep the backup off-host, plus the operator-held secrets and identity/connection configuration. These are not all included in the backup. Keep/export the connection encryption key separately if connection administration is configured.
4. First start migrates snapshots, originals and reviews, then registrations, and records catalog-migration-report.json and registration-migration-report.json in the state volume. Verified migrated native snapshot/original/review tables are then removed. An interrupted migration can be rerun; a failed contract/report check can leave the old tables retained and is reported in the log. Check the reports and logs before declaring the upgrade complete.
5. Verify sign-in, exact reads of existing assets, expected access refusals, and the workflows you use before resuming publication.
6. No in-place downgrade. To return to 2026.9.2, restore the pre-upgrade backup into a separate empty deployment using the old image. Retain the upgraded deployment until recovery is verified; new writes made after the backup are not in that backup.