Can I use Umami self-hosted analytics in a portfolio dashboard?
Last updated: November 6, 2026
SoleOS: One dashboard for revenue, traffic and live signals across every app, game and website you run. Start 7-day trial →
From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.
Yes, but not out of the box. Umami doesn't have a native, widely-supported connector in most portfolio dashboards (SoleOS included, at least today), so "using it in a portfolio dashboard" means either querying its API or database yourself, or exporting numbers on a schedule and feeding them into whatever rolls your products up. If you're running Umami because you want full control and no third-party data sharing, building a thin layer on top is consistent with that choice — it's just extra work you should plan for, not assume away.
Why Umami doesn't "just connect" like Stripe or GA4
Tools like Stripe, RevenueCat, and Google Analytics 4 have stable, documented OAuth flows and hosted APIs that a dashboard vendor can integrate once and trust to keep working. Umami is open source and self-hosted (or hosted on Umami Cloud), which means:
- There's no single OAuth app a dashboard can register with, because every instance is a different URL, different version, and different auth setup.
- The REST API exists and is reasonably well documented, but it's meant for you to query your own instance, not for third parties to request scoped read access the way Stripe restricted keys or GA4 service accounts work.
- Self-hosted versions can be on different release versions with slightly different schemas, so a generic connector would need to handle version drift that a SaaS API doesn't have.
None of that makes Umami bad — it's one of the better options if you want pageview and event data without sending it to Google or a VC-backed SaaS. It just means "portfolio dashboard integration" is something you build rather than something you toggle on.
What it actually takes to pull Umami into a portfolio view
If you want Umami numbers sitting next to your Stripe MRR and App Store installs, you have three realistic paths:
1. Query the Umami API directly. Umami exposes endpoints for stats, pageviews, and events, authenticated with an API key or a username/password token depending on version. You'd write a small script (cron job, serverless function, whatever you're comfortable maintaining) that pulls daily or weekly numbers for each site and pushes them somewhere your dashboard can read — a spreadsheet, a database table, or a webhook endpoint if your dashboard accepts custom metric pushes.
2. Export to CSV and import manually. Umami lets you export data from the dashboard UI. This works fine for a once-a-month gut check across 2-3 products, but it doesn't scale past that without becoming a chore you quietly stop doing — which defeats the point of a portfolio view in the first place.
3. Route Umami events through something that does have a connector. Some founders forward key events (signup, activation, purchase) from their app into both Umami (for the privacy-first traffic view) and a tool like PostHog or GA4 (for the parts of the funnel they want aggregated automatically). This is more plumbing, but it means your portfolio dashboard gets a reliable signal without you hand-rolling an API integration for every self-hosted instance you run.
None of these are hard engineering, but they're recurring maintenance: API keys expire, Umami versions get upgraded, servers move. Multiply that by however many of your products run Umami, and it adds up the same way any manual process does across a portfolio — see the honest numbers from running a 10-app portfolio for what manual overhead actually costs when it's spread across more than two or three products.
Where Umami fits versus what SoleOS pulls in automatically
Disclosure: SoleOS is built by the same people writing this post, so take the comparison with that in mind — we're not a neutral party here.
SoleOS currently connects to RevenueCat, Stripe, PostHog, GA4, Search Console, Bing Webmaster, App Store Connect, Google Play, Firebase, and Supabase with OAuth, API keys, or service accounts — no manual exports, and AdMob is planned next. Umami isn't on that list, and because it's self-hosted rather than a single SaaS API, it's a harder connector to build and maintain reliably across every founder's version and setup. If web analytics from a self-hosted, privacy-first tool is central to how you make decisions, SoleOS isn't going to replace that workflow today — you'd still run Umami as your source of truth and use a dashboard like SoleOS for the revenue, subscription, and store-side metrics that do connect cleanly.
That's a reasonable split for a lot of solo founders: keep Umami for traffic and privacy, let a portfolio tool aggregate the money and distribution metrics where native connectors already exist. If you want to see what that aggregated view actually looks like before deciding anything, the live demo uses sample data and doesn't require signing up.
When you don't need a portfolio dashboard for this at all
If you're running one or two products and already check Umami's own dashboard daily, adding another tool on top is probably unnecessary complexity. Umami's built-in dashboard is genuinely good for single-site or small-team use — real-time visitors, referrer breakdowns, and basic funnels are all there. The case for pulling it (or anything else) into a portfolio view only shows up once you're context-switching between four, six, ten dashboards and losing track of which product needs attention this week. If that's not you yet, skip the extra integration work and revisit it when the number of tabs you open each morning starts to annoy you.
It's also worth being honest about what web analytics can and can't tell you about a portfolio. Pageviews and sessions are a leading indicator at best — they don't tell you if a product is making money or losing users to churn. If your real question is "which of my apps are actually healthy," you'll get further by pairing traffic data with Stripe and RevenueCat tracked together than by perfecting your Umami pipeline first.
Frequently asked questions
Does Umami have an official API for third-party integrations?
Yes, self-hosted Umami exposes a REST API for stats, pageviews, and events, and it's documented well enough to build against. It's designed for you to query your own instance programmatically, not as a hosted OAuth integration point for external dashboards, which is why most portfolio tools don't offer a one-click Umami connector the way they do for Stripe or GA4.
Is Umami Cloud easier to connect than self-hosted?
Umami Cloud centralizes auth and uptime, which removes some of the version-drift and hosting headaches of self-hosting. But it's still a single-tenant API key per account rather than a scoped OAuth flow most dashboards build against, so you'd still be writing a custom integration — just against one stable endpoint instead of N self-hosted ones.
Can I just export Umami CSVs into a spreadsheet alongside my other metrics?
Yes, and for a small number of products checked monthly, that's often the pragmatic answer. It breaks down once you're doing it across more than a couple of products or want it refreshed more than monthly — manual exports are the first thing people stop doing when they get busy, which is exactly when the data matters most.
Will SoleOS add a native Umami connector?
Not currently on the roadmap, mainly because self-hosted tools require per-instance setup that doesn't fit the "connect once, trust the API" model our other connectors use. If that changes, it'll show up on the connectors page rather than requiring you to go digging for it.
What should I track instead if I don't want to build an Umami integration?
If your portfolio dashboard already supports GA4 or PostHog, consider routing key events there in parallel with Umami, or accept that web traffic stays in Umami's own dashboard while revenue and store metrics roll up elsewhere. Check the metrics dictionary for exactly what gets calculated from which source so you know what you'd be giving up either way.