Capability index
| Area | Current documentation |
|---|---|
| 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 |
| 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 |
| Gateway Inference | Gateway 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. See the HA guide.
- Storages — expected in 2.11: external connections on every plan; managed storages with Secure Links on Personal and higher.
- Managed-database backup and restore — expected in 2.12, Personal and higher.
- Gateway 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 Gateway 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 Gateway instance can use it.
Use this index to answer three evaluation questions: whether Gateway 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, and monitoring.
- Databases: external connections, managed PostgreSQL/Redis/ClickHouse, explorers, monitoring, direct TLS, and private application bindings.
- 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, scenarios, Plan Mode, and Gateway Inference.
- 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 Database 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 Gateway’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”Gateway 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 Gateway where the organization needs their depth. The relevant Gateway value is a consistent ownership, authorization, workflow, and audit layer across the supported resources—not a claim to absorb every infrastructure discipline.