When self-hosted Umami or Umami Cloud fits your team
A team choosing a web analytics platform often has one of two constraints: the analytics data must stay inside its own cloud account, data center or network, or it does not want to run a Node.js and PostgreSQL service at all. Self-hosting removes the subscription but moves the upkeep to your team. Umami Cloud charges for events and retention, and it includes cloud-only features such as email reports and a streaming API that the free self-hosted version does not have. Neither option is better in general; the right one depends on which of those two constraints is binding.
Self-hosted Umami is the better fit when data residency or internal policy requires analytics events to stay in infrastructure you control, or when you already run Node.js and PostgreSQL services and have people who patch and back them up. The Umami installation documentation requires Node.js 18.18 or newer for a source install and supports PostgreSQL from version 12.14, and the project publishes a Docker image and a Docker Compose file that starts Umami with a bundled PostgreSQL database. Your team then owns upgrades (the project's v3.4.0 release was published on September 17, 2026), database backups, TLS, and the uptime of the collection endpoint. Confirm with your platform team who carries that on-call load before you commit.
Umami Cloud is the better fit when no one on the team wants to operate the service, when you need email reports or the streaming API now, or when your event volume and retention needs sit comfortably inside a published plan. Pricing on the Umami pricing page starts at $0 per month for up to 100K events with 6 months of retention, and rises to $20 per month for 1 million events with 2 years of retention and $200 per month for 10 million events with 5 years. Overage is billed per extra event, so model your monthly event count and the retention you need for compliance reviews before choosing a tier. Ask the vendor how overage is invoiced and whether Enterprise terms apply at your scale.
How self-hosted Umami and Umami Cloud compare on the facts
This table sets the published Umami Cloud plans against the requirements of a self-hosted install, row by row. Read it as a checklist: the license and software cost favor self-hosting, while event limits, retention and cloud-only features decide whether a managed plan is the better fit.
| Factor | Self-hosted Umami | Umami Cloud |
|---|---|---|
| License | MIT license, free to self-host according to the project README and pricing page | Hosted service under Umami's published pricing terms; confirm current terms before signing |
| Software cost | No license fee for the open-source platform; you pay for hosting, database, backups and staff time | Hobby at $0 per month, Pro at $20 per month, Business at $200 per month, per the pricing page |
| Installation requirements | Node.js 18.18 or newer for a source install; PostgreSQL 12.14 or newer | Nothing to install or patch on your side |
| Docker option | Prebuilt Docker image and a Compose file that starts Umami with a bundled PostgreSQL database | Not applicable |
| Event limits and retention | Limited by your own hardware and database sizing; no vendor cap | Hobby: 100K events, 6 months retention. Pro: 1 million events, 2 years. Business: 10 million events, 5 years |
| Overage rates | None set by the vendor; storage and compute growth is your cost | Pro: $0.00003 per extra event. Business: $0.00002 per extra event. Ask for Enterprise terms in writing |
| Enterprise terms | Not applicable | Custom pricing and retention on Enterprise; confirm scope, limits and support terms with Umami directly |
| Cloud-only features | Email reports and the streaming API are not in the self-hosted version, per the pricing page | Includes email reports and the streaming API, per the pricing page |
Which Umami Cloud plan maps to your event volume
Umami Cloud Hobby is the entry tier and is listed at $0 per month. It covers up to 100K events with 6 months of retention, which suits a small site, a single product or a trial period where you want cookieless analytics without running any infrastructure. Because the plan is free, the cost question shifts to whether six months of history meets your reporting and audit needs.
- Event cap: up to 100K events per month on the published Hobby tier.
- Retention: 6 months of stored data.
- Price: $0 per month, according to the Umami pricing page.
- Who it suits: low-traffic sites, pilots and teams that do not need year-over-year comparisons.
- Watch for: a sudden traffic spike that pushes you past the cap, and any reporting requirement longer than six months.
Before you commit, check your current monthly event count, your projected growth and whether any internal policy requires analytics history beyond six months.
Umami Cloud Pro is listed at $20 per month for 1 million events with 2 years of retention. It fits a growing marketing site or a product with steady traffic that needs annual comparisons without the operating work of a self-hosted install. Extra events are billed beyond the included volume at $0.00003 per event on Pro, according to the Umami pricing page.
- Event cap: 1 million events per month included.
- Retention: 2 years of stored data.
- Price: $20 per month, with overage at $0.00003 per extra event.
- Overage example (illustrative): 200,000 events above the cap would add $6 at the published Pro rate.
- Who it suits: teams that want two years of history and predictable billing with headroom above their current volume.
Model your peak month, not your average, because overage is charged per event and a campaign can move you across the cap quickly.
Umami Cloud Business is listed at $200 per month for 10 million events with 5 years of retention. It is the tier for high-traffic properties, multiple sites under one account or longer compliance-driven retention. Extra events are billed at $0.00002 per event on Business, which is lower than the Pro rate, according to the Umami pricing page.
- Event cap: 10 million events per month included.
- Retention: 5 years of stored data.
- Price: $200 per month, with overage at $0.00002 per extra event.
- Overage example (illustrative): 2 million events above the cap would add $40 at the published Business rate.
- Who it suits: large consumer properties and organizations that need five years of history in a managed service.
- Watch for: volume above 10 million events or retention beyond five years, which move you to Enterprise.
Confirm with Umami which features and events are counted toward the cap for your setup before you size the plan.
Enterprise is not published with a fixed price or cap. Umami lists custom pricing and custom retention for this tier, so any organization with event volume above the Business cap of 10 million events per month, or with retention needs beyond five years, must request a quote. Enterprise is also the route for organizations that need terms tailored to procurement or data residency rules.
- Event cap: custom, above the published Business cap.
- Retention: custom, beyond the published five years where required.
- Price: custom quote, with no published rate.
- What to request: written event volume estimates, retention periods, the features you need and the contract term.
- Who it suits: high-volume properties and regulated teams that need custom retention.
Prepare your event counts and retention requirements in writing before you contact Umami, so the quote reflects your actual scope.
Where your analytics data lives and who controls it
Umami Cloud and self-hosted Umami store the same kind of data in very different places, under different operators. The cards below cover the decisions that follow from that split: where the data sits, who can reach it, how long it is kept, what personal data is collected, what evidence you can produce, and what the vendor's terms commit to.
Data location and hosting control
With self-hosted Umami, the database runs on PostgreSQL in your own cloud account, data center or air-gapped network, so you decide the region and the hosts. With Umami Cloud, events are processed in the vendor's hosted environment. Ask the vendor which regions and providers process your data, whether backups leave those regions, and whether you can choose a location that matches your residency rules.
Access control and administrator scope
Self-hosted Umami access is governed by the accounts you create in your own database and by the network paths you open to the application. On Umami Cloud, administrators of your workspace and the vendor's operations staff sit on different sides of the access boundary. Document who can view raw events, who can export data, and who can change tracking settings, then confirm how the vendor limits and logs its own staff access.
Retention settings and deletion
Retention is a commitment you must match to your own policy. Umami Cloud plans publish retention periods that differ by tier, so the period you buy also sets how long event history exists. Self-hosted installs keep data until you delete it or run your own cleanup, which means retention is only as good as the jobs and backups you control. Confirm how deletion requests are fulfilled on each option, including backups and replicas.
Cookieless design and personal data
Umami describes itself as working without cookies, cross-site tracking or the automatic collection of personal data. That design choice applies to both options, but it does not settle your legal position. Review which fields you send, including URLs with query strings, referrers and custom event properties, because those are the places where personal data can enter the dataset regardless of the tool.
Audit evidence and assurance
Self-hosted Umami gives you the logs, configuration and infrastructure records that an assessor will ask for, because they live in your environment. For Umami Cloud, you depend on the evidence the vendor is willing to share. Do not assume any certification or attestation applies to Umami Cloud. Request the vendor's current security and compliance documentation in writing and involve your own assessor before relying on it.
Data processing terms and responsibility
Umami Cloud is a service where the vendor operates the platform and holds the data, so the data processing terms define responsibilities for security, subprocessors, breach notice and deletion. With self-hosting, your organization is the operator and carries those duties itself. Obtain the current data processing agreement, the subprocessor list and the breach notification terms before you send production traffic, and have legal and privacy staff review them.
What running self-hosted Umami takes from your team
Running self-hosted Umami means your team owns the whole stack. The fastest route is the prebuilt Docker image or the Docker Compose file, which starts Umami with a bundled PostgreSQL database. That convenience carries a decision: a bundled database is simple to start but still needs backups, storage monitoring and version tracking, so most teams with an existing database service will point Umami at an external PostgreSQL instance instead. Confirm which PostgreSQL version your chosen deployment expects. Umami's installation documentation states it supports PostgreSQL from version 12.14, so check that floor against your own database standards before you deploy. A source install adds a Node.js requirement of 18.18 or newer, which means someone must own Node.js patching on the host.
Upgrades are the recurring task. Umami v3.4.0 was published on September 17, 2026, after v3.3.1 on August 20 and v3.3.0 on August 12, so the release cadence is frequent enough to require a standing owner, a test environment and a rollback plan. Read each release note before pulling a new image, back up the PostgreSQL database first, and verify that tracking still works afterward. Around that routine, you still need TLS certificates for the analytics hostname, uptime monitoring for the collection endpoint, and a capacity review as traffic grows. Size the database and host against your own event volume, since no self-hosted capacity figure is supplied here and the cloud event tiers do not translate directly into server sizing.
The free license carries no support contract. Umami is MIT licensed and can be self-hosted for free, so when a release breaks your install, the fix sits with your team or with a partner you pay under a separate written scope. Weigh that against the two features Umami Cloud adds: email reports and a streaming API. If a stakeholder needs scheduled email reports, decide whether to build them with your own scripts and mail service, or to pay for Umami Cloud. Building an alternative means maintaining it too, so list the owner, the schedule and the data source before you commit. Ask Umami directly on the pricing page which features are included in each plan, and confirm the current feature set against your requirements before you choose.
What your team runs in each hosting model
This table sets out who carries each recurring operating task under Umami Cloud and under a self-hosted Umami install on Node.js and PostgreSQL. Read each row as a question to answer for your own team, and treat every vendor-side entry as something to confirm in Umami Cloud's terms before you rely on it.
| Operating task | Umami Cloud | Self-hosted Umami |
|---|---|---|
| Infrastructure provisioning | Umami operates the hosting; confirm regions, capacity and data location in its terms | Your team selects hosts, containers or VMs and networking in your own cloud or data center |
| Database administration | Confirm in Umami Cloud's terms whether the vendor manages PostgreSQL, tuning and scaling | Your team runs PostgreSQL 12.14 or newer, including sizing, tuning and access control |
| Application upgrades | Confirm the vendor rolls out upgrades and whether any downtime or opt-in applies | Your team tracks releases, such as v3.4.0, and applies upgrades on its own schedule |
| Backup and restore | Confirm backup frequency, retention of backups and restore procedures in the terms | Your team designs, tests and stores database and configuration backups and proves restores work |
| Security patching | Confirm vendor patch timing for the platform and its hosting layer | Your team patches the OS, Node.js runtime, container images and PostgreSQL |
| Uptime monitoring | Confirm any availability commitment or status reporting the vendor publishes | Your team deploys its own health checks, alerting and on-call coverage |
| Data retention management | Retention depends on plan, such as 6 months on Hobby, 2 years on Pro and 5 years on Business | Your team sets and enforces retention and deletion in the database |
| Feature access | Email reports and the streaming API are cloud-only features per Umami's pricing page | Core analytics are available for free; cloud-only features need Umami Cloud or a different tool |
Moving analytics between self-hosted Umami and Umami Cloud
This sequence moves Umami analytics from one host to the other without losing track of traffic or breaking existing dashboards. It ends with a signed comparison of both sides and a retired source instance. Historical data may not transfer, so the export answer comes first.
Confirm export and history rules in writing
Before you commit to either direction, ask Umami for written answers on three points: whether historical event data can be exported from self-hosted Umami or from Umami Cloud, in which file formats, and whether that history can be imported into the target. Ask how retention on the target applies to imported data, since Umami's pricing page lists 6 months on Hobby, 2 years on Pro and 5 years on Business. This step is done when you hold written answers. If export or import is not available, plan to keep the old instance running read-only for historical reporting.
Size the target plan from measured traffic
Pull the monthly event count from your current instance, or from the Umami Cloud usage view if you are moving to the cloud, and compare it with the included events: 100K on Hobby, 1 million on Pro and 10 million on Business. Umami's pricing page lists overage at $0.00003 per extra event on Pro and $0.00002 on Business, so you should model a sustained increase as well as a short spike. Confirm with Umami whether its event counting matches your current instance, because a mismatch will appear as a gap in the first comparison report. Done when you have a written plan choice with headroom noted.
Provision the target instance
For Umami Cloud, create the account and website entry and record the tracking identifier. For self-hosted, a source install needs Node.js 18.18 or newer and PostgreSQL 12.14 or newer, while the prebuilt Docker image and Compose file start Umami with a bundled PostgreSQL database. Your platform team owns TLS, backups, the database host and the network path from visitor browsers to the endpoint. Done when the target accepts a login and a test page view appears in its dashboard. Check the installation documentation for the current requirements before you build the host.
Archive history from the source instance
Take a full backup of the self-hosted PostgreSQL database before any change, and record every website ID, domain and custom event name in an inventory file. If Umami provides an export for your version or plan, run it and store the output with checksums. A move in either direction depends on the same export answer you received in the first step. Done when you have a restorable backup and an inventory that a second engineer can read. Keep the source database in place until the final step.
Repoint the tracking script on staging
Change the script source and website identifier in the site template or tag manager so they point to the target. Use only the endpoint and identifier issued by the target instance. Load a staging page, trigger a page view and one custom event, and confirm both arrive in the target with the expected URL and referrer. Test in a clean browser profile, since extensions that block scripts will hide events from you. Done when the staging test passes, after which you roll the change to production pages in batches so failures show up quickly.
Run both instances in parallel
Keep the old instance collecting while the new one collects, so you have overlapping periods to compare. Expect early differences from blocked scripts, bot filtering and sessions that span the cutover, and record the cause of each difference. Ask Umami to confirm how each side filters bots and counts unique visitors. Done when you have at least one full business cycle of overlapping data and a written list of known variances that the owner has accepted.
Validate reports and retire the old instance
Compare pages, referrers, goals and custom events between both sides across the overlap window. Check dashboards that rely on older data, because a Hobby site keeps only 6 months of retention and older views will not exist there. Umami's pricing page says Umami Cloud adds email reports and a streaming API that the self-hosted version lacks, so rebuild any reporting or integration that depends on those features before you cut over. Sign off with the report owner, stop collection on the old site, keep the backup under your retention policy and decommission the host.
How the cost of each model is structured
Self-hosted Umami has no license fee, because the MIT-licensed platform is free to run on your own infrastructure. The cost sits elsewhere: the servers or containers that run the Umami application, the PostgreSQL database it writes to (the installation documentation sets the supported floor at PostgreSQL 12.14 or newer), backups, TLS, monitoring, and the staff hours spent on upgrades and incidents. Your own team pays for those, and any outside help is a separate invoice. Umami Cloud works the other way around. You pay a recurring plan fee (published as $0 per month for Hobby, $20 per month for Pro and $200 per month for Business), and the vendor carries the hosting and upkeep. Overage applies when you exceed a plan's event allowance, at $0.00003 per extra event on Pro and $0.00002 on Business, according to Umami's pricing page. Confirm current figures on Umami's pricing page before you build a budget, since plan terms can change.
Several inputs move the total cost of either model. Event volume is the largest driver on Cloud, because it sets which tier you need and whether overage applies. On self-hosted Umami, volume drives database storage, query load and the size of the server you provision. Retention length matters in the same way: Cloud retention is tied to the plan (6 months on Hobby, 2 years on Pro, 5 years on Business), while self-hosted retention is whatever your team configures and must store. The number of sites tracked, the skills your team already has with Node.js and PostgreSQL, and how much downtime your stakeholders will tolerate for analytics all shift the self-hosted side. A dashboard that is allowed to be offline for a day needs less engineering than one that feeds a live campaign report.
When you request a quote for an implementation or retainer, ask for a written scope that lists the environments, the sites and event volumes in scope, the retention you need, and the systems Umami must connect to. Ask for named deliverables (for example, the deployed stack, backup and restore evidence, and handover documentation), timelines with milestones, and the acceptance criteria for each. For ongoing work, ask for the retainer terms: included hours or response expectations, what is excluded, how upgrades between Umami releases are handled, and how changes beyond scope are priced. Ask DeployOpen to state which items are one-time and which recur. Requests like these produce a quote you can compare with the Cloud plan fees line by line.
Questions buyers ask before choosing Umami Cloud or self-hosting
How much does self-hosting Umami cost compared with the published plans?
The software itself is free, so self-hosting costs are the infrastructure and the staff time to run it. Umami's pricing page lists Umami Cloud Hobby at $0 per month for up to 100K events with 6 months of retention, Pro at $20 per month for 1 million events with 2 years of retention, and Business at $200 per month for 10 million events with 5 years of retention. Those figures are the cloud side of the comparison. On the self-hosted side, ask your team to price the servers or containers, the managed or self-run PostgreSQL database, backups, TLS certificates, monitoring and upgrade time. Those costs recur monthly and grow with traffic, retention length and the number of sites you track. Compare them against the plan that matches your event volume and the retention you need.
How long does a self-hosted Umami install take and what does it need from staff?
Duration depends on your platform and how you deploy, and no install time is published in the sources, so confirm it with your own engineers. The documented paths are a source install, which requires Node.js 18.18 or newer and PostgreSQL 12.14 or newer, or the prebuilt Docker image at docker.umami.is/umami-software/umami with a Docker Compose file that starts a bundled PostgreSQL database. The Docker route is the lighter first step. Staff need to handle the web application, the database, reverse proxy and TLS, secrets, backups, restores and version upgrades. Umami v3.4.0 was published on September 17, 2026, so plan a recurring upgrade routine and test it against a copy of your data before applying it to production.
Can a team run self-hosted Umami without outside help?
Yes, if you have people comfortable with Docker or Node.js, PostgreSQL administration and routine Linux operations. Umami is MIT licensed, so you can run it without a commercial contract. The question is who will own the install after launch. Check whether you have someone on call for outages, who applies security updates, and who tests upgrades. If those roles are thin, a fixed-scope implementation or a retainer with DeployOpen could cover deployment, hardening, backups, documentation and upgrades inside your own infrastructure. DeployOpen does not publish a price list, so a quote follows from the written scope.
When should a team pick Umami Cloud instead of running its own install?
Pick Umami Cloud when you want analytics running without owning a database, application servers or upgrades, and when your event volume and retention fit a published plan. Hobby, Pro and Business cover different event tiers and retention periods, so start by estimating monthly events and how long you need to keep data. Pick self-hosting when your data must stay inside your own infrastructure, when retention needs exceed the plan you would buy, or when your event volume would push you into overage rates. Overage on Umami Cloud is $0.00003 per extra event on Pro and $0.00002 on Business, which can become a material recurring cost at high volume. Confirm the current terms on the pricing page before deciding.
Can analytics data move between Umami Cloud and a self-hosted install?
The sources do not describe a supported migration path between Umami Cloud and a self-hosted database, so do not assume one exists. Ask Umami directly how export and import work, what format the data uses, and whether historical events, sites, users and tracking IDs carry over. Also check how the tracking script is embedded on your sites, because changing the script endpoint affects every page. Plan a parallel run where both systems collect data for a short period so you can compare counts before you cut over. DeployOpen can scope the migration work as part of a fixed-scope engagement once the requirements are written down.
Which cloud-only features need replacing if we self-host Umami?
Umami's pricing page says Umami Cloud adds features the self-hosted version lacks, and it names email reports and a streaming API as examples. Those are the features to replace or drop. List every report your stakeholders receive today and every system that reads analytics data, then decide whether each one needs an alternative. Email reports could be replaced by scheduled exports or a separate reporting job, and a streaming API could be replaced by reading from the database or building a small integration. Confirm the full list of cloud-only features on the pricing page, because the sources name only these two examples.
What retention and privacy questions should we settle before choosing?
Start with how long you need to keep events, because retention drives both plan choice and storage cost. The cloud plans list 6 months for Hobby, 2 years for Pro and 5 years for Business, and Enterprise offers custom retention. Self-hosted retention is set by your own database growth and backup policy. On privacy, Umami describes itself as working without cookies, cross-site tracking or automatic collection of personal data, but your legal obligations depend on what you configure and collect. Ask your privacy or legal team to review the data flow, the hosting location and the retention schedule. Umami does not issue compliance attestations, so treat its documentation as product information, not as proof of compliance.
How DeployOpen scopes, delivers and supports a self-hosted Umami install
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Umami, that means running the MIT-licensed analytics platform on your infrastructure with your own PostgreSQL database and your own retention and data handling decisions, rather than sending traffic data to a third party.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the sites, domains and event volumes Umami will measure, and who owns each one.
- Scope records the hosting target, PostgreSQL version, Node.js runtime or Docker approach, and who operates each layer.
How we build
- We install Umami from the Docker image or a source build, configured to your network, DNS and TLS standards.
- We set up the PostgreSQL database, backups and restore tests so analytics data survives host failure.
- We test tracking scripts, dashboards and access controls before go-live, then document each configuration choice.
How we hand over
- Handover includes runbooks for upgrades, database maintenance, secret rotation and tracking-script changes.
- Your team receives documentation of data flows, retention settings and the hosting components you own.
- We confirm which parts of the install stay with your team and which sit under a support retainer.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- Upgrade work follows Umami's published release notes, so each version change is reviewed before rollout.
- Ask any provider to confirm response expectations and upgrade responsibilities in the quote, not in general terms.
