Capability index
| Area | Current documentation |
|---|---|
| Pre-purchase questions | Evaluating Opfield |
| Ingress, Domains, Routes, TLS | Ingress overview |
| Docker containers and Deployments | Docker overview |
| Compose Projects | Compose Projects |
| Git builds and Build Workers | Git sources and Build Workers |
| Managed and external databases | Databases overview |
| Database backup and restore | Database backups |
| Storage connections and managed object storage | Storage |
| Private database bindings | Application database bindings |
| Pages | Pages overview |
| Monitoring, logs, notifications, and status | Monitoring and operations signals |
| Identity and permissions | Authentication, users, and groups |
| AI Workspace | AI Workspace |
| Opfield Inference | Opfield Inference |
| Security and operations | Security model |
Availability and target versions
Section titled “Availability and target versions”- Workload Availability (HA) — available, Business/Enterprise: replication or failover for mount-free Containers, Deployments, and whole Compose Projects, with an optional node priority order and automatic return to the primary. When every participant runs 2.11, the Nodes fail over by themselves without Opfield (data-plane failover). See the HA guide.
- Ingress groups — available, Business/Enterprise: a Route, Domain, Pages site, or the status page served by several nginx Ingress Nodes at once, with per-member delivery, health, and logs, and a health endpoint for load balancers. See Ingress groups.
- Storage — available in 2.11, Personal and higher: connections to S3-compatible, FTP, FTPS, and SFTP storage, and managed SeaweedFS object storage with private workload links and Secure Links. See Storage.
- Container links — available in 2.11.1, Personal and higher: private access from a Container, Deployment, or Compose service to one port of another workload, on the same Node or another one, with no published port. See Container links.
- Database backup and restore — available in 2.11, Personal and higher: native backups of managed and external PostgreSQL, Redis, and ClickHouse to storage connections. See Database backups.
- Opfield configuration export for transfer to another instance — expected in 2.12, every plan.
Future versions are estimates. The full plan matrix separates ready capabilities from the roadmap.
The general Opfield CLI is expected in 2.13 on every plan, and the Bastion / SSH management daemon in 2.14 on Business and Enterprise. The plugin system is documented separately as future core infrastructure: not yet implemented, tentatively no earlier than 2.20, with no guaranteed release date.
Capability status
Section titled “Capability status”| Status | Meaning |
|---|---|
| Ready | Available in the current product, subject to plan and runtime prerequisites |
| Ready, opt-in | Available but hidden or inactive until an administrator enables it |
| In development | Included in product direction or plan positioning but not generally available |
| Plan benefit | Commercial or service-level benefit rather than a runtime feature |
Plan inclusion and runtime readiness are separate. A checkmark for an In development capability means the plan is intended to include it after release, not that the current Opfield instance can use it.
Use this index to answer three evaluation questions: whether Opfield owns the workflow, which infrastructure prerequisite provides it, and which plan admits it. A feature can be documented and licensed but unavailable on a particular installation because the required Node role, connector, provider, or runtime capability is not healthy.
Current product families
Section titled “Current product families”- Ingress: Domains, Routes, TLS, access lists, maintenance, health checks, managed upstreams, and nginx placement.
- Docker: standalone containers, blue/green Deployments, Compose inventory and lifecycle, images, volumes, networks, registries, builds, migrations, archives, tasks, monitoring, and container links (Personal and higher).
- Databases (Personal and higher): external connections, managed PostgreSQL/Redis/ClickHouse, explorers, monitoring, direct TLS, private application bindings, and scheduled backup and restore.
- Storage (Personal and higher): S3-compatible, FTP, FTPS, and SFTP connections with an object browser, managed SeaweedFS object storage with access keys, private workload links, and optional public listeners, server-side copy jobs between S3 storage, and assistant-driven migration of legacy MinIO clusters.
- Pages: immutable static deployments, Tags, Routes, previews, and optional Git builds.
- Nodes and Relay: role-based enrollment, capability reporting, signed updates, monitoring, and multi-member Relay operation.
- Identity: users, groups, MFA, OIDC, tokens, OAuth, resource scopes, and impersonation.
- Operations visibility: health, metrics, logs, Tasks, alerts, notifications, status pages, structured logging, audit, and SIEM. These are connected product surfaces, not one universal observability dashboard.
- Automation and AI: REST, OAuth, MCP, AI Workspace chat, and Opfield Inference on every plan; AI Plan Mode, Scenarios, and Sandboxes on Personal and higher.
- Security: system PKI, user-facing Internal PKI, encrypted secrets, audit, admission boundaries, and fail-closed lifecycle checks.
Runtime prerequisites
Section titled “Runtime prerequisites”A plan entitlement does not replace host capability. Secure Runtime needs a healthy gVisor capability, Git builds need a dedicated Build Worker, managed databases need a prepared Storage Node, public ingress needs a reachable Ingress node, and private links need a healthy Relay path.
Use the feature-specific page to verify prerequisites, lifecycle consequences, and recovery behavior before enabling a capability in production. See Plans and entitlements for plan behavior.
Evaluation path
Section titled “Evaluation path”For a product evaluation, begin with the business journey rather than the longest feature list. Choose one representative public application, one private data dependency, one managed Node role, and one operator identity. Prove deployment, access control, customer traffic, monitoring, failure recovery, and audit for that journey. Then add higher-level capabilities such as Git builds, Pages, managed databases, AI, or SIEM only when they match the intended operating model.
Record each result as:
- supported and verified on the tested installation;
- supported with an unmet prerequisite;
- plan-restricted;
- in development; or
- outside Opfield’s product boundary.
This avoids treating roadmap positioning, a disabled UI control, and a failed runtime capability as the same thing.
Product boundary
Section titled “Product boundary”Opfield coordinates infrastructure resources and their supported lifecycle. It does not replace Kubernetes, infrastructure-as-code, professional monitoring/SIEM, host security, network firewalls, engine-native database tooling, or disaster-recovery systems. Use those systems alongside Opfield where the organization needs their depth. The relevant Opfield value is a consistent ownership, authorization, workflow, and audit layer across the supported resources—not a claim to absorb every infrastructure discipline.