I’m starting a small series on what I self-host and what I delegate to a provider for personal projects.
The rule isn’t ideological. I’m happy to pay for things that are genuinely business-critical: email delivery, backups, domains, payment processing, managed databases when the project needs them. Those are areas where downtime or data loss creates a real problem, and I’d rather buy reliability than spend a weekend rebuilding infrastructure.
But for accessories and nice-to-have services, I try to be more deliberate. Analytics falls into that category for most of my personal projects. It’s useful. I want to know whether people visit a site, which pages they read, and whether a new post or feature gets any attention. But if the dashboard disappears for a day, nothing breaks.
That distinction led me to Umami.
Umami is an open-source web analytics tool that I run myself, deployed through Coolify. It gives me the basic things I actually use: page views, visitors, referrers, countries, devices, and custom events. It also avoids the feeling that I’m installing a full advertising and profiling system on a small personal website.
I’ve used hosted analytics platforms before. They work, and I don’t think using one is a bad decision. The thing was that I kept paying, or accepting the trade-off of sending visitor data to another company, for information I barely checked. Once I looked honestly at my usage, I realised I needed much less than the bigger platforms offered.
So Umami became a good fit.
What I need from analytics
For personal projects, my questions are usually boring:
- Is anyone visiting this?
- Which pages get read?
- Where do visitors come from?
- Did the link in a newsletter, social post, or README send traffic?
- Did someone use a specific feature?
I don’t need attribution modelling. I don’t need ad conversion funnels. I don’t need a dashboard designed for a marketing team of twenty people. And I definitely don’t need to inspect individual users.
Umami handles the boring questions well. You add a lightweight script to the site, create a website entry in the dashboard, and traffic starts appearing. For actions that matter, I send custom events. A click on a demo button, a completed signup flow, or an outbound link can become an event without turning the application into an analytics project.
That last part matters. Analytics tends to expand if I let it. First it’s page views, then campaigns, then segmented funnels, then I’m adding tracking code to every screen. For a personal project, that usually creates more maintenance than insight.
I try to keep the instrumentation close to actual decisions. If I can’t explain what I’d do differently after seeing an event, I probably don’t track it.
Why self-host this part
Self-hosting Umami gives me a few things I value.
First, the data stays in infrastructure I control. I’m not claiming that makes it magically private or risk-free. I still need to secure the server, manage access, update the application, and understand the relevant privacy rules. But the data path is simple: the visitor’s browser sends analytics data to my Umami instance, and I control that instance.
Second, the cost is predictable. Umami itself is open source. I still pay for the server, storage, backups, and a domain, but it runs comfortably alongside other small services. I’m not adding a separate subscription per site just to count page views.
Third, I like that it gives me a boundary. The product is focused on analytics. It doesn’t constantly push me toward more tracking, more integrations, or more data collection. That’s probably a small thing, but product defaults influence behaviour.
And finally, I learn something from operating it. Not enough to justify self-hosting every service, but enough to make this one worthwhile. A small analytics service is a manageable way to stay familiar with containers, databases, reverse proxies, monitoring, and backups without putting critical systems at unnecessary risk.
Why I use Coolify
I run Umami on Coolify because it removes the parts of self-hosting that I don’t particularly want to repeat for every small service.
I still control the server and the deployment, but Coolify gives me a practical layer for deploying applications, assigning domains, handling TLS certificates, managing environment variables, and looking at logs. I don’t need to manually maintain a collection of shell scripts and reverse-proxy configuration for each project. I could do that, but it would be probably overkill for this use case.
For Umami, the setup is straightforward: deploy the application and its PostgreSQL database through Coolify, attach a domain, add the required environment variables, and let Coolify handle the application lifecycle. Updates still need attention, especially database migrations, but the normal operational work stays small.
That’s the balance I like. This is self-hosted, but it’s not handcrafted infrastructure. I’m deliberately delegating some platform concerns to Coolify while keeping the service and its data on my own infrastructure.
What Umami does well
The interface is clean and fast. That sounds minor, but it makes the tool more likely to get used. I can open a site, pick a date range, and get a sensible view of traffic without fighting a complex reporting system.
The core metrics are enough for me. Referrers tell me whether a link worked. Page views show what attracts attention. Event tracking gives me a rough signal about actions. Country and device data can catch obvious issues, like a mobile-only page problem or unexpected traffic from a scraper.
The privacy-oriented design is also a better match for how I want to run small sites. I prefer collecting the minimum useful data. It feels more respectful to visitors, and it reduces the amount of data I need to protect.
Limitations
This choice has real trade-offs.
Coolify makes deployment easier, but it doesn’t remove responsibility. I still own updates, database backups, server security, and recovery. If Umami breaks after an upgrade, I’m still the support team. If the server goes down, analytics disappears until I fix it. That’s acceptable because analytics isn’t business-critical in this context.
The numbers also won’t match every other analytics provider. Different tools define visitors and sessions differently, filter bots differently, and lose different amounts of traffic to blockers. I use Umami for trends and decisions, not as an accounting system.
And if I were running a business where analytics drove advertising spend, sales attribution, or contractual reporting, I’d probably choose a managed product, or at least put much more operational effort into this setup. Self-hosting would become less of a hobby-sized decision and more of an operational responsibility.
For my personal projects, Umami on Coolify hits the right balance: useful data, low recurring cost, reasonable privacy, and a small amount of infrastructure I’m comfortable owning.
That’s the pattern I expect this series to follow. I’ll pay for the parts that need professional-grade reliability. For the rest, I’ll self-host when the service is simple enough, useful enough, and not painful to recover from when something eventually goes wrong.