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.

What you get

A managed installation is a full Opfield, the same release as self-hosted, at <name>.opfield.cloud. You buy and manage it in the account portal, together with a paid license key (Personal, Business or Enterprise). It is not available with Community.

• Region: Finland. Germany is planned.
• Sign-in with your Opfield account. The owner signs in to the installation with the same account they use in the portal.
• Daily backups. A backup runs every day. You can also back up on demand and restore from the portal. After a delete, the newest backup is kept for a few days, so the installation can be brought back.
• Updates in your maintenance window. You choose a day and an hour (UTC). Opfield takes a backup, updates and comes back on the new version. You can also update right away.
• Your nodes stay yours. You enroll your own servers with one-time tokens from the portal. Workloads, databases and storage run on them, not on the managed VM.

Plans

Prices are per month, on top of the license key, and renew together with the key.

Twelve months cost the price of eleven. You can move from Standard to Extended at any time and pay the difference for the rest of the period; Opfield restarts once. A move down takes effect at the end of the paid period.

Email included

Opfield sends system emails: sign-in codes, password setup and reset links, invitations. A self-hosted installation needs an SMTP provider for that. A managed installation sends them out of the box, from <name>@mail.opfield.cloud, in both plans and at no extra cost.

The limits are generous for system mail and keep the shared sending reputation clean:

• Standard: 500 a month, 50 a day, 25 an hour.
• Extended: 2,000 a month, 200 a day, 50 an hour.

Your own domain

The installation can answer on your own domain, for example ops.example.com. Add the domain on the installation's page, create the CNAME record it shows, and Opfield gets a certificate for it. The opfield.cloud address keeps working. Passkeys are tied to the address, so they have to be added again after a change; the page tells you before you switch.

AI included

Opfield has a built-in AI assistant and an MCP server for your own agents. Both need a model. On a managed installation, Opfield Cloud AI is already connected:

• Free, with every managed installation: model usage included.
• S, $9/month.
• M, $29/month, with twice the usage of S.

There are two models: Opfield Swift for quick everyday work, and Opfield Heavy for longer and harder tasks. Usage is shown as a percentage of each window, with the time the window resets. When a window is used up, the assistant says so and works again once it resets. Nothing else in Opfield stops.

Getting started

In the account portal, turn on "Host it in our cloud" when you buy a key, or choose "Add managed cloud" on the page of a key you already have. After payment the installation is set up automatically, and you get an email when it is ready. Plans and prices are also on the pricing page.

The same rules as for a person

Agents have no separate permission model. An MCP client connects to https://<your-opfield>/api/mcp and signs in with OAuth on behalf of a user. On the consent screen the user picks the scopes the client gets, and those scopes can never go beyond what the user can do. Access limited to folders, nodes or single resources works the same way: an agent with access to one app's folder sees that folder and nothing else. The agent can call get_my_access to see what it was given and where it may create things.

Agents can do nearly everything a person can do with resources. A few things stay in the browser on purpose: impersonation, OAuth consent, creating API tokens or authorizations, and the user's own sign-in and sessions. An agent cannot give itself more access.

The MCP endpoint accepts only OAuth tokens issued for it; REST API tokens do not work there. The user also needs the MCP permission, so an admin decides who may connect agents at all.

Everything lands in the audit log

Every agent action passes the same checks as a click in the interface and is written to the same audit log, with the user and the token it came from. To see what an agent changed overnight, open the audit log.

Guards against accidents

Permissions decide what an agent may do. Some mistakes happen inside those permissions, so Opfield adds guards:

• Console guard. Agents can run commands in a node console as root, which lets them repair a node. Docker, containerd and Podman are masked there, and a Docker command 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.
• No SSH into nodes. Agents cannot run commands over SSH on hosts that are Opfield nodes. They use the node console, which has the guard.
• Changes outside Opfield are visible. If a managed container is stopped, changed or removed by hand anyway, the built-in alert "Container changed outside Opfield" fires.
• Safe retries. Create operations accept an idempotency key, so an agent that retries after a timeout does not create a duplicate.

Docker tools instead of a shell

Most agent work on workloads goes through dedicated tools rather than shell commands: list containers across all Docker nodes, read logs and stats, restart, update an image, change configuration, manage deployments with slots and rollback, Compose projects, volumes, networks, and Git sources with their builds. Because these are Opfield operations, routes, Secure Links and availability stay consistent after a change, and each step is audited.

Agents can also read Opfield's documentation and skills through MCP before they change anything.

Example: a failing service

A user asks an agent: "The billing API has returned 502 since this morning. Find out why and fix it." A typical session:

1. find_resource finds the route and the container behind it; get_route shows the upstream.
2. get_docker_container shows that the container keeps restarting and that its Git source deployed a new build at 07:40.
3. get_docker_container_logs shows the process exiting on start because a new required environment variable is missing.
4. The agent reports this and offers two options: roll back to the previous build, or add the variable.
5. The user chooses the rollback. The agent calls manage_docker_source with rollback, then checks the logs and the route again: the container is running and the route answers 200. The rollback is in the audit log under the user's name.

Nobody needed shell access to the server, and the agent did nothing outside the user's own permissions.

Getting started

Add the MCP server to your client with your Opfield address, sign in and choose the scopes. Start with read-only scopes, watch what the agent does in the audit log, and widen access as you gain confidence. If you would rather not set up a client, the assistant built into Opfield uses the same tools and the same rules.