Self-host Umami on redu

Umami is a modern, privacy-focused web analytics platform, an open-source alternative to Google Analytics that does not use cookies and keeps your visitor data on infrastructure you control. People self-host it to own their analytics data outright. On redu, your AI agent runs Umami for you on a real VM in the EU, so you set nothing up by hand.

License: Umami 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 your own Umami instance on your own redu infrastructure.

Deploy it with your agent

Connect the redu MCP. This works with any MCP client; Claude Code is shown as the example:


claude mcp add --transport http redu-cloud https://mcp.redu.cloud/mcp

Point your agent at Umami’s official Docker setup and tell it:


Deploy Umami on redu using its official docker-compose, and expose the web UI.

Umami ships an official docker-compose.yml (a Next.js app plus a PostgreSQL database), so your agent uses deploy_compose to run the whole stack on one EU VM with podman-compose up -d --build and serve the web UI at https://<name>.redu.cloud. Your agent discovers the exposed web port at deploy time. redu never rewrites your compose file.

Database

Umami requires a PostgreSQL database. It does not need Redis, MySQL, or any other external datastore. You have two clean options:

Keep the bundled db service (default). Umami’s official compose file already includes a PostgreSQL service, so deploy_compose runs it alongside the app on the same VM with no extra configuration.
Use a redu managed Postgres. Have your agent provision a separate managed database and point Umami at it:
```
Deploy Umami on redu with a managed Postgres database.
```
Your agent provisions a redu managed Postgres VM and appends the connection env to the compose project’s .env. DATABASE_* aliases are injected alongside the standard Postgres variables, so the connection string is available without manual mapping.

Access it

Once the deploy finishes, Umami comes up at https://<name>.redu.cloud with TLS already handled by a wildcard certificate, so there is no per-app certificate setup. On first run, Umami creates an initial admin login; sign in and change the default credentials before you add your first website. Your agent can retrieve the live URL for you.

Keep it running

Deploys are self-healing: redu recreates and retries the stack until Umami 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 a keypair) to update Umami, adjust its configuration, or fix an issue in place, and commit any fixes back to the repo with a GitHub token.

What’s next

Stuck? support@redu.cloud