App
uptimepage
Repo / project
https://github.com/uptimepage/uptimepage
Docs
https://uptimepage.dev/docs
What does it do?
Uptime monitoring with a public status page built in. Checks HTTP, TCP, ICMP ping, DNS, TLS certificate and domain expiry, plus inbound cron heartbeats, and alerts to Slack, email, PagerDuty, Discord, Telegram, ntfy, Pushover and others. Everything is drivable by REST API or Terraform as well as by click. AGPL-3.0, one self-contained Rust binary.
Why would you like it on malmo?
Disclosure first: I am the author. Opening this because we talked on X and you asked me to put it here.
The home server case is the one it fits best. Someone running malmo already has services they care about, and this tells them when those are down without paying a SaaS or trusting one to watch its own host. The status page half is useful for anyone sharing a service with family or a small team.
Below is everything I think you need to judge the fit and write the manifest. Happy to answer anything that is missing.
First run needs no shell
Creating the first account used to need a terminal, which does not fit "every privileged operation has a UI path". That is fixed as of today's image. Set these and the first boot creates the owner plus their org and logs a single-use sign-in link:
UPTIMEPAGE_BOOTSTRAP__EMAIL=owner@example.com
UPTIMEPAGE_BOOTSTRAP__ORG_NAME=Home Lab
Once the instance is claimed the setting goes inert, so a value left behind in a manifest cannot re-seed or break a later restart. Note the double underscore for nesting. Docs: https://uptimepage.dev/docs/configuration#first-run-owner
Image and ports
ghcr.io/uptimepage/uptimepage:latest, published linux/amd64, public, no auth needed to pull. Pin a release tag instead of latest if you prefer.
Port 8080 is the dashboard and REST API, so that is your main_port. Port 9090 is Prometheus metrics, keep it internal. It only makes outbound checks and nothing needs to reach in, so a closed-by-default appliance profile works. Needs permissions.internet: true.
Required env
UPTIMEPAGE_AUTH__FINGERPRINT_SALT=<openssl rand -base64 32>
UPTIMEPAGE_AUTH__PUBLIC_BASE_URL=http://<appliance-host>:8080
UPTIMEPAGE_AUTH__SESSION__COOKIE_SECURE=false
The salt is load-bearing and the app refuses to boot without it, so generate it once per install and keep it. PUBLIC_BASE_URL is what the seeded sign-in link is built from, so if it stays localhost the link will not work from another machine on the LAN. COOKIE_SECURE=false is only needed on plain HTTP; behind TLS drop it and keep the secure default.
Storage points at UPTIMEPAGE_STORAGE__POSTGRES__URL and UPTIMEPAGE_STORAGE__CLICKHOUSE__URL / __USER / __PASSWORD. Both databases run their own migrations at startup, so there is no init step to script.
The caveat: ClickHouse
You provision Postgres natively but not ClickHouse, so it has to ride inside the app's own compose as an app-owned service. That is more weight than the average catalog app on an old laptop, and I would rather say so up front than have you find it on the hardware.
It stores every check result and serves the uptime and latency rollups. The storage layer sits behind a trait and an in-memory implementation already exists in the tree, so a Postgres-only backend is a port rather than a rewrite. I have not built it because nobody has hit the wall yet. If that weight is what keeps uptimepage out of the catalog, say so and I will move it up the list.
docker-compose.yml in the repo root is the reference stack (Postgres 18 + ClickHouse 26.3 + the app) if it helps as a starting point. It publishes database ports and runs without auth in front, so treat it as a shape to copy, not to ship.
Before submitting
App
uptimepage
Repo / project
https://github.com/uptimepage/uptimepage
Docs
https://uptimepage.dev/docs
What does it do?
Uptime monitoring with a public status page built in. Checks HTTP, TCP, ICMP ping, DNS, TLS certificate and domain expiry, plus inbound cron heartbeats, and alerts to Slack, email, PagerDuty, Discord, Telegram, ntfy, Pushover and others. Everything is drivable by REST API or Terraform as well as by click. AGPL-3.0, one self-contained Rust binary.
Why would you like it on malmo?
Disclosure first: I am the author. Opening this because we talked on X and you asked me to put it here.
The home server case is the one it fits best. Someone running malmo already has services they care about, and this tells them when those are down without paying a SaaS or trusting one to watch its own host. The status page half is useful for anyone sharing a service with family or a small team.
Below is everything I think you need to judge the fit and write the manifest. Happy to answer anything that is missing.
First run needs no shell
Creating the first account used to need a terminal, which does not fit "every privileged operation has a UI path". That is fixed as of today's image. Set these and the first boot creates the owner plus their org and logs a single-use sign-in link:
Once the instance is claimed the setting goes inert, so a value left behind in a manifest cannot re-seed or break a later restart. Note the double underscore for nesting. Docs: https://uptimepage.dev/docs/configuration#first-run-owner
Image and ports
ghcr.io/uptimepage/uptimepage:latest, publishedlinux/amd64, public, no auth needed to pull. Pin a release tag instead oflatestif you prefer.Port 8080 is the dashboard and REST API, so that is your
main_port. Port 9090 is Prometheus metrics, keep it internal. It only makes outbound checks and nothing needs to reach in, so a closed-by-default appliance profile works. Needspermissions.internet: true.Required env
The salt is load-bearing and the app refuses to boot without it, so generate it once per install and keep it.
PUBLIC_BASE_URLis what the seeded sign-in link is built from, so if it stayslocalhostthe link will not work from another machine on the LAN.COOKIE_SECURE=falseis only needed on plain HTTP; behind TLS drop it and keep the secure default.Storage points at
UPTIMEPAGE_STORAGE__POSTGRES__URLandUPTIMEPAGE_STORAGE__CLICKHOUSE__URL/__USER/__PASSWORD. Both databases run their own migrations at startup, so there is no init step to script.The caveat: ClickHouse
You provision Postgres natively but not ClickHouse, so it has to ride inside the app's own compose as an app-owned service. That is more weight than the average catalog app on an old laptop, and I would rather say so up front than have you find it on the hardware.
It stores every check result and serves the uptime and latency rollups. The storage layer sits behind a trait and an in-memory implementation already exists in the tree, so a Postgres-only backend is a port rather than a rewrite. I have not built it because nobody has hit the wall yet. If that weight is what keeps uptimepage out of the catalog, say so and I will move it up the list.
docker-compose.ymlin the repo root is the reference stack (Postgres 18 + ClickHouse 26.3 + the app) if it helps as a starting point. It publishes database ports and runs without auth in front, so treat it as a shape to copy, not to ship.Before submitting