Opfield 2.12.3

Opfield 2.12.3 is out. Most of the work in this release went into keeping disks from filling up, making agent access safer, and fixing rough edges in Git builds, Pages and managed databases. Below are the changes most users will notice. The full list is in the changelog.

Disks stay bounded

A control plane that runs builds, images and logs across many servers can quietly fill a disk. In 2.12.3 every place that grows has a limit.

• The internal registry keeps two builds per container, deletes the builds of removed sources and stops accepting new builds when its disk is 90% full.
• Docker nodes remove images that nothing has used for 12 hours. Each container keeps the image it runs and one to roll back to.
• Container logs on Docker nodes stay bounded, including containers created before Opfield or outside it. Nginx nodes keep route logs within a size limit and remove the logs of deleted routes.
• Postgres WAL and replication slots no longer fill a database disk.
• Housekeeping keeps Opfield's own data bounded even when it is switched off, and runs at once when an Opfield disk reaches 90%. It also shows what fills each disk: the largest tables, Redis, container logs, and old images per node.

New built-in alerts warn you before this becomes a problem: disk alerts at 85% that cover every data disk of a node, Opfield disk full, full database disks, and Housekeeping not running.

A guard for agent console commands

The assistant and MCP clients can run commands in a node console. They run as root, so an agent can actually repair a node. Docker, containerd and Podman are masked in that console: a command that uses Docker is refused with the name of the Opfield tool to use instead.

This is an accident guard, not a security boundary. It keeps an agent from changing a managed container behind Opfield's back by mistake. Agents also can no longer run commands over SSH on hosts that are Opfield nodes.

If a managed container is still stopped, changed or removed by hand, the new built-in alert "Container changed outside Opfield" fires and explains what the change means.

Access list rules in order

Access list rules are checked from top to bottom, and the first match wins. Until now the order could not be changed, so an allow rule added after a broad deny could never match. Rules can now be reordered in the interface, the API and MCP, and rules that can never match are flagged.

Failover order for databases and storage

For managed Postgres, key-value stores, ClickHouse and S3 storage with availability, you can now set the failover order: which server takes over first when the primary fails.

Registry in S3

The internal registry can store its data in S3 instead of on the Opfield host's disk. A storage switch checks every image the registry keeps for workloads.

Pages and error pages

Pages projects serve their own 404.html for missing paths, with a 404 status.

Every page that nginx generates itself (errors, denied clients, unreachable upstreams, the default server) is now an Opfield page. Your applications' own error pages pass through unchanged.

Git sources

• A Git-source container can be rolled back to its previous build from the Source tab, the API or MCP.
• A failed build shows the failing Dockerfile step and its exit code, and a source says why a build failed or deployed nothing.
• Environment variables, secrets and volumes can be set before the first build, and the first build starts right away.
• The build security policy can block only vulnerabilities that have a fix, either for application packages or for all packages.

Also in this release

Routes behind Cloudflare see the real client IP in access lists, rate limits and logs. Managed Postgres runs on Opfield's own images, and PostGIS and pgRouting install on demand from the Extensions tab.

One thing to know before you update: container archives now use the Opfield format (.ofca). Archives exported by earlier releases cannot be imported.

Self-hosted installations update as usual. Managed cloud installations update in their maintenance window.