Skip to content

Glossary

Use these terms in runbooks, support requests, automation, and architecture decisions. Opfield uses several familiar infrastructure words with a specific ownership or lifecycle meaning. Precise terminology matters because a Container, Deployment, Compose Project, Pages Deployment, and managed database have different rollback and deletion behavior.

Additional Route — A literal path-prefix location inside a managed ingress Route.

Binding — A durable relationship granting one managed resource access to another, such as an application database identity.

Build Worker — A dedicated Docker-daemon profile using BuildKit/containerd without a Docker Engine socket.

Deployment — A stable application identity with blue/green runtime slots and rollback state.

Desired owner — The Opfield resource or subsystem responsible for creating, reconciling, and retiring a dependent object. Objects with another owner should not be deleted as manual cleanup.

Ingress group — A set of nginx Ingress Nodes that serve the same Routes, Domains, and Pages sites, each keeping its own copy of their configuration and certificates. See Ingress groups.

Managed node — A host running a bounded Opfield daemon role.

Pages Deployment — An immutable static-site artifact release.

Relay — The long-lived authenticated data-plane service and public owner of 9443/tcp.

Route — A managed nginx traffic definition; persisted APIs may retain the historical proxy-host name.

Secure Link — A supported private authenticated connection between Opfield-managed resources, not a general VPN.

Tag — A mutable Pages release pointer targeting an immutable Deployment.

Task — A durable long-running operation such as build, migration, deployment, or update.

Access List — Reusable ingress policy containing IP rules and optional HTTP basic authentication.

Capability — A feature reported healthy by a managed daemon, used to admit operations that the host can safely perform.

Entitlement — Plan-derived authority to use a paid capability. Entitlement does not prove that the required host, Node, provider, or connector is ready.

Folder — An organizational and permission boundary grouping supported Opfield resources.

Impersonation — A visibly marked, audited administrator support session acting as another user. It is separate from the administrator’s normal session.

Inference token — A dedicated gwi_ credential for the Opfield Inference data plane, separate from ordinary Opfield API credentials.

Resource scope — Permission limited to named Opfield resources or ownership boundaries rather than every resource of a type.

System actor — An Opfield service or scheduled process recorded as the initiator of an operation rather than a human session.

Container link — A private link from a Container, Deployment, or Compose service to one port of another workload, on the same Node or another one. See Container links.

Control plane — Opfield services and persistent state used to authorize, coordinate, and audit operations. Managed workloads can continue in their documented last-applied state during some control-plane outages.

Data plane — The runtime path carrying customer traffic or private service connections, such as Ingress, Relay, Secure Links, and Opfield Inference requests.

Desired state — The durable configuration Opfield expects an owning daemon or service to apply.

Fail closed — Rejecting or deferring an operation when authorization, ownership, identity, entitlement, capability, or compatibility cannot be proven instead of selecting a less secure fallback.

Immutable artifact — A build or Pages output identified by content or release identity and not modified in place. Mutable pointers such as Pages Tags select an immutable artifact.

Lease mode — Data-plane failover of Workload Availability: the Docker Nodes, Ingress Nodes, and Relays of a workload hold a lease per serving slot and fail over without Opfield. See Data-plane failover.

Lease watchdog — The gateway-lease-watchdog service on Docker Nodes that stops a lease-mode container past its lease deadline, even when the Docker daemon or dockerd hangs.

Managed database — A PostgreSQL, Redis, or ClickHouse instance provisioned and operated on a Storage Node.

Managed storage — S3-compatible object storage provisioned and operated by Opfield on a Storage Node, private by default. New clusters run SeaweedFS; clusters created before 2.11 may run the legacy MinIO engine.

Storage connection — A saved, encrypted connection to S3-compatible, FTP, FTPS, or SFTP storage operated outside Opfield.

Storage Node — A managed Node role that runs managed databases, managed object storage, and database backup jobs; formerly the Databases role.

Operation ID — A durable identifier used to reconcile a lifecycle command when its immediate response is lost or interrupted.

Pages Project — A static-site resource containing immutable Deployments, mutable Tags, source configuration, and Routes.

Reconciliation — Comparing durable desired state with the current owner-reported state and applying or repairing the supported difference.

Reported state — The latest inventory, capability, or health state acknowledged by the owning daemon.

Route-owned binding — A Secure Link relationship created and retired with its owning ingress Route.

Runtime profile — A restricted daemon or workload mode with a defined capability and security boundary, such as Build Worker, Storage, Default runtime, or Secure Runtime.

Secure-link connector — The one connector each Docker Node runs for all its database bindings, storage links, and container links; each link has its own private network. It replaces per-link connector containers and host listeners. See Shared connector and link networks.

Service address — A role-specific reachable address reported or configured for peers that cannot use the Node’s generic local address.

System PKI — Hidden certificate authorities and identities used for Opfield-managed transport; separate from user-facing Internal PKI.

When a support discussion uses “restart,” “delete,” “ready,” or “deployed,” identify the exact resource and owner. Restarting the Opfield application, Relay, daemon, Node, workload, and database engine has different consequences; a completed Task and a customer-verified outcome are also different states.