Does the chart ship a database?

It can, but do not use it for anything you care about. Point externalDatabase.url at a managed Postgres so the data outlives the release.

How do migrations run?

An init container runs them before the app container starts, so a rollout is also a migration. When you pin an image tag, set it on both containers or the init container will run the old migrations against the new code.

Can it run without an ingress controller?

Yes. A Cloudflare tunnel in the same namespace works, and the chart has values for it. Nothing needs a public load balancer.

One. The scheduler lives in the process, and two replicas would both try to send the morning standup. Horizontal scaling is on the roadmap behind a shared lock; until then, one.

Install Morgenruf on Kubernetes with Helm

Install

helm repo add morgenruf https://charts.morgenruf.dev
helm repo update

helm upgrade --install morgenruf morgenruf/morgenruf \
  --namespace morgenruf --create-namespace \
  --set slack.clientId="YOUR_CLIENT_ID" \
  --set slack.clientSecret="YOUR_CLIENT_SECRET" \
  --set slack.signingSecret="YOUR_SIGNING_SECRET" \
  --set externalDatabase.url="postgresql://user:pass@host:5432/morgenruf" \
  --set flaskSecretKey="$(openssl rand -hex 32)" \
  --set app.url="https://standups.your-domain.com"

Use a real database. The chart can start one for you, which is fine for a look, but point externalDatabase.url at managed Postgres for anything you intend to keep. The data outliving the release is the point.

Exposing it

Slack has to reach the app over HTTPS. Three ways, in order of how common they are:

Ingress. Set ingress.enabled=true and your host. Standard annotations for cert-manager work.
Gateway API. An HTTPRoute is supported for clusters that have moved on from Ingress.
Cloudflare tunnel. No ingress controller, no public load balancer, no open port. Useful on a homelab cluster or anywhere the cluster is not internet-facing.

One replica, on purpose

The scheduler that fires standups, coffee chat rounds and the midnight kudos reset runs inside the app process. Two replicas would both wake up at nine and both send the morning message. Until that moves behind a shared lock, run one replica and let Kubernetes restart it; a restart mid-round resumes rather than repeating, because delivery is recorded per person as it happens.

Upgrades

helm repo update
helm upgrade morgenruf morgenruf/morgenruf --reuse-values

Migrations run in an init container before the new app container starts. If you pin an image tag rather than using the chart's, set it on both the app and the migrate container, or you will run the previous release's migrations against the new code.

What to watch

kubectl logs deploy/morgenruf -c migrate after a rollout, to see which migrations applied.
Scheduler started with N jobs in the app log. N should grow when you add a standup.
The status page endpoint, if you run your own monitoring.

Stuck? Ask in discussions, or have CloudDrove run the cluster for you.