Install and manage applications with Kubchi

Kubchi is the Kubit service for installing and managing applications and databases on Kubernetes. In the usual workflow, you select a ready-to-install pack from a repository, complete its form, and confirm the installation.

Installing a ready-to-use pack does not require building a Helm chart or writing a YAML manifest. The panel shows the available versions, configuration, and documentation for each pack. After installation, you can use the same panel to inspect the application and its resources.

A ready-to-install pack is a prepared definition for installing an application or database. Its chart, versions, default values, and configuration form are already defined. Depending on the repositories available to the cluster, the list may include applications such as Redis, PostgreSQL, Grafana, or n8n.

Pack repositories determine what is available on each cluster. They are represented by ClusterPackRepository or PackRepository: the first is cluster-scoped, while the second belongs to a namespace. Open Install Pack for the current list. The ready-to-install packs section also documents commonly available options.

1. Select a ready-to-install pack from a repository.
2. Choose the pack name, namespace, version, and pack-specific settings in the form.
3. Review the configuration preview and chart documentation, then confirm the installation.
4. Kubchi installs the pack on the cluster and reports the state of its resources in the panel.
5. After installation, manage its configuration, version, logs, events, resource usage, and integrations.

Start with installing your first ready-to-use pack.

Each pack can provide its own form and documentation. After installation, the pack page shows the chart version, namespace, workload status, and outputs defined by the chart, such as the application URL or connection details.

From the same page, you can change the configuration, review a newer version, or run an available management operation. The options depend on the pack and the permissions assigned to your role.

Use Workloads, Logs, Terminal, Events, and Alerts to inspect the running application. If an installation does not complete, check the pack events first and then read the pod logs.

Monitoring shows CPU and memory usage for a project or an individual pack. Metrics appear only when monitoring is enabled on the cluster and your role has permission to view them.

You can change a pack through its form or configuration editor. A GitOps connection keeps the pack manifest in Git. The CI/CD integration passes an image tag produced by your pipeline to the pack.

Use Environment Variables for shared values and Docker Registry Credentials for pulling private images. Do not store sensitive data directly in general configuration; encrypt it with Vault.

If the chart supports web access, register the domain and TLS certificate in the project, then select the domain and certificate Secret in the pack configuration. The pack form and documentation define the exact field names.

To use Kubchi, you need a Kubit account, membership in an organization, and access to a project. The project must be connected to a Kubernetes cluster. If you do not have a cluster yet, create one through Managed Kubernetes.

Your role determines which pages and operations are available. If you cannot see the project, pack repositories, or a management option, ask an organization administrator to check the project-to-cluster connection and your role permissions.

Kubchi creates a Kubernetes Pack resource for each installation. Pack Operator reads that resource and applies the Helm chart to the cluster. When you work with ready-to-install packs, you normally do not need to manage this resource directly.

Edit the YAML manifest when the chart has no form, the setting you need is not exposed by the form, or you want to manage the Pack with technical tooling. The Pack reference documents the manifest structure, operator behavior, and kubit-cli.