1 Introduction
In my previous articles, I have written two posts about self-hosted Umami. One is about setting up version 1.33.1 (see article:Docker Series: Building a Website Traffic Monitoring System Based on Umami), and the other is about setting up version 2.11.3 (see article:Home Data Center Series: Detailed Setup Tutorial for the Latest Version of Umami (2.11.3)). Although I have also deployed Google Analytics 4, Umami is indeed an excellent complementary tool—with a clean interface and intuitive data, it is perfect for quickly viewing visitor behavior and trends. From a personal use perspective, it offers a lighter and friendlier experience than GA4.
However, self-hosted Umami also has aspects that make me feel a bit “tired”: with every major version upgrade (such as from 1.x to 2.x, or from 2.x to 3.x),the data structure changes, and old data is not guaranteed to be seamlessly compatible. For example, the newly released v3 version even completely removes support for MySQL, keeping only PostgreSQL. This is very awkward for old sites built on MySQL: either go through the hassle of a full migration, or discard historical data and start over. Of course, there is another option, which is to use one version for a lifetime. However, those who can resist upgrading even when they know a new version is available are ruthless people with immense patience, far beyond ordinary people~.
Now I am once again facing the choice of whether to upgrade Umami to the v3 version. I want to see what new features the new version's interface has, but I really don't want to deal with the hassle anymore. After all, I've already gone through the upgrade from v1 to v2 once. Even if I upgrade from v2 to v3 this time, who knows how many major version upgrades there will be in the future, since Umami has a major version upgrade almost every year. Although in theory, you can manually back up and migrate the database, and then handle it step-by-step according to the upgrade documentation, in practice, it always feels like performing “brain surgery” on the database—a slight oversight leads to errors, missing data, or even rebuilding the service. For this reason, many people simply choose to deploy completely fresh during major version transitions, leaving no historical data behind.
On the other hand, self-hosted Umami actually consumes a non-trivial amount of resources. Especially if you, like me, build a blog using WordPress, with WordPress+MariaDB already running on the VPS, plus the Docker version of Umami (and PostgreSQL), the performance of a “mid-range” machine with **2 vCPUs + 2GB RAM** is not very abundant. Not to mention that most people's servers definitely run more than just these two services; a bunch of small things like logs, backups, and proxies all compete for resources.
So, is there a way to enjoy Umami's useful statistics without having to build the server-side yourself, without the hassle of upgrading, and while always keeping the latest version?
Of course there is, and that is what this article is going to introduce — Umami Cloud Hosting Service. Through official hosting, you can always experience the features of the latest version of Umami, saving yourself the trouble of maintenance. Crucially, the free version quota is actually completely sufficient for average personal blogs.
2 Comparison of Pros and Cons between Self-Hosted Umami and Umami Cloud Hosting
Although I feel that the free version quota of Umami Cloud is completely sufficient for average personal blogs, everyone's actual needs are different, and the free version of Umami Cloud indeed has its shortcomings. Therefore, in this chapter, I will briefly list the Self-hosted Umami 和 Umami Cloud Hostingpros and cons, so that everyone can see them at a glance and choose the most suitable method based on their own situation after comparison.
| Dimension | Self-hosted Umami | Umami Cloud Hosting |
|---|---|---|
| Deployment & Maintenance | Requires building your own server and database (only PostgreSQL database is supported starting from v3), offering high flexibility but also high maintenance costs. | Simply register an account, create the corresponding site, generate and embed the tracking code into the site's code to use. The server and database are officially hosted, requiring no maintenance, and upgrades are completed automatically, saving peace of mind. |
| Data Migration & Upgrades | During major version upgrades, the database structure may change, requiring manual data migration. Any improper operation may lead to errors or loss of historical data. | Data migration and compatibility are handled by the official team, making upgrades transparent, stable, and reliable, butthe free version only retains data for the last 12 months。 |
| Performance & Resource Consumption | High performance requirements on the VPS or server, especially when running WordPress + Umami simultaneously; even a mid-range machine with 2 vCPUs + 2GB RAM does not handle it easily. | Performance is handled by the official team, consuming no local server resources. No need to worry about resource bottlenecks from traffic fluctuations, making it suitable for lightweight usage scenarios. |
| Cost | The software is open-source and free, but you must bear the cost of the VPS running the software. | Eliminates maintenance costs. The free version supports up to 3 sites and 1 million events per month, which is generally sufficient for personal blogs; the paid version is billed based on features and event volume. |
| Privacy & Data Control | Data is stored on your own server, giving you complete control, including backup, deletion, and export, in compliance with your own privacy policy. | Data is stored in Umami Cloud. Privacy and compliance are guaranteed by the official team, suitable for legitimate sites, but the data is ultimately not under your complete control. |
| Security | You need to handle server security, database access control, firewall rules, bot protection, HTTPS configuration, etc., yourself. Security depends on whether the configuration is appropriate, posing human risks. | Uses official cloud services with HTTPS by default, built-in security mechanisms, and isolated environments, reducing maintenance risks, but requires trusting the official data hosting security. |
| Flexibility of Use | Free to modify source code, customize configurations, extend functions, and integrate systems, suitable for secondary development or complex scenarios. | Features are limited to the official interface and API, with low customizability, but the functionality is sufficient for most common monitoring needs. |
| Applicable Scenarios | Suitable for users who heavily rely on historical data, value autonomy, or enjoy tinkering with systems, as well as scenarios where complete control over privacy and API openness is desired. | Suitable for users who want a hassle-free, rapid deployment and focus on data visualization without wanting to maintain the backend, especially personal bloggers, small businesses, small sites, etc. |
Summary：
From an overall comparison, the biggest advantage of self-hosting Umami is complete control over data, unlimited history, and unlimited monitored sites, but at the same time, it requires maintaining your own server, manual upgrades, and bearing the performance pressure. On the other hand, the advantage of Umami Cloud is zero maintenance, automatic upgrades, stable performance, and quick setup, making it very hassle-free.
Of course, the free version of Umami Cloud also has obvious disadvantages:it only supports up to 3 sites, and data is only retained for the last 12 months. If you can accept these two points, then for personal blogs or small websites, Umami Cloud is undoubtedly the most hassle-free and straightforward solution.
3 Registering for Umami Cloud and Completing Basic Configuration Steps
Visit the official website registration link—https://cloud.umami.is/signup, and configure it according to the following graphic tutorial:
Then Umami Cloud will send a confirmation email to your registered email address:
In the confirmation email, copy the 6-digit confirmation code and click the ”Login” button to jump to the login verification interface:
On the login interface, use the username and password you registered with to log in, enter the confirmation interface, and input the 6-digit confirmation code from the confirmation email to confirm:
When registering for Umami Cloud, you need to select a data storage region (US or EU).The selected region determines which data center the data is stored in, as well as the applicable laws and privacy protection rules. Generally speaking,the EU region is more compliant with GDPR requirements, making it suitable for users who focus on privacy and compliance; while the US region may offer faster global access and a simpler legal environment. If your visitors do not mainly come from the EU, it is recommended to choose the US region.
Generate the JS script containing the tracking code:
Similarly, you can add other sites (free accounts can add up to 3 sites). After that, you only need to insert the saved site tracking code script into the code of the site you want to monitor (for friends using WordPress, the code insertion method can refer to the following link:Inserting Umami Tracking Code in WordPress)。
If you have a Cloudflare account and your site is published through Cloudflare, you can directly load the JS script from the cloud using Zaraz technology without adding it directly to the website code. Interested friends can refer to the article:Home Data Center Series - Optimizing Website Loading Speed: Cloud Loading and Management of Third-Party Scripts via Cloudflare Zaraz. Also, Cloudflare's UI has changed significantly now, and the Zaraz feature has been moved to the following location—it took me quite a while to find it~:
Finally, click on the website name to enter the monitoring interface:
Note: Being a bit lazy here, I won't take screenshots for each feature one by one. If you are interested, just register an Umami Cloud account and try it out yourself.
4 Enabling Dedicated Share Links
At the end of the previous chapter, I briefly introduced the site statistics content visible in the official Umami Cloud UI. However, this UI can only be seen after logging into Umami Cloud yourself and cannot be used for public release. If you want to publish it externally, you need to enable the ”Shared Link” feature. There is a share button in the top right corner of the official UI:
After that, anyone can view the statistics of the visited site in read-only mode through this link. You can directly check the display effect of this link:Umami Cloud Statistics Display Link。
5 Data Export
Umami Cloud has one more feature than self-hosted Umami, which is the export of statistical data. Therefore, for bloggers who are not sure whether they need to build Umami themselves, they can completely use Umami Cloud to experience it for a period of time. If they are really satisfied and confirm that they need to retain data for a long time, they can export the statistical data from Umami Cloud and import it into their self-hosted Umami according to the official manual.
Click the ”Settings” button:
Subsequently, you will receive an email in your registered mailbox containing a link to download the exported data:
Clicking the download link will download a zip file. The folder obtained after decompression contains 3 CSV files:
Mainly the ”website_event.csv” file. After opening it, you can see the statistical content:
The rest is about how to import the CSV file into the corresponding PostgreSQL or MySQL database of the self-hosted Umami. There are many tutorials online, and interested friends can research it on their own.
6 Summary
Choosing between self-hosting or using cloud services is essentially a balance between “controlling it yourself” and “handing it over to others,”there is no absolute good or bad, only what is suitable.
For example, many bloggers choose self-hosted Umami precisely because they value its flexibility of being fully controllable, unlimited, and having independent control over major version upgrades; while some people later migrated back from Umami Cloud to self-hosting because they were unwilling to be limited by the 12-month data retention limit of the free version.
But if you just want a simple and stable traffic statistic, do not rely on long-cycle data, and do not insist on various highly customized capabilities, then the features of the Umami Cloud free version are actually quite sufficient, especially for personal blogs, static sites, and some lightweight information pages.
So, the key is still to look at your needs:
- If you have a high desire for control, want to retain detailed data for a long time, and are willing to maintain the service, self-hosting is absolutely the right choice.
- If you want to quickly get started with statistical analysis, don't want to hassle with maintenance, and don't mind historical data being saved for a maximum of 12 months,then the Umami Cloud free version is actually the optimal solution。
For most personal blogs,"data from the past 12 months" is sufficient to fully reflect key indicators such as reader trends, content performance, and SEO effects. The Umami Cloud free version guarantees 1 year of data retention, which actually covers the vast majority of usage needs.
Often, only users with strict analysis needs for long-term data will feel that the demand to “must retain 3~5 years of data” is a rigid demand.. But frankly speaking, for most personal bloggers, this is more of an obsession or “OCD”—especially when traffic is low, keeping old data that is rarely looked back at for a long time has little practical value other than taking up storage.
For myself, except for checking it every day out of novelty when I first deployed Umami, I am usually too lazy to look at Umami's statistics now. After all, with at most a few hundred visits a day, it doesn't really matter whether I look at it or not; at most, I occasionally check the traffic of the last 24 hours on a whim. For an application that I only occasionally think of opening, spending VPS resources to build and maintain it (and having to do a major version upgrade every year) feels a bit uneconomical in retrospect (just for me).
So, for people like me, Umami Cloud is a more suitable choice.
I was using the PostgreSQL version back in 2.X, so I upgraded directly to 3.X without much trouble. The only thing is that a small bug remained: in the 2.X era, the default page redirected to "/dashboard". In 3.X, the default page became "/websites". After upgrading to 3.X, directly accessing the application's domain name still redirects to "/dashboard", resulting in a direct 404.
If it has always been PostgreSQL, upgrading across major versions should normally be fine, but the fear is that something abnormal might happen. If you really care about historical data, routine backup and preventive measures should still be taken before upgrading; after all, it's better to be safe than sorry. When I upgraded from 1.x to 2.x before, it was mainly because the deployment method had changed, from an integrated docker-compose deployment to a separated deployment with a Linux container deploying the Umami server + Docker deploying PostgreSQL, which is why I spent a long time messing around. However, the key is still whether you really care that much about historical data. If you don't, one year of data is more than enough. In this case, the Umami Cloud hosted method is the most worry-free.