This will create a 1GB volume and only one machine. If you look at the source, I’ve disabled auto_stop_machines and made min_machines_running = 1 so the monitor is always up.
Hide your Uptime Kuma from the outside world
I’m not a fan of anyone snooping my self hosted things and since the major selling point of Uptime Kuma is alerting I’ve removed public IPs from mine using fly ips release [IP]. You could also change the fly launch command above to use --no-public-ips so they’re never allocated.
To access a hidden uptime kuma you can easily use fly proxy -a KUMA_APP_NAME 3333:3001 and go to http://localhost:3333. If you use an WireGuard app in you computer you could also directly go to http://app_name.internal:3001, that takes some work before you can do it but makes easier for future use.
I like the idea of using OSS tools for something like this. I’ve often decided against it because it’s generally a pain to deploy and keep it online but if the deployment process is so simple then it’s worth considering.
Thanks for sharing this! It made it super easy to get up and running.
My app has run out of RAM once or twice (using a free 256MB VM), so I’ve allocated 256MB swap by adding swap_size_mb = 256 at the top level of the fly.toml file. It hasn’t been needed again yet, but should help with occasional spikes. https://fly.io/docs/reference/configuration/#swap_size_mb-option
As another private/secure access method, Uptime Kuma has built-in support for cloudflared. I used that to set up a Cloudflare tunnel with access control provided by Google authentication. This provides easy, extra secure access to Uptime Kuma without a public IP.
I launched my app with the --no-public-ips arg and used your fly proxy tip to initially tunnel in to get cloudflared set up.
Just curious, how your config creates automatically a volume for uptime kuma? By just mentioning the mounts with double square brackets? Any references to the documentation are much appreciated. Thank you!