Apps
Everything you deploy lives in an environment—as a container app or a Helm app. This page explains both in depth: what they are, what you can configure, and how you run, pause, and observe them from the dashboard. For how to create and manage environments themselves, see Environments.
Two types of apps
- Container apps — An app you deploy from a container image (e.g. your API, frontend, worker). You set image, replicas, env vars, resources, and optional autoscaling or sidecars. Kaja deploys it into the environment you chose and keeps it running (or paused) there. Ideal for your own services.
- Helm apps — A single Helm chart deployment (e.g. PostgreSQL, Redis, nginx) inside an environment. You pick the chart, version, and values; Kaja installs and upgrades it. Ideal for off-the-shelf or internal charts.
Both appear in the same environment in the dashboard. Each app has a unique name within that environment—so you can't have a container app and a Helm app with the same name in the same env.
Container apps (in depth)
What is a container app?
A container app is a workload defined by a container image and the settings you give it: how many replicas, which env vars, how much CPU/memory, health checks (probes), and optional autoscaling or sidecar containers. You create it in an environment; Kaja deploys it to the right cluster and keeps status, logs, and metrics in one place.
Creating a container app
- Open a cluster and an environment in Kaja.
- Go to Container apps (or Apps) in that environment and create a new one.
- Set name (unique in the env), image (e.g.
myreg.io/myapp:v1), and replicas (or leave unset and use autoscaling). - Optionally add env vars, resource requests/limits, ports, liveness/readiness probes, autoscaling (min/max replicas, target CPU or memory), sidecars (e.g. log shipper, proxy), and image pull secrets if the image is private.
- Submit. Kaja deploys the app; you see status, pods, and can open Logs and Metrics.
You can link a build config to the app so that when a build finishes, the new image rolls out automatically (see CI/CD integration).
Key features
| Feature | What you get |
|---|---|
| Image & replicas | Run any container image; set replica count or let autoscaling manage it. |
| Env vars | Inject environment variables; reference secrets or config from the cluster. |
| Resources | Set CPU/memory requests and limits so the cluster can schedule and cap the app. |
| Probes | Liveness (is the process alive?), readiness (is it ready for traffic?), optional startup probe. Kaja uses these so the platform and cluster know when to send traffic and when to restart. |
| Autoscaling | Min/max replicas and a target (e.g. CPU %). The cluster scales the app based on load. |
| Sidecars | Add extra containers in the same pod (e.g. proxy, log shipper). Same lifecycle as the main app. |
| Pause | Scale to zero when you're not using the app—saves cost without deleting it. Resume when you need it. |
| Revisions | Each update creates a revision; you see history and can reason about rollbacks. |
| Logs & metrics | Live logs (all pods/containers) and per-pod CPU/memory in the dashboard. See Logs & metrics. |
| Builds | Attach a build config; trigger builds from the UI or pipeline and roll out new images. See CI/CD integration. |
Updating and rolling out
Change the image, replicas, env, or any other setting in the dashboard and save. Kaja rolls out the change. You see status and pod phases; if something fails, you can fix and redeploy from the same place. Revisions help you track what was deployed when.
Status, pods, and health
The app detail view shows overall status (e.g. Running, Pending, Failed), the list of pods (name, phase, ready state), and any events or messages that explain why a pod isn't ready. So you can debug without leaving Kaja.
Helm apps (in depth)
What is a Helm app?
A Helm app is one Helm chart deployment inside an environment. You choose the chart (e.g. from Bitnami, or your own repo), the version, and the values. Kaja installs and upgrades it on the cluster; you see status, pods, and services in the dashboard—and you can open Logs for the release's pods. For chart sources, values, and reapply, see also Helm.
Creating a Helm app
- Open a cluster and an environment in Kaja.
- Go to Helm apps (or Apps) in that environment and create a new one.
- Set name (unique in the env), chart (e.g.
nginx,bitnami/postgresql), and optionally repository URL and version. - Add values—key-value in the UI, or paste YAML. You can also pull values from config maps or secrets in the cluster so sensitive or shared config stays out of the UI.
- Optionally set release name and namespace if you need to override defaults.
- Submit. Kaja deploys the chart; you see status, pods, services, and Logs.
Key features
| Feature | What you get |
|---|---|
| Chart, repo, version | Pick any Helm chart; add the repo URL if needed; pin a version for repeatable deploys. |
| Values | Key-value or YAML; optional values from config maps or secrets. |
| Expose to other environments | Let other environments (that you allow) reach this app's services—e.g. a shared database. On the environment you set which envs can send traffic in; on the Helm app you turn on "expose to other environments" and optionally limit which envs can access it. |
| Updating | Change version or values and save; Kaja runs the equivalent of helm upgrade. |
| Reapply | Force a fresh apply if something went wrong or you want to resync. |
| Status, pods, logs | See release status, the pods the chart created, and open Logs for those pods—same experience as container apps. |
Exposing a Helm app to other environments
When one environment needs to use a service from another (e.g. a shared DB), you expose the Helm app. On the environment that hosts the app, you configure which other environments are allowed to send traffic in. On the Helm app, you enable "expose to other environments" and optionally restrict which envs can access it. The dashboard guides you through the options so you get shared services without opening everything up.
When to use container apps vs Helm apps
- Use a container app when you're deploying your own image (your API, frontend, worker) and want fine control over replicas, env vars, resources, probes, and autoscaling.
- Use a Helm app when you're deploying a chart (database, cache, or any chart-based service) and want to manage it with values and upgrades from the dashboard. Both can run in the same environment and can talk to each other (and to apps in other envs when you configure exposure).
Summary
| Type | What you get |
|---|---|
| Container app | Image-based workload. Replicas, env vars, resources, probes, autoscaling, sidecars, pause, revisions, logs, metrics, builds. |
| Helm app | Chart-based workload. Chart, version, values, expose to other envs, update, reapply, status, pods, logs. |
| Naming | One name per app per environment; container and Helm app names are unique within the same env. |
One place for all your apps—container and Helm. For environments (where apps run), see Environments. For chart details and values, see Helm. For logs and metrics, see Logs & metrics.
Next steps
- Environments — Where apps run; spin up and pause environments.
- Helm — Chart sources, values, and multi-chart workflow.
- Logs & metrics — View logs and metrics for your apps.
- CI/CD integration — Trigger builds and deploy from your pipeline.