A standup bot on your own servers, in your own region

git clone https://github.com/morgenruf/morgenruf.git
cd morgenruf/app && cp .env.example .env   # add your Slack app values
docker compose up -d

Why teams self-host a standup bot

Self-hosting decides one thing before anything else: which machine, in which country, holds the answers. Everything else on this page follows from that. Three reasons come up, in this order:

• The answers are sensitive. A standup is a daily log of what is broken, what is late and who is stuck. Plenty of companies are fine with that in a vendor's cloud. Regulated ones are not, and it is not a preference they can be argued out of. Here the answers sit in whatever Postgres you point it at, in whatever region that database is in.
• The bill grows with the team. Per-seat pricing means the cost of three questions a morning rises every time you hire.
• They already run things. If you have a cluster and a Postgres, adding one more small service is an afternoon.

What running it actually involves

• One container. A Python process. Not a queue, a worker pool and a cache.
• One database. Postgres 13 or newer. Migrations run themselves on start.
• An HTTPS URL. Slack posts events to it. A Cloudflare tunnel is enough and needs no open port.
• Upgrades. Pull the image and restart, or helm upgrade.
• Backups. pg_dump. There is no other state.

What leaves your network

A self-hosted install talks to Slack only, plus Zoom, email (Resend), an AI provider or PostHog analytics if the operator turns those on. By default that means slack.com: the app calls it to read channel membership, open DMs and post the summary, and Slack calls your HTTPS URL back with events. Answers, blockers, participation, coffee chat pairings and kudos are written to your Postgres. There is no licence check. Each optional service stays silent until you configure it: Zoom when someone links an account for coffee chats, Resend when you set up digest email, an AI provider when you add a key for summaries, and PostHog when you set a PostHog key. You can watch that on the egress rules, and since it is MIT licensed and readable end to end you can check the claim rather than take it.

Which makes the residency answer short. The data lives in the region your database lives in, under the retention your backups already have, and a deletion or subject access request is a query against a schema you own.

What it costs

A small VPS and a managed Postgres, or nothing extra if you already run both. There is no seat component at any size, which is the whole economic argument: the difference between hosted and self-hosted grows with your headcount, not with your usage. What the hosted standup bots charge per person is on the comparison pages, if you want to do the arithmetic for your own team.

Where it runs

• Kubernetes with the published Helm chart, ingress, HTTPRoute or a tunnel
• Docker Compose on a VPS, a homelab box or a spare Mac mini
• Anywhere else a container and a Postgres can live

The same image and the same database either way. Every way of running it is written up step by step, and the choice is mostly about what your team already operates.

The dashboard runs on your own domain, behind your own auth.

The part people underestimate

Not the install. The Slack app: scopes, a redirect URL, and the fact that a workspace which installed before a feature existed has not granted that feature's scopes. That page exists because it is where setups actually stall. It helps to read what the bot does inside Slack first, because the scopes follow from it and half of them are for features you may not switch on. If you would rather hand the whole job over, CloudDrove does paid setup and hosting on your own infrastructure.