Opfield 2.12: apps, databases on several servers and a new name
Apps with environments, promotion and a kill switch; databases and storage on 2 to 5 servers that fail over even while Opfield is down; the Opfield name; signed releases and a full export of the installation.
By the Opfield team5 min readUpdated
Opfield 2.12.0 is out. Applications get a home of their own, managed databases can run on several servers, and the product now carries the Opfield name. Below are the changes most users will notice. The full list is in the changelog.
Apps and environments
An app now groups everything one application needs: containers, Compose projects, databases, storage, key-value stores, routes and Pages. Each app has environments, such as production and staging. Apps are available on every plan.
- Each environment has its own settings. Variables, secrets, allowed nodes and access are set per environment. Containers get the environment's values on create, update and recreate, and the environment page lists the workloads that still need a recreate.
- Promotion. An environment can be promoted to another: the exact images, Compose revision and Pages build that run in it move over.
- One page per app. It shows each environment's members with their health, alerts and activity. Resources can be created inside an app, imported into it or moved out again.
- Access per environment. Apps have their own permissions, and access can be granted for one environment only. Apps can also be managed from the REST API, MCP and the AI assistant.
An app can be shut down and started again. For a security incident there is a kill switch: it cuts the app's containers off their networks, holds its Secure Links closed and freezes its members. Releasing it puts everything back as it was. Apps and environments also have their own maintenance access codes and a maintenance page for their routes.
Databases and storage on several servers
On Business and Enterprise, managed PostgreSQL, key-value stores, ClickHouse and storage can run on 2 to 5 servers. One primary takes reads and writes, the copies follow it, and one of them takes over when the primary fails.
Failover between those servers keeps working while Opfield itself is down. Relays allowed in Settings > Relay and Docker nodes on other hosts act as witnesses that help decide which server is primary.
Settings changes, version updates and restarts go one server at a time, a node update hands its primary over first, and backups read from an up-to-date copy. The dashboard points out the ones that need a look. After the license grace period they keep failing over and can still be repaired; only turning this on, adding servers and changing settings wait for a renewed license.
New key-value stores run Valkey with the JSON, Bloom and Search modules. Move to Valkey checks an existing Redis store and moves it to Valkey on the same node. Backups of deleted databases can now be listed and restored.
The Opfield name and a calmer interface
The Opfield name, logo, colours and fonts are now in the console, the sign-in page, the status page, emails, installers and the AI assistant. The sidebar has 14 items, and Routes and Certificates each open as one page with tabs.
Sections your plan does not include are hidden. A direct link to one shows the plan instead of an error.
Every audit entry now shows a readable action and description, in the audit log, its export and the activity panels.
Signed releases and the continuity grant
Opfield images and release binaries are signed with Sigstore and come with SBOMs. The Verifying Releases guide in the repository shows how to check them with cosign.
The continuity grant now goes further: if Opfield is discontinued, the source code of the last release, commercial core included, becomes available under the MIT License, and key holders can keep running it without the license service. Opfield also finds the license service through a signed list of addresses and uses the next one when an address does not answer.
Move an installation to a new host
The whole installation can be exported to one encrypted file in Settings > General and restored on another host, from the setup wizard or with install.sh --restore. Nodes and relays can be told the new address in advance.
Also in this release
- The owner of a relay's machine can make the relay protected: Opfield then has no console, file or host access through it.
install.sh --domainand--acme-emailserve the console on port 443 with a Let's Encrypt certificate that renews itself.- An installation can be connected to an Opfield Cloud account with a code in Settings > Cloud. The link's requests are audited and listed.
How to update
Installations on 2.11.4 or earlier are offered 2.11.5 first, automatically, and 2.12.0 after it. Update Opfield first, then the Docker, nginx and monitoring nodes, then the Relay Pool. Updates and the installer now come from get.opfield.dev and images from ghcr.io/opfield/opfield, so firewalls must allow get.opfield.dev. The earlier addresses keep working.
2.12.1 followed a day later and carries the name everywhere else: nodes, relays, the API, webhooks and audit events. New API tokens start with opf_, and existing tokens keep working.
The details of every change are in the changelog, and the guides for apps and databases on several servers are in the docs.