Kubernetes (Helm)
rapidrest generate k8s
This adds a Helm chart under helm/. Like generate docker, it's idempotent: regenerate it with --force any time your project's datastores change (see CLI Reference → Add-ons).
What's in the chart
MongoDB and Redis are optional dependencies, pulled in as Bitnami subcharts only if your project actually uses them, each gated behind a condition in Chart.yaml (mongodb.create / redis.create) so they can be swapped out for externally-managed databases in values.yaml without touching the chart itself.
The templates are organized by the order Kubernetes resources naturally depend on each other:
helm/templates/
├── 0_config/ # ConfigMap + Secrets: becomes your app's env vars
├── 1_deployments/ # the server Deployment
├── 2_services/ # the Service exposing it inside the cluster
├── 3_gateways/ # Gateway + HTTPRoute exposing it outside the cluster
└── NOTES.txt # printed after `helm install` (see below)
Configuring values.yaml
The settings you'll actually touch:
| Key | What it controls |
|---|---|
host | The public hostname the service will be reachable at. |
environment | dev or production. In non-production environments the container also runs with --inspect enabled for remote debugging. |
auth.audience / auth.issuer / auth.expiresIn | JWT token settings, same as the auth config key described in Authentication. |
service.image.registry / repository / tag | Where to pull the container image from. |
service.replicas | How many pods to run. |
mongodb.create / redis.create | Whether to deploy the bundled Bitnami subchart, or connect to an existing external instance instead. |
auth.secret, cookies.secret, and sessions.secret default to Helm's randAlphaNum 32, a fresh random value generated at install time rather than a value you set. That's deliberate (see below).
Just like Docker Compose, every datastore ends up as a datastores__<name>__<key> environment variable on the pod, sourced from a generated ConfigMap/Secret pair rather than typed in by hand. These are the same nconf keys from Configuration, just populated by Kubernetes instead of Compose.
Installing
helm install my-api ./helm
Before your service starts serving traffic, init containers block startup until Redis and MongoDB (if either is bundled) respond to a basic connectivity probe. The pod won't report ready before its datastores are actually reachable.
Because auth.secret, the MongoDB admin password, and other credentials are randomly generated at install time rather than configured up front, helm install prints them to the terminal exactly once, via NOTES.txt. There's no way to recover them from the cluster afterward except by reading the underlying Secret resources directly. Write them down (or better, pull them into your own secret manager) before you close that terminal.
Routing
The chart uses the Kubernetes Gateway API (a Gateway + HTTPRoute), not a classic Ingress. Your cluster needs a Gateway API-compatible controller installed (the chart assumes an NGINX Gateway Fabric-style gatewayClassName: nginx). TLS termination and HSTS are both configurable via gateway.tls/gateway.hsts in values.yaml.
Trying it locally
If you don't already have a cluster to deploy to, helm/scripts/k3s_install.sh sets up a single-node k3s cluster with the prerequisites this chart expects (a Gateway API controller, the Bitnami Helm repo, and so on), a reasonable way to try a full Helm deployment on a single machine before deploying to a real cluster.