What good is a status page, when its availability depends on the status of your own infrastructure? After all the status page (and your monitoring) should also be available when the rest of your infrastructure isn’t. Bonus points of the status page is even in a different region/with a different provider.

Fly.io is a hosting provider that generously provides a free tier (256MB Ram and 3GB of storage) which is large enough to run an instance of Uptime Kuma. Fly.io provides a free instance per organisation, which means that even if you’re already using it for other projects, you could still have your free monitoring through them.

To get started with your own Uptime Kuma instance install the Fly.io command line utility and then create a file called fly.toml in an empty directory with the following content:

# fly.toml file generated for mykuma

app = "mykuma"

kill_signal = "SIGINT"
kill_timeout = 5
processes = []

[build]
  image = "louislam/uptime-kuma:1"

[mounts]
source="kuma"
destination="/app/data"

[env]
  PORT = "8080"

[experimental]
  allowed_public_ports = []
  auto_rollback = true

[[services]]
  http_checks = []
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"
  script_checks = []

  [services.concurrency]
    hard_limit = 25
    soft_limit = 20
    type = "connections"

  [[services.ports]]
    force_https = true
    handlers = ["http"]
    port = 80

  [[services.ports]]
    handlers = ["tls", "http"]
    port = 443

  [[services.tcp_checks]]
    grace_period = "1s"
    interval = "15s"
    restart_limit = 0
    timeout = "2s"

The value of app needs to be unique and is basically the subdomain Uptime Kuma will be operating from, therefore this needs to be a unique name. In the above example the address for Uptime Kuma would be https://mykuma.fly.dev. By specifying image = "louislam/uptime-kuma:1" the instance will be deployed from the official Uptime Kuma container.

But before we can deploy our monitoring, we first need to create the data volume that we have already specified in the config above.

flyctl volumes create kuma

With the volume created a simple flyctl deploy will pull the container and deploy it on the fly.io infrastructure in the desired region.

In case you are not 100% sure about it, running flyctl info after the deployment has finished will show you the full url:

App
  Name     = mykuma
  Owner    = personal
  Version  = 0
  Status   = running
  Hostname = mykuma.fly.dev

Services
PROTOCOL PORTS
TCP      80 => 8080 [HTTP]
         443 => 8080 [TLS, HTTP]

IP Adresses
TYPE ADDRESS             REGION CREATED AT
v4   xxx.xxx.xxx.xxx               2h5m ago
v6   2a09:xxxx:1::1:xxxx        2h5m ago

The way Uptime Kuma is designed you have your own private monitoring dashboard (where you can create additional monitors and see the detailed status) at one domain (mykuma.fly.dev in the above example) and then can have a public “Status Page” on a completely separate domain.

To tell fly.io that is should respond to our own domain, one needs to create a “certificate” for it through flyctl. For my own setup I created a CNAME entry in the Cloudflare UI pointing to the “Hostname” fly.io gave for my deployed app and then executed the below command to register this domain entry with fly.io:

flyctl certs create status.mydomain.com

Once the domain is registered I can create a “New Status Page” within Uptime Kuma and assign status.mydomain.com in its settings as the “Domain Name[s]”.

And to round up your monitoring and status infrastructure a notification method (or maybe even more than just one) should be configured within Update Kuma to get notifications if important infrastructure stops responding.