Umami: What I Learned While Eating a Big Serving of Humble Pie.

Umami is a modern, privacy-focused analytics platform. An open-source alternative to Google Analytics, Mixpanel and Amplitude.

Umami Analytics is primarily built with JavaScript and TypeScript, using the React based Next.js framework. While the core application runs on these web technologies, it relies on a database for storing analytics data, with PostgreSQL being the recommended and officially supported option.

There are plenty of guides showing how to deploy Umami on Vercel and Supabase as a privacy friendly and inexpensive alternative to Google Analytics. But I had a different idea in mind and, admittedly, got a bit stubborn about it: I wanted to run Umami on AWS and given how little traffic my site gets, I wanted to pay as close to $0.00 for it as possible.

Naturally, the plan was to contribute this fresh, undocumented implementation back to the community. But if you’re still reading, it’s worth clarifying: this isn’t a tutorial or a step by step guide. It’s more of a cobbled together concept. Something that might one day be revisited and developed into a proper solution, if it ever sees the light of day.

Stacks I Considered:

First idea: run Umami’s Docker containers on AWS ECS. There are official Umami containers — great. But how low could I push the price if I deployed ECS on the smallest EC2 instance available? Answer: not very. Still a few dollars a month. Unacceptable.

Next idea: deploy the analytics front-end on AWS Amplify, a stack I already use and wanted to explore further. Perfect… except Umami needs a Postgres backend, and I wanted to keep everything AWS-native. I considered AWS RDS, but that was an order of magnitude more expensive than I was willing to pay. What I really needed was something like a serverless relational database. Basically DynamoDB but SQL-flavored.

Enter AWS DSQL. A relatively new service, Generally Available in multiple regions, and billed via Distributed Processing Units — which means no activity, no cost. Fantastic. I could host the frontend on Amplify and let DSQL handle the storage.

But then reality hit: DSQL doesn’t support simple user:password authentication. It relies on ephemeral tokens and IAM roles. That meant Amplify would need an Umami adapter, and Umami would somehow need to generate DSQL auth tokens at connection time.

And that’s where everything fell apart. Too many new concepts at once. Documentation was thin. I couldn’t find any real-world examples showing how to make this work. I did find a short presentation explaining how to generate DSQL tokens in an Amplify app, but the GitHub source for the demo was nowhere to be found.

In Closing:

I shelved the idea and let it sit for a while. During my second attempt, I stumbled across discussions questioning Umami’s claims of GDPR compliance. I’m no lawyer, but the argument boiled down to this: Umami uses IP addresses to determine the visitor’s country, and that counts as processing PII, meaning GDPR applies.

So much ado for nothing. I’m already chuckling at my own foolhardiness.

Back to more accessible things — like expanding the features on this site that are still missing.