CONFIGURE. VALIDATE. OPERATE.

Build your Kubernetes cluster.Stay in control.

Configure hosts, networking, storage and tools through a guided workflow. Operate your clusters in Navigator, with resources, events, logs and YAML in context. Your infrastructure credentials stay encrypted on your device.

Windows desktop · Infrastructure supplied by you · Download not yet available

Real KubeRocks Desktop capture with a connected cluster. Click to enlarge and inspect the details.Actual application screenshot
01

Guided setup with real checks

Guided steps and checks before installation.

02

Navigator for everyday operations

Clusters, resources, events and access in one workflow.

03

Infrastructure credentials on your desktop

SSH secrets protected in local storage.

INSIDE THE PRODUCT

Explore KubeRocks, one decision at a time.

Open any chapter to see the screen behind that task. The path starts with configuration, moves through the platform and finishes with operations and local access.

Start with the complete workflow

See how decisions lead to review, with operational panels close to configuration.

Overview of the KubeRocks configuration stepper.Actual application screenshot

Locate the stages before filling in the fields.

Use the path to plan; installation starts only through an explicit action in the application.

1 / 12

Real application captures with a connected lab cluster. Browse the chapters and enlarge each screen to inspect the fields; figures reflect the moment of capture.

Read the configuration guide

From the first decision to the next investigation.

A cluster starts before the first command: which hosts to use, how to distribute roles, where to persist data and how to reach applications. KubeRocks organizes those decisions, exposes dependencies and keeps review close to execution.

The work continues after installation. Resources, access information, events, capacity and operational tools remain in the same application, so you can retain the context you need for the next task.

01

GUIDED CONFIGURATION

Each choice prepares the next step.

The stepper follows configuration from the environment through review: control planes, workers, networking, checks, storage, Gateway, platform, observability and security. Fields appear alongside the decisions they support, with help that explains their impact.

Review the plan before execution and follow installation in the console. Operational panels sit alongside configuration, keeping the information you need nearby as the work progresses.

  • A complete pathEleven fixed steps organize preparation. The production profile adds HAProxy / Load Balancer.
  • Help beside the fieldDomain, certificate and configuration explanations clarify decisions without requiring you to leave the form.
  • A plan you can reviewTopology, selected components and resource requirements remain available for review before execution.
  • Operational visibilityConsole and access panels keep configuration visible and can be rearranged around the task in progress.

IN YOUR WORKFLOWWhen preparing a staging environment, start with the hosts, check networking and then size the platform you actually intend to use.

Explore the setup decisions
Complete KubeRocks configuration stepper with cluster stages and the operational workspace.Actual application screenshot

The workflow organizes and validates configuration. Installation time and results depend on the hosts, connectivity and selected components.

02

CLUSTER ARCHITECTURE

See the topology before you put it to work.

Choose the environment and assign cluster roles. The architecture preview turns control planes, workers and load balancers into a layout you can inspect while configuring their addresses.

The Prod profile requires at least three control planes, three workers and two HAProxy hosts with a VIP for the API endpoint. That decision makes its infrastructure requirements visibly different from those of a small lab.

  • Environment profilesDev, integration, QA, load testing, staging, UAT, pre-production and production describe scenarios with explicit topology requirements.
  • Separate rolesControl plane and worker IPs are configured in their own steps, with minimum host counts determined by the profile.
  • A stable API addressIn production, HAProxy hosts, the VIP and the API domain form the path to the control plane.
  • A preview for reviewExplore distribution by area, adjust zoom and inspect the architecture diagram before starting installation.

IN YOUR WORKFLOWCompare a development lab with your intended production topology before ordering or reorganizing machines.

Explore the topology decision
KubeRocks architecture preview showing host organization and cluster roles.Actual application screenshot

The Prod profile already contains six Kubernetes nodes and does not fit the proposed Free plan, which allows five. Choosing the profile also does not prove the availability of every installed application.

03

ACCESS & READINESS

Find the blocker before installation.

Entering an IP address does not make a host ready. Access & Readiness checks connectivity, authentication and system conditions to explain what is available and what needs attention on each machine.

The workflow distinguishes a connection attempt from an actual result. Preparation checks requirements including sudo, connectivity, Python, operating system, hostname, CPU, memory, disk, swap and networking; mandatory failures prevent installation from proceeding.

  • Connection per hostCheck whether the desktop can reach hosts using the selected connection parameters and credential.
  • Visible requirementsResults by category help locate a permissions, capacity or compatibility issue.
  • Disks and capacityDiscovery informs storage selection and component planning.
  • Checks after installationThe workflow also checks the API, nodes, system components, CNI, DNS and communication and produces an operational report.

IN YOUR WORKFLOWIdentify an unreachable worker or insufficient capacity while you are still preparing the environment, with the problem attached to the correct host.

Follow the readiness checks
KubeRocks Access & Readiness showing hosts and individual check results.Actual application screenshot

Checks cover defined requirements. A passing result does not replace load testing, security review or validation of your applications.

04

PERSISTENT STORAGE

Know which disks will hold your data.

Rook-Ceph configuration starts with disks discovered on workers. Review each node’s device, capacity and state before allocating storage to the cluster.

That choice connects to the rest of the platform: components that require persistence expose their requirements, and planning compares requested volumes against an estimate of usable capacity.

  • Devices per nodeReview the path and capacity of eligible disks found during access checks.
  • Existing data is visibleThe workflow distinguishes clean disks, disks in use and existing signatures, and requires confirmation when preparation involves erasure.
  • Persistence for the platformThe catalog organizes volumes for components such as Prometheus and Grafana alongside the storage decision.
  • Capacity before ApplyCompare storage requests with estimated capacity and identify excess demand before execution.

IN YOUR WORKFLOWBefore enabling observability with retention, check that enough dedicated disks are available and that the planned volumes fit.

Explore storage selection
Per-worker disk selection for Rook-Ceph in the KubeRocks Storage step.Actual application screenshot

The current Rook-Ceph workflow requires eligible disks on at least three workers. Initializing a selected disk can erase its contents; redundant storage does not replace backups and restore testing.

05

NETWORKING, DOMAINS AND TLS

Define how traffic reaches your applications.

Pod CIDR, Service CIDR and the LoadBalancer IP pool form the networking foundation. In Ingress / Gateway, connect that foundation to your Gateway choice, domain names and the certificates serving your traffic.

Configuration distinguishes infrastructure access, such as dashboards, from application domains. Wildcard, exact-host and multi-host certificates cover different names, and that difference is part of route validation.

  • Cilium for the network foundationThe workflow uses Cilium for connectivity and LoadBalancer functions, with a configurable IP pool.
  • A Gateway with a purposeCilium Gateway is the default choice; Istio serves scenarios that need additional service mesh capabilities.
  • Certificate checksValidation checks that the key matches the certificate, its validity period and SAN hostname coverage before exposure.
  • Local access testingGateway information and hosts entries help test names before relying on public DNS.

IN YOUR WORKFLOWKeep platform dashboards on an infrastructure domain while planning a separate domain for the team’s applications.

Explore domains and certificates
Istio Gateway flow diagram showing configured domains, Gateway, services and cluster paths.Actual application screenshot

DNS, network reachability and certificate trust must be configured correctly. An internal or self-signed certificate does not automatically become trusted by every browser.

06

PLATFORM ENGINEERING

Build the platform your work calls for.

A useful platform connects software delivery, artifacts, data and operations. The catalog organizes those choices and opens component-specific configuration instead of treating every installation as a checked box.

Evaluate pipelines with Tekton or Jenkins, repositories with Harbor or Nexus, analysis with SonarQube and backups with Velero. Each option has dependencies, persistence requirements and its own profile; selecting everything is not a required starting point.

  • Software deliveryTekton, Jenkins, GitLab CE and GitLab Runner configurations support different pipeline and integration designs.
  • Artifacts and qualityHarbor, Nexus and SonarQube have controls and requirements specific to the offered profile.
  • Data and messagingPostgreSQL, Redis, Kafka and RabbitMQ expose profile, replica and persistence settings; choosing single-instance or production changes their requirements.
  • Scaling and recoveryKEDA organizes event-driven scaling. Velero offers external S3 or Rook-Ceph S3 configuration, with a bucket and credential reference appropriate to the mode.

IN YOUR WORKFLOWFor a team beginning to publish applications, select the delivery and artifact services it needs, review persistence and then add other services.

Explore platform choices
Platform Engineering groups: GitOps, CI/CD, artifacts, scaling, backup, quality, databases and messaging.Actual application screenshot

Availability and installation lifecycle vary by component. Jenkins, Nexus and SonarQube Community profiles do not provide application HA; GitLab CE and Harbor have their own limits. A selected item is not yet an installed service.

07

OBSERVABILITY

Plan how you will see what happens in the cluster.

Metrics, logs, traces and profiles answer different questions. Configuration organizes Prometheus, Grafana and Alertmanager alongside components such as Loki, Tempo, Pyroscope and Alloy, with persistence and retention fields where supported.

The workflow accounts for dependencies between collectors and destinations. Access information for installed services then appears in Access Center, keeping useful dashboards and endpoints within reach.

  • Metrics and dashboardsPrometheus, Alertmanager and Grafana form an installation unit with shared dependencies.
  • Logs, traces and profilesLoki, Tempo and Pyroscope address different signals; Alloy participates in collection and forwarding in the corresponding profiles.
  • Retention you can sizeFor Prometheus, review retention, scrape interval and persistent volume. Each component exposes fields applicable to its storage.
  • Explicit lifecycle actionsIn supported workflows, installation, updates, disabling while preserving data and removal are distinct actions with different impacts.

IN YOUR WORKFLOWStart with the metrics and dashboards your team uses. Add logs and traces with a deliberate decision about retention, collection and storage.

Explore observability configuration
Observability step with metrics, logs and tracing components and their configuration options.Actual application screenshot

Selecting a tool does not prove that an application is already sending telemetry. Results depend on collection, instrumentation, permissions and capacity; removal has boundaries for each stack unit.

08

MULTICLUSTER NAVIGATOR

Find the resource. Understand the context. Keep working.

Navigator brings cluster visibility and resource navigation together. Use filters, state and details to move from an overview to the object that needs attention while retaining the selected environment’s context.

Events, YAML, logs, shell and port-forward are close to the resource when the action is supported and authorized. Dockable panels let you keep inventory visible while investigating.

  • Fleet visibilityReview cluster identity, connectivity and available information before opening a specific environment.
  • Inventory with detailExplore resources, refine your selection and inspect events and information for the chosen object.
  • Tools in contextOpen YAML, logs and operational access without rediscovering the originating cluster and resource.
  • Capacity and usage stay distinctThe overview distinguishes capacity, requests and observed usage; missing collection remains visibly missing data.

IN YOUR WORKFLOWWhen a workload has a problem, start in the correct cluster, find the resource, read events and open logs while retaining the investigation’s context.

Explore Navigator
KubeRocks Navigator showing resource inventory and selected cluster details.Actual application screenshot
KubeRocks Kubernetes health with Pod, node, PVC and workload readiness and signals that need attention.Actual application screenshot
Observed cluster history in KubeRocks with CPU, memory, storage, Pods, nodes and visible collection gaps.Actual application screenshot

Actions depend on the resource and permissions. Usage metrics require real collection; available inventory does not grant unrestricted shell, editing or cluster operations.

09

CREATION, YAML AND OPERATIONS

From a missing resource to a change you can review.

Create Kubernetes resources through the Navigator’s guided forms. The creation plan organizes the object, destination and configuration: for a Deployment, this includes image, replicas, ports, variables, volumes, probes and resources where selected.

For existing objects, the YAML editor keeps the resource and its context close. Server validation, a change preview and edit history help you understand the effect before applying an update.

  • Creation by resource typeThe creation catalog covers workloads, networking, configuration, storage and RBAC. Choose the cluster, namespace and type before filling in its specific form.
  • Review the changeInspect generated or edited YAML, check validation and compare differences before confirming the update.
  • Actions on the right resourceLogs, events, shell, restart, scaling and port-forward are available in compatible workflows. Selection preserves the destination cluster and object.
  • History and recoveryEligible changes have history and rollback; deletion uses confirmation and temporary backups of recoverable manifests, with a seven-day window.

IN YOUR WORKFLOWTo adjust an application, locate its Deployment, inspect events and logs, review the YAML and then apply the necessary change.

See the inventory behind these operations
Deployment creation plan in Navigator with image, replica, network, volume and configuration stages.Actual application screenshot

Cluster permissions and capabilities still apply. Manifest rollback and object recovery do not restore database contents or deleted volumes; keep independent backups.

10

CAPACITY PLANNING

See what your choices require in CPU, memory and storage.

Every added tool needs resources. Resources brings discovered worker capacity together with the platform’s estimated requests so you can inspect the impact of your choices before execution.

Overview, comparison, ranking and distribution answer different questions: what requests the most, which group accounts for the demand and where configuration exceeds known capacity.

  • CPU and memory by groupCompare planning for Kubernetes, observability, security and platform tools.
  • Ranking and distributionIdentify the largest requests and explore their composition by stack or component.
  • Storage in the same reviewCompare requested volumes with estimated usable Rook-Ceph capacity.
  • States that explain the issueUnknown capacity, partial estimates and exceeded limits remain distinct in the presentation.

IN YOUR WORKFLOWIf the platform does not fit the available workers, identify the largest components and revise the selection or infrastructure before Apply.

Inspect planned capacity
KubeRocks Resources comparing planned CPU, memory and storage.Actual application screenshot

Requests and planning baselines estimate resource reservations. They are not usage measurements or a guarantee of capacity for your application workload.

11

APPLICATION ACCESS AND ACCESS CENTER

From the installed service to the address you need.

Application access organizes Gateways, domains, listeners, certificates and application routes. The workflow relates the published hostname to its TLS boundary and keeps infrastructure and application access explicitly separated.

Access Center collects the cluster’s operational access sheet: endpoints, dashboards, access information, useful commands and DNS guidance. Reaching a service no longer depends on finding the right line in an old log.

  • Routes in contextConfigure application access with the Gateway, listener and certificate coverage in view.
  • Dashboards within reachFind URLs for installed services such as Grafana, Prometheus, Hubble and Rook-Ceph when access has been configured.
  • Copyable commandsUse the DNS information and access or diagnostic commands appropriate to the service.
  • Credential metadataThe report distinguishes references and access information from secrets held locally or by the service itself.

IN YOUR WORKFLOWAfter installing the platform, open the cluster access sheet, locate the required dashboard and review its domain and access instructions together.

See how to reach your services
KubeRocks Access Center with search and cluster access and operation history.Actual application screenshot

A recorded URL does not make a service public by itself. Network reachability, DNS, certificate and authentication must match the environment’s configuration.

12

CANARY AND ADVANCED ROUTES

Try a new version with a share of the traffic.

Application access connects a route to existing services and lets you define a delivery strategy. The capture shows a real example: 90% of configured traffic to the stable version and 10% to a test version.

Expand the options to configure HTTP rules, traffic distribution, mirroring and promotion. The preview shows the affected manifests so that changing exposure remains a decision you can review.

  • Explicit destinations and weightsDefine the stable version and up to seven test versions, with services, ports and weights. The form checks the distribution before application.
  • HTTP and gRPCRoutes specify protocol, hostname, namespace, path and destination. Advanced capabilities depend on the Gateway and provider.
  • Failure controlsWith Istio, review the circuit breaker, limits and outlier detection options available for the route.
  • Promotion and portabilitySupported workflows include promotion, rollback, and access configuration import and export, with destination validation.

IN YOUR WORKFLOWValidate a new application version with a fraction of requests, follow its health through your observability signals and decide when to promote it.

Inspect the route configuration
KubeRocks canary strategy with 90% assigned to the stable service and 10% to a test version.Actual application screenshot

Configured weights describe routing intent, not measured traffic. Distribution depends on the provider and requests; promotion does not fix application errors.

13

IDENTITY, POLICY AND SECURITY

Choose the right control for each responsibility.

Certificates, identity, admission policies, secrets and threat detection solve different problems. The Security, Identity & Policy step groups these tools by purpose, with their own settings instead of a generic promise of a “secure cluster”.

Cert-manager supports certificate management; Keycloak handles identity; Vault addresses secrets storage; Kyverno supports policies; Falco and analysis tools contribute the available security signals and checks.

  • Identity with explicit dependenciesIn Keycloak, configure the profile, replicas, hostname and database for the scenario. Local and external databases have different responsibilities.
  • Secrets and persistenceVault has replica, storage and HA settings. Initialization, unseal and access policy remain operational decisions.
  • Policies and detectionInspect admission, runtime and configuration analysis tools. Installing a controller starts the work of defining the rules your team needs.
  • Access scoped to a namespaceThe access manager also supports issuing kubeconfig with an owner, namespace, permission profile and explicit lifetime. View, workload editing and namespace administration have different scopes.

IN YOUR WORKFLOWWhen preparing your team’s platform, separate user identity, certificates, admission policy and secrets management before choosing components.

Explore security choices
Security, Identity & Policy groups in the KubeRocks configurator showing cluster security tools.Actual application screenshot

A tool’s presence does not certify compliance or prove complete integration. Profiles, policies, administration credentials and recovery need configuration and validation in your environment.

14

LOCAL CREDENTIALS AND SECURITY

Connect your infrastructure without handing your keys to a web page.

The desktop application keeps infrastructure credentials encrypted on the device. Credential management separates connection details, authentication, selection of the credential in use and editing of the secret, making each change explicit.

The central service organizes configuration, references and sanitized operational data. Inside the cluster, identity, policy and security choices have their own configuration: protecting a local key and configuring the platform are separate parts of the same responsibility.

  • A vault on your deviceThe desktop main process uses operating system secure storage to protect saved secrets.
  • Explicit editingThe credential list keeps selection and search separate from the form; the secret stays locked until an edit action.
  • References in the central serviceConfigurations use credential references, while authentication material is resolved in the authorized local workflow.
  • Cluster controlsSecurity, Identity & Policy organizes tools such as Kyverno, Vault and Keycloak with requirements specific to each profile.

IN YOUR WORKFLOWSave a credential in the desktop, select it for the hosts and reuse that reference in configuration without copying a private key into the marketing website.

Understand the credential workflow
Local credential editor with name, SSH username, port and protected saved password.Actual application screenshot

The product uses connected services and is not entirely offline. Connections may require restricted local temporary material, and protection also depends on the security of your device.

COMPONENT CATALOG

Choose components by the problem they solve.

Explore the 46 options in the configurator catalog. Open a category to connect each tool with its role in the platform.

Storage1
Rook-Ceph
Ceph-backed persistent storage for block, file and object workloads.
Ingress / Gateway2
Cilium
CNI, eBPF datapath, Service LoadBalancer, NetworkPolicy and Hubble visibility.
Istio
Service mesh for mTLS, retries, timeouts, circuit breaking and fault injection.
Platform Engineering18
Argo CD
GitOps continuous delivery.
Tekton
Cloud-native CI/CD pipeline components.
Jenkins
Controller-based automation server with dynamic agents.
GitLab CE
Self-hosted GitLab Community Edition platform.
GitLab Runner
Runner integration for GitLab CI jobs.
Harbor
Container registry and artifact security platform.
Nexus Repository
Stateful artifact repository manager.
KEDA
Event-driven workload autoscaling.
Velero
Backup and restore workflows.
SonarQube Community
Code quality and static analysis platform.
PostgreSQL
Open-source relational database with optional replication.
MySQL
Open-source relational database with primary/replica mode.
MariaDB
Open-source relational database compatible with MySQL workloads.
MongoDB Community
Open-source document database with replica set mode.
Redis
Open-source in-memory database with Redis Cluster mode.
Kafka
Distributed event streaming platform for durable topics.
RabbitMQ
AMQP message broker with management UI and clustering.
NATS
Lightweight messaging and JetStream event persistence.
Observability17
Prometheus
Metrics and time-series collection.
Grafana
Dashboards for cluster and workload signals.
Alertmanager
Alert routing and notification grouping.
Loki
Log aggregation for Kubernetes workloads.
OpenTelemetry
Trace-only collector when Grafana Alloy is unavailable.
Alloy
Grafana telemetry collector pipeline.
Beyla
Automatic application instrumentation.
Tempo
Distributed tracing storage.
Pyroscope
Continuous profiling backend.
Faro
Frontend observability integration.
SkyWalking
APM and distributed tracing suite.
Jaeger
Distributed tracing backend.
Elasticsearch
Search and storage engine for log analytics.
Kibana
Elastic dashboards and log exploration UI.
Filebeat
Lightweight log forwarder.
OneUptime
Open-source observability, status page and incident platform.
Grafana OnCall
On-call scheduling and escalation; a catalog item whose OSS project status needs review before production.
Security, Identity & Policy8
Kyverno
Policy and admission control for Kubernetes resources.
Cert-Manager
Certificate lifecycle automation for Gateway HTTPS routes.
External Secrets Operator
Synchronizes external secret stores into Kubernetes.
Vault
Secrets management and encryption services.
Trivy Operator
Kubernetes vulnerability scanning operator.
Falco
Runtime threat detection for Kubernetes workloads.
Wazuh
SIEM and XDR security monitoring.
Keycloak
Identity and access management.

This is the configuration catalog. Installation availability, versions, dependencies, profiles and lifecycle vary by component and application distribution. Selection does not confirm installation or replace vendor documentation.

AI WITH OPERATIONAL CONTEXT

A useful analysis starts with the right resource.

Review helps assess a resource, including one that appears healthy. Troubleshoot starts from observed symptoms to suggest a next step. Analysis uses the selection’s context and bounded evidence, with results tied to what could actually be verified.

Choose enabled providers and keep custom prompts for resource types. Tokens remain encrypted locally; analysis uses the permitted evidence for the selected provider.

Understand which data is shared
  1. Review

    A direct assessment, evidence-backed findings and prioritized improvements.

  2. Troubleshoot

    The problem and next step come first, with proposed commands when evidence supports them.

  3. Custom prompts

    Instructions per resource type keep the analysis aligned with the work.

AI can transmit permitted evidence to an enabled provider and incur external charges. Corrective commands are suggestions for human review; analysis does not authorize automatic repairs.

FIND YOUR WORKFLOW

One workflow, different kinds of work.

Start with the task you need to accomplish. Each scenario leads to the relevant decisions and screens.

Developers and people learning cluster operations

Learn with a lab you understand

You want to build a small environment and understand how hosts, networking and components fit together.

Use the appropriate profile, work through checks and inspect the architecture. The proposed Free plan covers environments within all three limits; the Prod profile requires a larger topology.

Explore this workflow

DevOps and platform teams

Prepare a foundation for your team

Your team needs Kubernetes, persistence, software delivery and observability with decisions it can review.

Choose catalog components by need, check dependencies and capacity, and record how the services will be reached.

Explore this workflow

Operators of their own clusters

Operate several environments with context

You move between development, staging and production and need to locate the correct resource quickly.

Use Navigator to choose the environment, refine inventory and open details and tools while retaining context.

Explore this workflow

Engineers responsible for operations

Investigate a troubled workload

An application is not ready and you need to separate the symptom, evidence and next action.

Inspect the resource, its events and logs. When enabled and applicable, AI assistance helps structure the analysis while leaving the corrective decision to you.

Explore this workflow

Architects and infrastructure administrators

Review the plan before expanding the stack

You want to add services without overlooking existing CPU, memory and storage capacity.

Compare estimated requests, identify the largest components and revise workers, disks or selections before execution.

Explore this workflow

What you decide at each step.

The stepper contains eleven fixed stages. HAProxy / Load Balancer appears after Cluster when the profile requires it. Each stage prepares information used later, leading to review of the complete plan.

Explore every step

GROW WITH INTENTION

Start with the size of the environment you want to operate.

The proposed plans combine infrastructure capacity and users per organization. Compare nodes, vCPU and RAM across your clusters; do not use momentary consumption to estimate plan eligibility.

PROPOSED LAUNCH PRICING

Free

For getting started with your first environment.

US$ 0/month

Free within plan limits.

 

  • Up to 5 nodes
  • Up to 20 total vCPU
  • Up to 40 GB total RAM
  • 1 user

Guided configuration, Navigator and local vault.

Download coming soon

Team

For sharing operations with your team.

US$ 29/month

Or US$ 290/year, billed once annually.

Equivalent to 10 monthly payments; save 2 months.

  • Up to 50 nodes
  • Up to 200 total vCPU
  • Up to 400 GB total RAM
  • Up to 5 users

Guided configuration, Navigator and local vault.

Download coming soon

Free: up to 5 nodes, 20 vCPU and 40 GB RAM, within all three limits simultaneously. It suits small environments. The Prod profile requires at least 3 control planes + 3 workers and already exceeds Free’s node limit.

Prices in US dollars (USD). Limits are aggregated per organization; all three infrastructure limits apply simultaneously in this proposal. Servers, cloud costs, domains and third-party licenses are not included. Currency conversion and applicable taxes depend on final contracting. Subject to confirmation before launch; no contracted support SLA.

Compare plans and limits

FREQUENTLY ASKED QUESTIONS

Before you start.

Does KubeRocks create the machines or host my Kubernetes cluster?

You supply hosts in your provider, data center or lab. KubeRocks organizes configuration, checks prerequisites and runs the installation and operational workflows available for that environment.

Machine, networking, disk, DNS and external-service costs and responsibilities remain yours. The proposed subscription covers software, not managed infrastructure.

What do I need to prepare before starting?

The current desktop workflow targets Windows and uses local Docker for execution. Hosts need connectivity, credentials and permissions compatible with installation.

Access & Readiness checks system requirements, access, CPU, memory, disk and networking. The operating system must be in the supported matrix; a host reachable through SSH may still be unsuitable for the cluster.

Can I build the production topology on the Free plan?

Not within the proposed limits. Free allows up to 5 nodes, 20 vCPU and 40 GB RAM simultaneously across the organization. The Prod profile requires at least 3 control planes and 3 workers: six Kubernetes nodes, plus two HAProxy hosts and a VIP.

A paid plan with enough capacity can meet that commercial requirement, but it does not change technical prerequisites or guarantee application availability.

Do I have to complete every stage and install every tool?

Work through the relevant stepper decisions and select components for your scenario. The workflow contains 11 fixed stages; HAProxy / Load Balancer appears when the profile requires it.

Optional components do not need to be enabled together. Some choices introduce storage, collection or capacity dependencies that must be met before execution.

Do the checks guarantee that installation will never fail?

Checks look for known blockers before installation and verify Kubernetes conditions afterwards. Mandatory failures prevent progress, and results help locate the problem.

Connectivity, image availability, host state and application configuration still influence the outcome. There is no zero-failure guarantee or fixed completion time for every environment.

Are my SSH keys and passwords stored on the website?

Infrastructure credentials stay encrypted on the device through the desktop application. The central service works with references and sanitized operational data without needing to store secrets from the local vault.

Authorized connections use authentication material and may require restricted local temporary files. Protect the operating system session and the device holding those credentials.

Does that mean the application works completely offline?

No. Authentication, central services, synchronization and component downloads can require connectivity, in addition to connections to your hosts and clusters.

Local credentials describe where secrets are protected; they do not mean that every function and every piece of data remains disconnected.

What happens to disks, and how do I prepare backups?

The current Rook-Ceph workflow requires eligible disks on at least three workers. Check device, capacity and state: initialization can erase selected disks, with explicit confirmation when existing data or signatures are present.

Keep independent backups. Velero needs a suitable destination, bucket, credentials and policy; preparing a controller or storage does not prove recovery. Validate a restore test for your scenario.

Does Resources show my cluster’s actual usage?

The planning view compares discovered capacity with estimated component requests. These figures help size the platform before execution and identify excess demand.

Observed usage belongs to available cluster telemetry. In Navigator, capacity, requests and usage metrics are distinct concepts; missing collection must not be read as zero usage.

Is every catalog component highly available?

Each component has a profile and its own prerequisites. HA Vault uses Raft and persistence; Keycloak can use an external database, while its local PostgreSQL remains a single replica. Jenkins, Nexus and SonarQube Community have single-application profiles; GitLab CE and Harbor also have scaling limits in the offered profile.

Review component configuration and documentation before choosing a production architecture. Selection, confirmed installation and recovery capability are different states.

Can I add or remove tools after installation?

Lifecycle workflows exist for supported components, including the observability stack. Dependencies and volume policy are part of the decision; disabling while preserving data and uninstalling with removal are different actions.

Availability varies by component. A catalog selection or saved configuration does not confirm that the runtime can install or remove that item in any cluster.

How do I reach Grafana and applications afterwards?

Access Center collects endpoints, URLs, metadata and useful commands for installed services. Application access lets you work with Gateways, listeners, domains, certificates and application routes.

Reaching a destination requires the correct network, DNS or hosts entries, certificate trust and authentication. An access record does not automatically publish an application to the internet.

Does AI assistance receive my data or change the cluster?

Enabled providers can receive permitted analysis evidence; tokens remain encrypted locally. Analysis uses allowed fields and diagnostic signals; raw logs and event messages stay on the device during collection.

Review and Troubleshoot present assessments and suggestions. Corrective commands require your judgment and do not constitute automatic repair. The provider may charge for usage.

Can I download the application or subscribe now?

Downloads and subscriptions are not yet available in this preview. Plans describe the launch proposal, with USD prices and external costs presented separately.

You can explore the screens, compare limits and evaluate requirements now. The installer and subscriptions will become available when the product launches.

KubeRocks Desktop

Understand your next cluster before the first Apply.

Explore configuration, inspect the platform and see how operations continue in Navigator. KubeRocks is being prepared to bring this workflow to your desktop.

Return to the product tour

This is an evaluation preview. The installer and subscriptions will become available only at launch.

We may use Google Analytics to understand website visits. It stays disabled until you allow it. You can change your choice at any time.

Privacy