Self-Host Umami Analytics with Dokploy: Cookie-Free Web Analytics on Your Own VPS in 10 Minutes

Umami is the analytics tool for people who want to know how their sites are doing without shipping visitor data to a third party: no cookies, no personal data, GDPR-friendly by design, and a clean dashboard with page views, referrers, devices, countries and custom events. It runs as a single Node.js container with a PostgreSQL database, and Dokploy ships it as a one-click template. This guide walks through the template as published in the Dokploy templates repository on 31 October 2026 (Umami 3.4.0 with PostgreSQL 15), the first-login change, adding the tracking script, and backups.

What the template deploys

The Compose file runs two services without published ports, so Traefik is the only way in:

• umami from ghcr.io/umami-software/umami:3.4.0, with DATABASE_URL pointing at the db service, DATABASE_TYPE: postgresql, an APP_SECRET, and a health check against /api/heartbeat; it waits for the database's health check before starting.
• db from postgres:15-alpine, with a named volume db-data on /var/lib/postgresql/data and a pg_isready health check.

The template variables generate the secrets for you (APP_SECRET as 64 random base64 characters, DB_PASSWORD as a 32-character password) and route your domain to the umami service on port 3000. Nothing to change before deploying; this is one of the cleanest templates in the catalogue.

Step 1: deploy

1. On a Dokploy server (Umami runs happily in the smallest MassiveGRID preset on the Dokploy hosting page, 2 vCPU and 4 GB for $9.58 a month, alongside other services), create or open a project and choose Create Service, Template, Umami.
2. Enter the domain, for example analytics.example.com, with its A record already pointing at the server.
3. Deploy. The database initialises, Umami runs its migrations and the health check turns green within a minute.

Umami idles at 100 to 150 MB of RAM and PostgreSQL at 50 to 200 MB; even a site with a million page views a month stays well within the Starter preset.

Step 2: first login, and the one thing you must change

Open https://analytics.example.com and sign in with Umami's default credentials, username admin and password umami. Change the password immediately under Settings, Profile; the default is public knowledge and the dashboard is on the internet. Then create a user for each team member, and consider putting Dokploy's rate-limit middleware on the login route.

Step 3: add your websites and the tracking script

Settings, Websites, Add website: name and domain. Umami gives you a one-line script to paste before </head> on every page:

<script defer src="https://analytics.example.com/script.js" data-website-id="your-website-id"></script>

Within a minute of a visit the dashboard shows the page view. Umami tracks without cookies, stores no IP addresses in a reversible form and does not need a consent banner under most interpretations of GDPR and the ePrivacy rules, though you remain responsible for your own privacy notice. Custom events are data-umami-event attributes on buttons and links, or umami.track() from JavaScript.

Step 4: ad blockers, several sites and teams

• Ad blockers block script.js by name on analytics hosts. Umami supports renaming the script through the TRACKER_SCRIPT_NAME environment variable (for example TRACKER_SCRIPT_NAME=stats, served as /stats.js); add it to the umami service environment and redeploy. A first-party subdomain such as metrics.yourdomain.com helps as well.
• Several websites live in one Umami instance; add each under Websites and give each its own script tag.
• Teams in Umami let you share dashboards with view-only members; create a team and add websites to it.
• Data retention is unlimited by default; the database grows roughly with page views. A busy year is typically a few gigabytes, which the Starter preset's 64 GB disk absorbs.

Step 5: backups and upgrades

Your analytics history is in the db-data volume. Add a Volume Backup on the Compose service for that named volume to an S3 destination on a daily schedule, or run a scheduled pg_dump -U umami umami inside the db container to a path the volume backup covers. To upgrade Umami, bump the image tag in the Compose editor (the template pins 3.4.0; check the release notes), redeploy, and Umami migrates the schema at start. Take a backup before upgrading; our backup guide has the S3 setup.

Umami or Plausible?

Both are in Dokploy's template catalogue and both are cookie-free, open-source analytics. Plausible's community edition is a heavier stack (Elixir app, PostgreSQL and ClickHouse) and needs more memory, roughly 1 to 2 GB; Umami is lighter and simpler to run. Plausible's hosted plan starts at a monthly fee by page views; Umami Cloud has a free tier and paid plans. Self-hosting either on a $9.58 server next to your other Dokploy services makes the hosted fee the thing to compare against. If you want goals, funnels and a slicker UI, try Plausible; if you want the smallest footprint and the quickest setup, Umami.

Frequently Asked Questions

Is Umami GDPR-compliant without a cookie banner?

Umami is designed for it: no cookies, no cross-site tracking, visitor identification by a daily rotating hash and no stored personal data. That removes the consent requirement for analytics cookies under the ePrivacy rules in most readings, but you still need a privacy notice and your own assessment; self-hosting in the EU (MassiveGRID runs Frankfurt and London) keeps the data under your control for the GDPR side.

What are the default Umami login details?

Username admin, password umami. Change the password under Settings, Profile immediately after the first login; the default is published in Umami’s documentation and the dashboard is reachable from the internet.

How much server does Umami need?

Very little: about 100 to 150 MB of RAM for Umami and 50 to 200 MB for PostgreSQL, with disk growing a few gigabytes a year for a busy site. It fits in the MassiveGRID Starter preset (2 vCPU, 4 GB, 64 GB NVMe, $9.58 a month) alongside other Dokploy services.