On this page
Use the Cloud console
Understand the browser-first Cloud workspace, its scopes, real operation states and the actions available without a local command line.
These steps describe the intended customer path. Use the interface only after personal access and written confirmation of this capability in your pilot scope.
Before you start
The Cloud web experience is being prepared as a single authenticated workspace. During the pilot phase, access, scope and supported actions are confirmed in the individual proposal. No customer infrastructure credentials are placed in the browser.
1. Know the workspace
The target Cloud experience keeps commercial and Kubernetes work in one product shell. The same signed-in workspace carries the selected organization, role and cluster scope into every page; a second account portal is not part of the intended customer path.
| Area | What you see | Safe action |
|---|---|---|
| Overview | Current workspace, active operations and attention items with a freshness indicator. | Open the related operation; do not infer success from a page load. |
| Clusters | Clusters, capacity, lifecycle status and the scope of the selected workspace. | Review the quote and limits before requesting a change. |
| Applications | Approved application inputs, revisions, rollout state and bounded rollback actions. | Use a supported input and wait for the observed release state. |
| Usage & support | Confirmed usage, proposal-specific costs and a redacted support context. | Export only the information your role is allowed to share. |
2. Follow one browser operation
Every change is represented as a durable operation. A refresh, a lost browser tab or a short network interruption must not erase what was requested or what the platform observed.
- 01
Select the scope
Choose the organization, workspace, cluster and application shown in the page header. If a resource is not in your scope, stop instead of trying another URL.
- 02
Review before confirming
Read the requested action, resource limits, price impact and irreversible steps. A browser request is not a payment or provisioning confirmation until the backend records the verified result.
- 03
Observe the result
Follow the operation ID, timestamps and real observed state. Retry only when the page offers a bounded retry; otherwise use the support path with the operation ID.
3. Read states without guessing
| State | Meaning | Next step |
|---|---|---|
| Requested | The request is accepted for validation; no resource is ready yet. | Wait for the next observed update. |
| Running | A durable operation is executing and may still be retried or reconciled. | Keep the operation ID and avoid duplicate requests. |
| Ready / healthy | The qualified checks for this resource have passed at the displayed time. | Use the resource within the confirmed scope. |
| Degraded / failed | The platform observed a problem or could not complete the operation. | Read the reason, preserve the ID and contact support when needed. |
| Unknown / delayed | Fresh observation is unavailable; this is not a green or successful state. | Do not repeat a chargeable action; wait or escalate. |
4. Keep the browser boundary safe
- ✓Never enter provider API keys, kubeconfigs, private keys or cluster-admin tokens into a Cloud form.
- ✓The browser receives scoped data and actions; ClusterPilot keeps provider credentials and privileged orchestration behind the service boundary.
- ✓A missing button means the capability is not enabled for the workspace; do not work around it with an untracked command.
- ✓Share operation IDs and redacted error details with support, never raw secrets or complete request bodies.
Manage a cluster in the Cloud → · Deploy an application with Helm in ClusterPilot → · Operate from the Cloud workspace →
Use this guide within your agreed pilot scope. Kubernetes examples are not evidence of a generally available Cloud capability.