Create clusters
Plan infrastructure, verify prerequisites and provision Kubernetes through a documented workflow.
Controlled self-service Kubernetes
Self-service Kubernetes for platform teams—with guardrails instead of unrestricted access.
ClusterPilot turns recurring cluster work into reviewable workflows. Teams can request and follow approved operations without sharing permanent administrator access or rebuilding the process from tickets and shell history.
Self-service Kubernetes at a glance
Which Kubernetes tasks can become controlled self-service?
Authorized users start the right workflows through a clear interface. The platform team defines choices, permissions and requirements.
Scale clusters
Add or reduce nodes through a controlled operation and retain every step.
Update Kubernetes
Check versions, compatibility and order before the upgrade and keep the result.
Repair failures
See failure context, diagnostics, node replacement and safe next actions on the operation.
Operational challenge
Self-service fails when speed and control are designed separately.
A portal alone does not create a safe platform. Teams need approved choices, clear ownership, bounded execution and a result that operations and QA can review.
Ticket queues
Routine cluster work waits for the few people who know the provider, bootstrap and recovery runbooks.
Overpowered access
Direct cluster-admin access makes simple requests fast, but weakens separation of duties and accountability.
Invisible outcomes
A completed request rarely preserves the exact plan, ordered steps, result and cleanup context in one place.
Enterprise value
A self-service layer for controlled cluster operations.
The value comes from shared state, explicit ownership and reviewable execution.
Approved choices
Provider settings, topologies, versions, add-ons and validation modes come from an explicit supported contract.
Guarded execution
Identity, scope, readiness, compatibility and risk are checked before a lifecycle agent reaches the target environment.
Shared evidence
Request, actor, plan, status, logs, artifacts and recovery context remain connected to the OperationRun.
Controlled workflow
From request to reviewable outcome
The platform team defines the permitted path once; authorized users reuse it through the UI or API.
Choose an approved task
Select a provider, target, lifecycle action, add-on or validation mode within the released capability contract.
Review the plan
Check prerequisites, affected resources, compatibility, permissions and explicit confirmation before mutation.
Run through the agent
Assign bounded work to the lifecycle agent and follow ordered steps, status and stable failure context.
Retain the result
Keep artifacts, checksums, cleanup state and recovery guidance available to platform, QA and support teams.
Evidence
Self-service that remains accountable.
Every permitted action produces a durable record instead of a one-time portal response.
Who requested it
Authenticated actor, team, permission, target and confirmation context.
What the platform ran
Versioned intent, plan, admission decision, step order, lifecycle-agent assignment and immutable software subjects.
How it ended
Terminal state, logs, artifacts, cleanup, retry history and a safe next action when work stops.
Frequently asked questions
Questions about Self-Service Kubernetes Platform
Short answers about use, workflow and next steps.
What is self-service Kubernetes?+
Self-service Kubernetes lets authorized users request approved cluster or platform operations without waiting for a manually executed runbook. The platform team still defines permissions, choices, checks and execution boundaries.
Which Kubernetes tasks can ClusterPilot automate?+
ClusterPilot supports workflows for infrastructure planning, cluster creation, inspection, scaling, Kubernetes upgrades, node replacement, deletion, add-on installation and Kubernetes validation.
Is self-service Kubernetes the same as managed Kubernetes?+
No. Self-service describes how internal users request work. Managed Kubernetes describes who carries operational responsibility. ClusterPilot is customer-hosted software and does not transfer that responsibility to an external provider.
Can developers receive unrestricted kubectl access?+
That is not the ClusterPilot model. The current release exposes bounded workflows and read-oriented operational context rather than generic cluster-admin mutations.
Can ClusterPilot adopt any existing cluster?+
The current evaluated lifecycle path applies to clusters managed by ClusterPilot. A general detach or adoption contract is not claimed for v0.0.5.
Start with a measurable workflow
Simplify your most important Kubernetes workflow together.
We review your environment and current workflow, then show the implementation with ClusterPilot.
hello@clusterpilot.de