Self-host Uptime Kuma on redu
Uptime Kuma is a self-hosted uptime monitor and status page: it pings your services, alerts you when they go down, and publishes a clean public status page. People self-host it to keep their monitoring (and the data about their own outages) under their own control. On redu, your agent runs it for you on real EU infrastructure, so you set up nothing.
License: Uptime Kuma is licensed under MIT. That is a permissive open source license, so you can self-host it freely. In this guide you are the operator, running Uptime Kuma on your own redu infrastructure.
Deploy it with your agent
Connect the redu MCP:
claude mcp add --transport http redu-cloud https://mcp.redu.cloud/mcpPoint your agent at Uptime Kuma’s official Docker setup and tell it:
Deploy Uptime Kuma on redu using its official docker-compose, and expose the web UI.Your agent uses deploy_compose to run the stack on one EU VM (via podman-compose up -d --build) and serves the Uptime Kuma web UI at https://<name>.redu.cloud. redu never rewrites your compose file: it starts the project as-is and exposes the single web service. Your agent passes the host port that the web UI is published on, discovered from the official compose setup at deploy time.
Database
Uptime Kuma ships with its own embedded datastore (SQLite, kept in a data volume), so it needs no external database. The default deploy just runs the official compose file and persists the data directory, which is the recommended setup for most people.
If you later want to run it against a separate managed database instead, redu can provision one and inject the connection env for you (DATABASE_* aliases are set alongside the standard variables so the app connects unmapped):
Provision a redu managed Postgres and point Uptime Kuma at it, appending the connection env to the compose project.For a straightforward status page, the built-in datastore is the simplest choice and nothing external is required.
Access it
Once the deploy finishes, Uptime Kuma comes up at https://<name>.redu.cloud with TLS already terminated (a wildcard cert), so there is no per-app certificate setup. On first visit, Uptime Kuma walks you through creating your admin account, then you can start adding monitors and building your status page.
Keep it running
Deploys are self-healing: redu recreates and retries the stack until Uptime Kuma actually runs, and get_deployment returns the build log if you want to see what happened. Day two, your agent can SSH into the VM (via get_ssh_command and your keypair) to update Uptime Kuma or fix it in place, and commit any config changes back to your repo with a GitHub token. redu is EU-hosted (a German data centre) and billed by the hour.
What’s next
Stuck? support@redu.cloud