DEV Community: Cyborgmachine

Why I Use Umami Instead of Google Analytics (And Don't Have a Cookie Banner)

Cyborgmachine — Tue, 29 Sep 2026 17:26:06 +0000

When I was setting up analytics for my blog, Google Analytics seemed like the obvious choice. But once I looked at what it actually requires — a tracking script, a cookie consent banner, a cookie policy page, conditional script loading — it felt like way too much for a personal site that doesn't run ads or retargeting.

So I went with Umami instead. It's open-source, self-hosted, and doesn't use cookies at all. No consent banner needed, and my data stays on my own server.

What's Actually Wrong With Google Analytics

Cookies and consent overhead. GA sets first-party tracking cookies (_ga, _ga_<container-id>). Under GDPR, that means you need a proper cookie consent banner with category-by-category opt-in. And users who reject cookies simply won't be tracked — so your data is incomplete from day one.

Your data lives on Google's servers. They process it for their own purposes too. You get a "free" analytics tool, and Google gets visibility into your traffic patterns.

It's heavy and overcomplicated. The GA4 snippet loads around 90–135KB of JavaScript. The dashboard is built for enterprise use cases — overkill if you just want pageviews, referrers, and device stats.

Why Umami

Umami is an open-source, self-hosted analytics platform that gives you the metrics you need without the privacy baggage.

No cookies — sessions are identified using a hash of IP + user agent + website ID. Nothing personal is stored, no consent banner required
Your data, your server — self-hosting on a VPS means no third party ever sees your analytics
Lightweight — the tracking script is under 2KB (vs GA's 90KB+)
Clean dashboard — one page with pageviews, unique visitors, bounce rate, session duration, referrers, browsers, OS, devices, and geo data
Easy to deploy — Docker + PostgreSQL, that's it

How I Set It Up

Here's the Docker Compose config I use:

umami:
  image: ghcr.io/umami-software/umami:latest
  container_name: umami
  environment:
    DATABASE_URL: postgresql://umami:${UMAMI_DB_PASSWORD}@umami-db:5432/umami
    APP_SECRET: ${UMAMI_APP_SECRET}
    TWO_FACTOR_ENCRYPTION_KEY: ${UMAMI_2FA_KEY}
  depends_on:
    umami-db:
      condition: service_healthy
  init: true
  restart: always
  healthcheck:
    test: ["CMD-SHELL", "curl -f http://localhost:3000/api/heartbeat"]
    interval: 5s
    timeout: 5s
    retries: 5

umami-db:
  image: postgres:16-alpine
  container_name: umami-db
  environment:
    POSTGRES_DB: umami
    POSTGRES_USER: umami
    POSTGRES_PASSWORD: ${UMAMI_DB_PASSWORD}
  volumes:
    - umami-db-data:/var/lib/postgresql/data
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U umami"]
    interval: 5s
    timeout: 5s
    retries: 5
  restart: always

After docker compose up -d:

Log in at port 3000 with admin / umami, change the password immediately
Go to Settings → Websites → Add website
Copy the tracking script into your site's <head>

In Next.js I use the Script component:

import Script from 'next/script';

<Script
  defer
  src="https://your-umami-instance.com/script.js"
  data-website-id="your-website-id"
  strategy="afterInteractive"
/>

No Cookie Banner, By Design

With Google Analytics I would have needed to build consent UI that loads before tracking, implement granular consent categories, write a cookie policy, and add conditional script loading. All of that for a personal blog.

With Umami the script just loads. Every visitor gets tracked from the start, and nobody has to click through a consent popup. Cleaner UX, complete data.

What You Give Up

To be fair, there are trade-offs:

No cross-site tracking — you can't follow users across domains or build retargeting audiences
No Google Ads integration — if you run paid campaigns, you'll need GA for conversion attribution
Simpler event tracking — Umami's custom events don't have GA4-level granularity for complex funnels
Self-hosting maintenance — you're responsible for updates and database backups (minimal, but it's there)

For a blog or portfolio, none of these matter. You're not retargeting visitors or running ad funnels.

GA vs Umami at a Glance

Feature	Google Analytics	Umami
Cookies	Yes (`_ga`, `_ga_<id>`)	None
Cookie banner required	Yes (GDPR)	No
Data location	Google's servers	Your server
Script size	~90KB+	<2KB
Self-hostable	No	Yes
Price	Free (data as payment)	Free (open source)
Setup complexity	Moderate	Low (Docker)
Dashboard	Complex, enterprise-focused	Simple, one-page
Cross-site tracking	Yes	No
Ad integration	Yes	No

Bottom Line

If you're running a personal site, blog, or small project — think about whether you actually need Google Analytics. Umami gives you everything that matters (who visits, where they come from, what they read) without the privacy infrastructure overhead. Setup takes about fifteen minutes if you already have Docker running.

Umami on GitHub →

Connecting Cloudflare Is Not Enough: How to Actually Get an A+ on SSL Labs

Cyborgmachine — Sun, 27 Sep 2026 18:46:24 +0000

If you've just added your site to Cloudflare, you might assume your TLS configuration is solid. You'd be wrong.

By default, Cloudflare sets your minimum TLS version to 1.0 — a protocol from 1999 that has known vulnerabilities and has been deprecated by every major browser. HSTS is off. Your SSL Labs score is likely sitting at a B or lower, and you don't even know it.

I learned this the hard way while hardening my self-hosted site. Here's every setting I changed to go from Cloudflare's defaults to an A+ on SSL Labs — and why each one matters.

The Problem With Cloudflare's Defaults

Cloudflare is an excellent CDN and security layer, but it optimizes for maximum compatibility out of the box, not maximum security. That means:

Minimum TLS Version: TLS 1.0 (vulnerable, formally deprecated by the IETF in 2021)
HSTS: Disabled
TLS 1.3: Enabled, but undermined by allowing TLS 1.0/1.1

This is a reasonable default for Cloudflare. They serve millions of sites, some of which still need to support ancient clients. But for your modern web application, there's no reason to keep these settings.

Step 1: Raise the Minimum TLS Version

This is the single most impactful change. Go to SSL/TLS → Edge Certificates and find "Minimum TLS Version."

You'll see a dropdown defaulting to TLS 1.0. Change it to TLS 1.2.

Why TLS 1.2 and not 1.3? Because TLS 1.2 is the floor — clients that support TLS 1.3 will still negotiate 1.3 automatically. Setting the minimum to 1.2 just cuts off the insecure protocols (1.0 and 1.1) that no modern browser needs anyway. Every major browser dropped TLS 1.0/1.1 support in 2020.

While you're here, make sure TLS 1.3 is toggled on. It should be by default, but verify it.

Step 2: Enable HSTS

HTTP Strict Transport Security tells browsers to always use HTTPS for your domain — no exceptions, no fallback to HTTP. Without it, a first-time visitor could be intercepted before the HTTPS redirect kicks in.

Go to SSL/TLS → Edge Certificates and click "Change HSTS Settings." Enable everything:

Enable HSTS: On
Max-Age: 12 months (the maximum — shorter values weaken the protection)
Include Subdomains: On (if all your subdomains support HTTPS)
Preload: On
No-Sniff Header: On

⚠️ A word of caution: HSTS is a commitment. Once a browser receives the HSTS header, it will refuse to connect over HTTP for the duration of the max-age. If you later need to serve your site over plain HTTP (you shouldn't), you'll have a bad time. Make sure HTTPS works perfectly before enabling this.

The "Preload" option adds the preload directive to your HSTS header, which signals that your domain is eligible for the HSTS Preload List built into browsers. Once on the list, even the very first visit will be forced to HTTPS. But enabling the toggle alone isn't enough — you still need to manually submit your domain at hstspreload.org after configuring these settings. Inclusion can take weeks or months to propagate through browser releases, and it's the hardest setting to undo.

Step 3: Force HTTPS Everywhere

Two more toggles in the same section:

Always Use HTTPS: On. This redirects all HTTP requests to HTTPS across your entire domain. Simple but essential.

Automatic HTTPS Rewrites: On. This fixes mixed content issues by rewriting http:// resource URLs to https:// on the fly. It won't fix everything (inline scripts, for example), but it catches most third-party embeds and legacy URLs.

Step 4: Enable Certificate Transparency Monitoring

This one isn't about your SSL Labs score, but it's worth enabling while you're in the settings. Certificate Transparency Monitoring sends you an email whenever a Certificate Authority issues a certificate for your domain.

Why does this matter? If someone manages to get a fraudulent certificate for your domain (through a compromised CA or a social engineering attack), you'll know about it immediately. It's free, it's a toggle, and there's no reason not to turn it on.

Don't forget to actually add your email address to the notification field — the toggle alone doesn't do anything without a recipient.

Step 5: Harden Your Origin Server

Cloudflare handles the connection between the visitor and Cloudflare's edge, but there's a second TLS connection between Cloudflare and your origin server. If your SSL/TLS encryption mode isn't set to Full (Strict), this connection might not be properly validated.

Go to SSL/TLS → Overview and set the mode to Full (Strict). This requires a valid certificate on your origin — either from a public CA (Let's Encrypt via Certbot works perfectly) or a Cloudflare Origin Certificate.

If you're running Nginx, make sure your origin config only allows modern protocols too:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

This mirrors what Cloudflare negotiates on the edge and ensures there's no weak link in the chain.

The Result

After making these changes, run your domain through SSL Labs and you should see an A+ rating.

The full checklist:

✅ Minimum TLS version → TLS 1.2
✅ TLS 1.3 → On
✅ HSTS → On (Max-Age 12 months, includeSubDomains, Preload)
✅ Always Use HTTPS → On
✅ Automatic HTTPS Rewrites → On
✅ Certificate Transparency Monitoring → On
✅ SSL/TLS mode → Full (Strict)
✅ Origin server → TLSv1.2 + TLSv1.3 only, strong ciphers

One Thing You Can't Fix on the Free Plan

You might still see some CBC cipher suites in your SSL Labs report under TLS 1.2. These are weaker than the preferred GCM and CHACHA20 ciphers but still considered safe in practice.

On Cloudflare's free plan, you can't customize the edge cipher suite — that requires the Business or Enterprise plan. This won't prevent you from getting an A+, but it's worth knowing about if you're aiming for a theoretically perfect configuration.

Why Bother?

A fair question. Your site works fine with Cloudflare's defaults, and the average user will never notice the difference.

But TLS hardening isn't about showing off a green badge. It's about eliminating known-weak protocols that exist only for backward compatibility with clients that shouldn't be accessing your site anyway. TLS 1.0 has known vulnerabilities (BEAST), and older SSL protocols it often coexists with are vulnerable to POODLE. HSTS prevents SSL stripping attacks. These aren't theoretical risks — they're well-documented attack vectors.

It takes about five minutes to change these settings. There's no performance penalty. The only "cost" is dropping support for Internet Explorer on Windows XP — and that's a feature, not a bug.

Originally on my blog. More stuff on web dev, devops, privacy, LLMs, and self-hosting there.