Production-Ready: Domains, Secrets & Autoscaling

Your hello Rapid is live and redeploys on every push. This tutorial takes it the rest of the way to production: a custom domain with automatic TLS, configuration and secrets injected as environment variables (including a private connection to a managed database), and scaling tuned for your traffic shape.

Each section shows both the dashboard and the danube rapids CLI — use whichever fits your workflow. We continue with the hello container and team slug acme.

1. Put your own domain in front

By default your container answers at https://hello-acme.danubedata.run. You can map up to 10 custom domains per container, each with a TLS certificate provisioned automatically via Let's Encrypt — no cert files, no renewals.

In the Rapid's Domains tab, click Add domain and enter api.example.com.
At your DNS provider, add the record Rapids shows you:
Type Name Value
CNAME api.example.com hello-acme.danubedata.run
Rapids validates the record and issues the certificate within a minute or two. Once it shows Active, https://api.example.com serves your container.

Type	Name	Value
CNAME	`api.example.com`	`hello-acme.danubedata.run`

For an apex/root domain (example.com) that can't take a CNAME, use an ALIAS, ANAME, or CNAME flattening to point at the same managed hostname. Do not pin the domain to an ingress IP. See Custom Domains for apex setup, migration, and verification details.

2. Configuration and secrets

Rapids injects configuration as environment variables. Set non-secret config and secrets (API keys, connection strings) the same way — values are stored encrypted and are never written to the GitOps repository in plain text.

Dashboard: the Rapid's Settings → Environment Variables card.

CLI (variables are merged with existing ones; changing them rolls a new revision):

Bash

danube rapids update hello \
  --env NODE_ENV=production \
  --env FEATURE_SIGNUPS=on

# remove one later:
danube rapids update hello --rm-env FEATURE_SIGNUPS

Talk to a managed database privately

If you run a DanubeData managed database or cache, your Rapid can reach it over internal cluster DNS — the traffic never leaves the cluster, so there's no public exposure and no egress charge. Inject the internal connection string as an env var:

Bash

danube rapids update hello \
  --env DATABASE_URL='postgres://app:••••@my-db.acme.svc.cluster.local:5432/app'

Read it in your app like any other env var (process.env.DATABASE_URL, os.environ[...], os.Getenv(...)). Find the internal hostname on your database's detail page.

Secrets are revision-scoped. A running revision keeps the values it started with; updating an env var rolls a new revision with the new values. Rotate a secret by updating the variable — the next revision picks it up.

3. Scaling

Rapids scales on request load. The defaults (scale-to-zero, scale up on demand) are good for most apps; tune these knobs when you have a specific need.

Setting	CLI flag	What it does
Min replicas	`--min-scale`	`0` = scale-to-zero (default). Set `1`+ to keep instances warm and avoid cold starts.
Max replicas	`--max-scale`	Ceiling on instances under load.
Scaling metric	`--scaling-metric`	`rps` (requests/sec) or `concurrency` (in-flight requests) per pod.
Target	`--scaling-target`	The per-pod value of the metric Rapids aims to hold before adding a pod.
Request timeout	`--timeout`	Max seconds for a single request (max `3600`).

Scale-to-zero vs. always-warm

Scale-to-zero (--min-scale 0) — you pay nothing while idle; the first request after idle pays a short cold start. Ideal for spiky or low-traffic services, internal tools, and webhooks.
Always-warm (--min-scale 1) — one instance stays running so every request is fast, at the cost of running 24/7. Use for latency-sensitive, steady-traffic APIs.

Bash

# Latency-sensitive API: always one warm instance, scale on concurrency, longer timeout
danube rapids update hello \
  --min-scale 1 \
  --max-scale 20 \
  --scaling-metric concurrency \
  --scaling-target 50 \
  --timeout 120

Picking a resource profile

Start on the Free profile (it includes the monthly free tier) and move up to a paid profile or pay-per-use when you need more vCPU/memory per instance. Profiles and rates are on the pricing page.

Bash

danube rapids update hello --profile small

4. A quick production checklist

Listen on $PORT and return 200 on a health path (e.g. /healthz) — Rapids only sends traffic to a revision once it's ready.
Log JSON to stdout/stderr — logs are captured per revision and searchable in the dashboard. (See Invoking Containers.)
Pin immutable image tags (commit SHA) so deploys and rollbacks are precise.
Keep the container stateless — anything that must survive a scale-to-zero belongs in a managed database, cache, or object storage bucket, not the local filesystem.
Lock down access if it isn't a public API — see Authentication.

What's next

Troubleshooting CR + Rapids — diagnose ImagePullBackOff, cold starts, and stuck deploys.
Serverless overview — the full reference for scaling, networking, and limits.

Questions? Contact support at support@danubedata.ro