On this page
Cloud product status
See what is documented for an agreed pilot, what is planned for the Cloud web experience and what still requires qualification or approval.
Use this planning guidance now for an inquiry and pilot proposal. Service commitments require a written agreement.
Before you start
This page explains the intended product direction. It is not a release schedule, service-level agreement or order confirmation. Your signed pilot proposal is the source for the scope delivered to you.
1. Read the status correctly
The documentation deliberately distinguishes instructions you can use after a pilot handover from planned capabilities. A documented Kubernetes procedure does not by itself mean that the surrounding managed service is generally available.
| Status | Meaning | Action |
|---|---|---|
| Ready to use on this website | Planning guides, pricing drafts and the inquiry form are available without a Cloud account. | Prepare the workload brief and request a proposal. |
| Planned Cloud capability | The capability is part of the planned delivery direction, but is not presented as generally available. | Do not design a production dependency around it yet. |
| Qualification required | Technical proof, operating evidence, commercial approval or a contractual definition is still required. | Confirm it in your proposal before relying on it. |
2. Follow the planned delivery path
The Cloud service is released in controlled stages. Each stage depends on verified results from the previous one; passing a code review is not the same as production acceptance.
- 01
Audit the existing product
Verify deployed architecture, identity, data stores, routes and operational ownership before consolidating or retiring any portal.
- 02
Qualify the commercial foundation
Prepare organization-aware identity, hosted payment, subscription state, entitlements, quotes and invoice integrity. No payment flow is treated as live before end-to-end qualification.
- 03
Prove infrastructure and cluster lifecycle
Provision ClusterPilot-owned infrastructure with tenant isolation and observable create, scale, upgrade and delete operations.
- 04
Unify the console and application workflows
Bring cluster, application, usage, billing, organization and support views into one Cloud console, then qualify the supported deployment paths.
- 05
Pass operational and release gates
Use real end-to-end evidence, security review, recovery tests, unit-economics checks and explicit human approval before a broader launch.
3. Understand the intended customer journey
The target experience starts at the public website and ends in one operational console. During the pilot phase, inquiry, proposal and handover replace the not-yet-qualified self-service steps.
| Journey area | Planned Cloud experience | Current pilot path |
|---|---|---|
| Account and organization | Self-service signup, login, organization/workspace and roles. | Identity and contacts are agreed during qualification and handover. |
| Plan and payment | Monthly or annual plan, hosted checkout, subscription state and customer portal. | A pilot inquiry leads to an individual proposal; no online payment is taken. |
| Infrastructure and cluster | Quote, ClusterPilot-provided resources and observable lifecycle operations without a customer provider account. | Capacity, price and supported operations are confirmed before provisioning. |
| Applications | Browser-based release paths for an approved OCI image or supported YAML/Helm package. | Use only the input, target and application scope confirmed for your pilot. |
| Operations | Status, activity, monitoring, backups, upgrades, usage, billing and support in one browser workspace. | Use the browser views and agreed support channel for the capabilities qualified in your pilot. |
4. Know the release guardrails
The following remain subject to evidence and explicit approval: final plan prices and limits; taxes and billing rules; monitoring coverage; backup retention and successful restores; high-availability topology; RPO/RTO; support response targets; and a general-availability date. Until confirmed, these are discussed as planned or proposal-specific.
- ✓Treat the pricing page as a transparent draft until your proposal confirms platform and infrastructure costs.
- ✓Require an observed restore result before treating backups as an operational safeguard.
- ✓Require measured behavior and an agreed design before relying on high availability or recovery targets.
- ✓Use subscription, usage and invoice status only after the end-to-end commercial flow has passed release gates.
ClusterPilot Enterprise remains a separate Self-Hosted offer for operation in the customer's environment. Its documentation and the separately scoped Technical Evaluation remain available; they are not evidence that a Cloud capability is already delivered.
Use this guide within your agreed pilot scope. Kubernetes examples are not evidence of a generally available Cloud capability.