I Killed My Vercel-Hosted Umami and Moved 13 Sites' Analytics Home

My analytics ran on Vercel with the data in someone else's Postgres. Railway's recent troubles were the reminder I needed: if losing the data would hurt, it shouldn't live in a database you can't log into.

Jask
Jask Independent researcher and developer

3 min read

阅读中文版

#self-hosting#Umami#Docker#data ownership

I switched off the Umami instance that ran on my Vercel account.

Umami is open-source web analytics. Think of it as the privacy-friendly Google Analytics: no cookies, no cross-site tracking, just the numbers. I run it for 13 of my sites, personal blogs and product pages alike. Which pages get read, where visitors come from, which day something suddenly spiked, that’s all Umami.

It lived on Vercel, with the database on Neon. Free tier, ran fine, and for a long time I didn’t think much about it.

The itch built up slowly

First, I tried to export my history. Everything Umami knows sits in Postgres, but with a hosted database you get one connection string and their rules. Backups, dumps, slow-query debugging, all on their terms. Getting a full local copy of my own traffic data felt like borrowing books in somebody else’s study.

Then Railway had its problems. Not my provider, but a peer PaaS wobbling is a mirror: my analytics chain was Vercel running the app and Neon holding the data, two links owned by other people. Change the pricing, trim the free tier, or simply have a bad day, and all 13 dashboards go dark together.

People calculate free PaaS in dollars. Money is the small part. The real cost is custody: your data sits in a database where how big it grows, how long it stays, and how you take it away are all decided by someone else.

I already had an idle box

I used to self-host a short-link service on a 2C2G VPS. I retired it recently, so the box sat there, billed and bored. Umami moving in costs me nothing at the margin.

The new setup is almost embarrassingly simple:

  • One 2C2G cloud server in Silicon Valley
  • Two Docker containers: the official Umami image with PostgreSQL, plus a postgres:17 container
  • Caddy in front as the reverse proxy, automatic HTTPS included

All of Umami’s state lives in the database, so the migration is a plain Postgres dump and restore. One evening of work, and all 13 sites came back with their full history.

Things you only learn once you own the database

Hosted, you face a black-box dashboard. Once you hold the database yourself, you learn its personality. One example: in the Umami v3 API, the same stat field returns a number from the list endpoint and a string from the detail endpoint. Anyone scripting against it gets bitten eventually. Before, that was a GitHub-issue mystery. Now it’s one query away.

Umami also has teams built in, sites grouped per team, which keeps a dozen properties manageable for one person. The team structure survived the move untouched.

What deserves self-hosting

I’m not a self-hosting fundamentalist. For prototypes and zero-traffic weekend projects, Vercel’s free tier is great. Don’t fight it.

My rule is a single question: if this data vanished tomorrow, would it hurt. If yes, it doesn’t belong somewhere I can’t log into the database. Analytics is the textbook case. It compounds. Comparing against three months ago is the entire point, and once it’s gone, it’s gone. You can’t backfill traffic you never recorded.

If you want to copy the homework: the cheapest VPS you can find, Umami’s official compose file, change the database password, point a domain at it. For extra safety, put a Cloudflare Tunnel in front so the origin IP never shows. That’s the pattern I documented for my short-link setup, and it transfers one to one.