Nodes and daemons

To create VMs directly from Opfield, see Hosting providers. Connected accounts appear under Nodes > Providers. The guide covers VM power, firewall, snapshots, and billing permissions.

A Node is Opfield’s durable identity for one managed host role. The daemon reports hostname, version, health, inventory, metrics, service addresses, and role-specific capabilities through an outbound authenticated session.

Opfield separates Ingress, Docker, Storage, Build Worker, Monitoring, and Relay responsibilities. Select the exact role during enrollment and do not reuse a daemon identity for a different trust boundary.

The Node detail page is the primary place to inspect connectivity, capability mismatches, update readiness, resource pressure, recent operations, and the last synchronized state. A stale snapshot can support read-only diagnosis but never authorizes a mutation.

Identity and state

Creating a Node first creates a pending durable identity. The generated enrollment token is single-use and bound to that identity. Successful enrollment installs a daemon certificate and changes the Node to an online managed host; deleting and recreating the record intentionally creates a different identity.

Opfield distinguishes several kinds of state:

• desired state: what operators configured in Opfield;
• reported state: the latest inventory and capability report acknowledged by the daemon;
• runtime state: live service health and active operations;
• cached snapshot: the last known read model used when a node is briefly unavailable.

Cached data supports diagnosis but never authorizes a mutation. Actions that need current host state fail closed when the daemon is offline or its capabilities are stale.

Role boundaries

Role	Owns
Ingress	nginx configuration, certificates, Routes, access and traffic telemetry
Docker	containers, Deployments, Compose, images, volumes, networks, builds and migration endpoints
Build Worker	isolated Git build execution and artifact admission
Storage	managed PostgreSQL, Redis, and ClickHouse engines, managed SeaweedFS object storage (legacy MinIO clusters keep running), storage images, direct endpoints, database telemetry, and backup and restore jobs; generic workloads are rejected
Monitoring	host metrics without workload lifecycle access
Relay	authenticated node transport and supported private tunnels

Do not treat role labels as cosmetic. Each installer, daemon profile, capability set, update artifact, and permission boundary is different.

Operational checks

For every production Node, confirm:

• hostname and displayed name identify the correct physical host;
• service addresses are reachable from their intended peers;
• version and compatibility state are current;
• expected capabilities are healthy rather than merely present;
• storage, memory, CPU, and disk pressure have alerts;
• update and recovery procedures are documented;
• the Node belongs to the correct folder and permission scopes.

Ownership and trust boundary

The Node record and daemon certificate are control-plane identities, not aliases for an IP address. Reinstalling a host under a newly created Node produces a new owner even if the hostname and address are unchanged. Resources, grants, operations, and cached inventory attached to the old identity do not transfer merely because the replacement has the same display name.

Protect the host according to its role. A Docker or Storage Node can access application data, an Ingress Node holds private certificate material, a Build Worker processes potentially hostile repository input, and a Relay carries authenticated control and private streams. Avoid combining roles on one host when that would collapse a security or failure boundary. Opfield presents separate roles because their privileges and operational blast radii differ.

The daemon initiates the managed session outward, so routine operation does not require exposing a general daemon administration port. Operators still own host patching, firewall policy, time synchronization, storage health, and the network path to Relay. Opfield can report these dependencies and fail mutations safely, but it cannot repair the underlying host or network.

Acceptance after enrollment

Do not place production resources on a Node immediately after its status turns online. Wait for a fresh inventory and metrics snapshot, then verify the expected role capabilities and service addresses. Run one low-risk role-specific operation: validate nginx configuration on Ingress, inspect a test workload on Docker, run an admitted test build on Build Worker, or confirm the storage preflight on Storage.

Record the recovery path before assignment: how to reach the host, where daemon and role-service logs live, which persistent identity or data must survive, and which dependent resources need verification after restart. This turns a Node from an installed daemon into an operable production boundary.

Continue with Node roles and installation before enrollment and Node updates and offline behavior before production rollout.