Opfield 2.12.7: moving ingress between nodes, folders for alerts and relay ports
Domain moves between ingress nodes that take Pages routes along and list what blocks them, folders for alert rules, webhooks and access lists, relay ports you can change without dropping connections, and Opfield AI on self-hosted installations.
By the Opfield team4 min readUpdated
Opfield 2.12.7 is out. Since 2.12.3 we have shipped 2.12.5, then 2.12.6 and 2.12.7 on the same day. Together they make moving ingress between servers more predictable, give relays a port you choose, fix container alerts and bring Opfield AI to self-hosted installations. Below are the changes most users will notice. The full list is in the changelog.
Moving a domain to another ingress node
You move a domain to another ingress node when a server is replaced or retired. In 2.12.7 the move takes more along and tells you more before it starts.
- Pages routes move too. A domain's Pages routes now go to the new node together with its other routes.
- The preview lists every blocker. Before anything changes, the move preview shows everything that blocks the move and how to fix each item.
- An offline source node is not a dead end. A move from a node that is offline finishes on its own once the node comes back.
- Rollbacks are audited. A rolled-back move is recorded in the audit log.
As before, Cloudflare-managed DNS is updated during the cutover. With external DNS, you update the records yourself before the move completes.
Relays on the port you choose
Relays carry private connections between your servers, so workloads and databases need no open ports. A relay no longer has to listen on the default 9443/tcp.
You can now enter a Relay Port when you add a relay or order a relay VM through a hosting account. The generated install command carries that port, and only that port has to be open on the relay host.
To change the port of a running relay, open the new port in the firewall and any port forward first, then use Change port on the relay in Settings > Relay. The same action is available in the API and over MCP. Opfield drains the relay, waits until its streams have moved to other relays, restarts it on the new port and returns it to the pool. If the relay does not come up on the new port within 20 seconds, it goes back to the previous one, and the relay row shows the reason, for example that the address is already in use.
A few limits: the relay needs the 2.12.6 relay release, so update the Relay Pool from Settings > General first. A protected relay changes its port on the host by re-running the installer. The local relay keeps 9443/tcp, because that port is also the endpoint every node uses to reach Opfield.
Alerts, folders and availability
- Container alerts fire. Container Started and Container Stopped rules set up for a specific container now fire. When a container alert resolves, it shows how long the container was stopped.
- Availability shows a missing replica. An availability policy now shows degraded while a node holding one of its replicas is offline.
- Folders for alert rules, webhooks and access lists. They can now be organized in folders, like other resources. Permissions can be given on a folder: it covers the folder, its subfolders and everything inside them, so a team can manage its own alert rules, webhooks and access lists. A rule sends only to webhooks its author can view.
Opfield AI and updates
The AI add-on is now called Opfield AI. Since 2.12.5 it also works on self-hosted installations connected to Opfield Cloud: through the inference core when it is installed, or directly in AI Workspace when it is not.
Budgets and subscriptions no longer get in each other's way. A spent monthly API budget does not block subscription models, and a spent subscription window does not block API models. A model held back by the API budget says the budget is used up instead of showing as unavailable. When Opfield AI ends, AI Workspace moves to another published model instead of turning off, and the default API budget goes back to what it was.
Opfield and its node daemons now take their updates from the Opfield update feed. A failed daemon update now shows why it failed.
Updating
Self-hosted installations update as usual. Managed cloud installations update in their maintenance window. Every change is listed in the changelog, and the details are in the docs.