DEV Community: karthiii13

Self-host Uptime Kuma: a status page in 10 minutes (with real RAM numbers)

karthiii13 — Wed, 07 Oct 2026 10:29:54 +0000

Originally published on FreeTierWatch, where we hand-verify free tiers and actually test the self-hosted apps we write about.

Uptime Kuma is the self-hosted answer to UptimeRobot and Pingdom: a monitoring dashboard that pings your sites, APIs, and databases, and alerts you when they go down. No per-monitor pricing, no 5-minute-interval paywall — your hardware, your rules.

We deployed version 2 from scratch, measured its actual resource usage, and broke a couple of monitors on purpose to see what failure looks like. Everything below is from that run.

What you need

Any machine with Docker — we used a workstation with 30 GB RAM, but our measurements show 256 MB free RAM is plenty
1 GB free disk (the image alone is 574 MB)
5-10 minutes

Docker not installed? On Ubuntu/Debian: curl -fsSL https://get.docker.com | sh

Step 1: the Compose file

Make a directory and drop this in as compose.yaml:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - kuma-data:/app/data
    ports:
      - "3001:3001"
    restart: unless-stopped

volumes:
  kuma-data:

Two deliberate choices here:

Named volume (kuma-data) instead of a bind mount — survives container recreation and avoids the host-permissions mess that bind mounts cause on some systems.
restart: unless-stopped — the container comes back after reboots without systemd units or cron hacks.

Step 2: start it

docker compose up -d

First run pulls the image (574 MB — a minute or two on decent broadband). Then open http://localhost:3001 (or http://<machine-ip>:3001 from another device on your network).

Step 3: database choice (new in v2)

Version 2 asks which database to use before anything else:

Pick SQLite for a homelab. The embedded MariaDB option exists for large installations (hundreds of monitors); for anything under ~50 monitors, SQLite is simpler, uses less RAM, and backs up as a single file. After 2 months with 3 monitors, our SQLite data volume was under 2 MB.

Then create your admin account. Use a real password manager entry — this dashboard knows every URL you care about.

Step 4: add monitors

Add New Monitor → pick a type → paste a URL. We set up three real ones:

Lessons from the two monitors we got wrong on the first try (visible as red in the history — we left them in deliberately):

HTTP-monitoring a private GitHub repo returns 404. The unauthenticated check sees what a logged-out user sees. Monitor something public, or use a keyword/API monitor with a token.
Supabase's REST endpoint returns 401 without an API key — "down" according to an HTTP monitor even though the service is fine. For databases, use a TCP Port monitor instead: ours checks the Postgres pooler on port 5432 and reports ~33 ms from India to Mumbai.

That's the general rule: HTTP monitors for pages, TCP monitors for databases and services that require auth.

What it actually costs to run (measured)

Metric	Measured value
Image size	574 MB
RAM, idle (0 monitors)	143 MB
RAM, 3 active monitors (60s interval)	133–147 MB
CPU, idle	0.02%
CPU, 3 monitors	~0.7–0.9% of one core
Disk (data volume, 3 monitors)	1.4 MB
Restart time (`docker restart`)	1.6 s, serving again in under 10 s

Translation: Uptime Kuma runs comfortably on a Raspberry Pi, a 10-year-old laptop, or the smallest VPS money can buy. RAM is the only number that matters, and it stays well under 200 MB.

Gotchas

The monitor is only as available as the machine it runs on. Our test box is a workstation that isn't on 24/7 — fine for learning, useless for real alerting. See below.
Port 3001 conflicts: if something already listens there, change the left side of the mapping ("3002:3001").
No built-in HTTPS. On a LAN that's fine; exposing it to the internet needs a reverse proxy (Caddy/Traefik/nginx) in front — or better, don't expose it and use Tailscale.
Updates: docker compose pull && docker compose up -d. The named volume keeps your data.

Backups

Everything lives in one volume. Snapshot it with:

docker run --rm -v kuma-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/kuma-backup-$(date +%F).tar.gz -C /data .

Cron that weekly and copy it somewhere that isn't the same disk.

When NOT to self-host this

Your monitoring box isn't always on. A monitor that's offline when your site goes down is theatre. If you don't have an always-on machine, run Uptime Kuma on a free or cheap cloud box — Oracle's Always Free tier fits it with room to spare, or any ~$4-6/mo VPS.
You're monitoring the same machine the monitor runs on. It can't tell you it's down.
You need SMS alerting and SLA reports for a client contract — paid services earn their fee there.

What we actually ran this on

Machine: Intel Core Ultra 7 255H (16 cores), 30 GB RAM, NVMe — massively overkill; see measurements above for what it actually needs
OS: Ubuntu 24.04.5 LTS, x86_64
Docker: 29.8.1, Compose v5.1.3
Uptime Kuma: louislam/uptime-kuma:2 (v2, SQLite backend)
Date: 2026-10-06

Supabase vs Neon: I measured both free Postgres tiers from India

karthiii13 — Wed, 07 Oct 2026 09:56:01 +0000

Originally published on FreeTierWatch, where we hand-verify and track the free tiers of developer services.

If you need a free Postgres database for a new project, you are basically choosing between Supabase and Neon right now. Both offer genuinely free tiers with no credit card. Both run real PostgreSQL.

They solve different problems. Supabase is an all-in-one backend (Postgres plus auth, storage, and edge functions). Neon is pure serverless Postgres focused on branching and scale-to-zero.

We didn't just read the pricing pages — we created a project on each, connected from India, and measured what actually happens. Numbers below are from our own runs on 2026-10-06.

The verdict table

	Supabase (Free)	Neon (Free)
Credit card required	No	No
Postgres storage	500 MB per project (2 projects)	1 GB per project, 20 GB account total
Compute model	Always-on shared instance	Scale-to-zero, 100 CU-hours/project/month
Idle policy	Project paused after 7 days inactivity	Compute suspends after 5 minutes (resumes automatically)
Cold start (measured)	495 ms*	1,242 ms
Hot query from India (measured)	5 ms (Mumbai)	58 ms (Singapore)
India region	Yes — Mumbai `ap-south-1`	No — Singapore closest
Bundled extras	Auth (50k MAU), 1 GB file storage, edge functions	Branching, 60k MAU auth, object storage
Backups	None on free	6-hour restore history (1 GB cap)

* Supabase's free instance doesn't scale to zero on short timescales — our "cold" number is a fresh connection after 6 minutes idle. Its real pause only kicks in after 7 days of inactivity and requires a manual dashboard restore.

How we measured

We created a fresh free project on each platform — Supabase in Mumbai (ap-south-1), Neon in Singapore (ap-southeast-1, its closest region to India) — and ran the same script from a machine in India:

Cold: first connection + SELECT 1 after 6 minutes of idle (beyond Neon's 5-minute suspend)
Warm: 5 fresh connections while compute is up
Hot: 5 queries on an already-open connection

The measurement script is in our repo — run it yourself.

What the numbers mean

Neon pays a real cold-start tax

	cold	warm connect (median)	hot query (median)
Neon (Singapore)	1,242 ms	431 ms	58 ms
Supabase (Mumbai)	495 ms	238 ms	5 ms

Neon's compute suspends after 5 minutes of inactivity — not configurable on the free plan. The next request pays ~1.2 seconds from India. If your app gets a request every few minutes, every one of those users waits. If it gets steady traffic, the compute stays warm and you never notice — but then you're burning through the 100 CU-hour monthly allowance (0.25 CU × 400 hours = the whole month, so steady traffic fits, but background jobs plus traffic may not).

Supabase's free instance is a small always-on server. No suspend cycle, no cold-start tax — until the 7-day pause, which is a different beast entirely: the project stops until you log into the dashboard and restore it by hand.

The 10x latency gap is geography, not engineering

Supabase's 5 ms vs Neon's 58 ms hot-query latency is almost entirely Mumbai vs Singapore round-trip time. Neither platform is "slower" — Neon just has no India region. If your users are in India, that 50+ ms on every single query is a tax you pay forever. If your users are in the US or EU, this flips and you should re-run our script from where your server will live.

Gotcha we hit: Supabase direct connections are IPv6-only

Our first connection attempt to Supabase failed with ENETUNREACH. The direct connection string (db.<ref>.supabase.co) resolves to IPv6 only, and most Indian home ISPs don't route IPv6. Use the session pooler string (<ref>.pooler.supabase.com) — it's IPv4-friendly. If a tutorial just gives you the direct string and you're on IPv4, you'll think the service is down. It isn't.

Verified limits

Supabase free tier

2 active projects, 500 MB Postgres each (including indexes and WAL overhead — usable space is less)
Auth: 50,000 monthly active users
Storage: 1 GB files; egress 5 GB/month; 500K edge function invocations
Paused after 7 days inactivity, restorable from dashboard
No automated backups — if you drop a table, it's gone

Neon free tier

100 projects, 1 GB Postgres each, 20 GB account-wide cap
100 CU-hours compute per project per month; autoscaling up to 2 CU
10 branches per project (database branches work like git branches)
Egress 5 GB/project/month; 6-hour instant-restore history (capped at 1 GB of changes)
Run out of CU-hours mid-month and your compute is suspended until next month — data survives, app goes down
Hit the storage cap and writes start failing until you free space

Note: many posts still cite Neon's old "512 MB per branch" limit. The current official number is 1 GB per project — we verified against Neon's plans doc on 2026-10-06.

Which one should you pick?

Student side project: Supabase. Auth and file uploads out of the box means you ship the actual project instead of wiring JWT handling all weekend. Ping it once a week so it doesn't pause (a free cron from GitHub Actions works).

Indie hacker production app: Neon — if your traffic is sporadic and your users aren't latency-sensitive. Database branching makes migrations genuinely safer: branch, migrate, test, merge. If you use Clerk/Auth0 or your own backend anyway, Supabase's extras are dead weight. But watch the CU-hour budget if you run background jobs.

India-based users: Supabase, and it's not close. 5 ms vs 58 ms on every query, measured. Until Neon opens an India region, physics wins.

When the answer is "pay for neither"

You need predictable latency with zero cold starts and zero pause risk → a $5-6/mo VPS running Postgres in Docker beats both free tiers
Your database is already over 500 MB–1 GB → you're outside both free tiers on day one
You need real backups and point-in-time recovery guarantees → that's a paid feature everywhere

What we actually ran this on

Client machine: Linux x86_64, Node.js 24, pg driver, IPv4-only home connection in India
Supabase project: Mumbai ap-south-1, session pooler connection
Neon project: Singapore ap-southeast-1, pooled connection string, fixed 0.25 CU
Method: 1 cold run after 360 s idle, 5 warm connections, 5 hot queries per service; medians reported
Date: 2026-10-06

The Free Tier Graveyard: every dev free tier that died, 2022-2026

karthiii13 — Tue, 06 Oct 2026 16:35:52 +0000

Originally published on FreeTierWatch, where we hand-verify and track the free tiers of developer services.

Every entry below broke thousands of apps and invalidated thousands of tutorials. Each one is verified against the provider's own announcement — linked, dated, no folklore.

If you build on free tiers, this list is why this site exists.

The timeline of deaths

Date	Service	What died
Nov 28, 2022	Heroku	Free dynos, free Postgres, free Redis — all of it
Aug 2023	Railway	Recurring free tier → one-time $5 trial credit
Feb 2024	Koyeb	$5.50/month free credit → single free instance
Mar 6, 2024	PlanetScale	Hobby plan killed (gone Apr 8, 2024)
Oct 2024	Fly.io	Free allowances removed for new accounts
Jul 8, 2025	Glitch	App hosting shut down entirely
Sep 4, 2025	Netlify	Legacy free tier closed; new accounts get ~15 GB effective bandwidth instead of 100 GB

2022: Heroku — the extinction event

The free tier that taught a generation to deploy. For over a decade, git push heroku main was the first deployment command most developers ever ran.

Salesforce killed free dynos, free Postgres, and free Redis on November 28, 2022, citing "fraud and abuse." Free databases on personal accounts were deleted, not just paused. Inactive accounts were deleted too, starting a month earlier.

What it broke: countless student projects, portfolio apps, Discord bots, and the Nightscout diabetes-monitoring community (big enough that Heroku's own FAQ has a dedicated entry for it).

The lesson that everyone learned the hard way: "free forever" is a pricing decision, and pricing decisions change with ownership. Heroku's free tier died 12 years in — longevity is not a guarantee.

2023: Railway — the quiet conversion

Railway replaced its recurring free tier with a one-time $5 trial credit. Once spent, you pay the $5/month Hobby minimum.

This one still catches people in 2026 because old tutorials never got updated. Our Railway data page exists largely to answer "wait, I thought Railway was free?"

The lesson: a trial credit dressed as a free tier is the most common soft-kill. Check whether the "free" is recurring or one-time before you build.

2024: PlanetScale — profitability, announced plainly

PlanetScale's CEO published "PlanetScale forever" in March 2024: the company was prioritizing profitability, laying off sales/marketing, and retiring the Hobby plan — with one month's notice.

To their credit, it's the most honest free-tier death notice ever written: "We do not need to give away endless amounts of free resources in order to keep growing."

What it broke: thousands of side projects running on free MySQL, with 33 days to migrate.

The lesson: VC-funded generosity is a customer-acquisition expense. When the market turns, it's the first line item cut. The most generous tier on the market is often the most fragile.

2024: Fly.io — the silent sunset

No dramatic blog post here. Fly.io's famous "3 free shared VMs" simply stopped applying to new organizations around October 2024; new signups are pay-as-you-go with a card required.

This is the hardest kind of death to catch: nothing was announced loudly, existing users kept their allowances, and thousands of tutorials continue to describe a free tier that new users can't get. Our Fly.io page tracks the current reality.

The lesson: grandfathering hides the change. The free tier a tutorial author used in 2023 may not exist for you today, even though their app still runs.

2025: Glitch — total shutdown

Glitch didn't shrink its free tier — it stopped hosting apps altogether on July 8, 2025. Projects, profiles, the in-browser editor as a host: gone. Subdomain redirects run through end of 2026 as a courtesy.

What it broke: a decade of creative web experiments, classroom projects, and the lowest-friction "remix and run" culture the web had.

The lesson: sometimes the risk isn't the tier — it's the company. Glitch was beloved and still died. Affection is not a business model.

2025: Netlify — the stealth nerf

Netlify didn't kill anything. It just moved all new accounts to a credit-based plan (300 credits/month) where bandwidth costs 20 credits/GB — an effective ceiling around 15 GB/month, versus the legacy tier's 100 GB. Existing accounts were grandfathered, so most writeups never noticed.

Full numbers on our Netlify page.

The lesson: watch for repricing disguised as "simplification." Credits, units, and tokens usually mean the old number got smaller.

The pattern (and how to predict the next death)

Across all seven deaths, the same warning signs repeat:

Ownership change — Heroku died under Salesforce. Koyeb just joined Mistral AI; Turso is joining Supabase. Acquisitions reset pricing philosophy. We flag these on our data pages the day we see them.
"Fraud and abuse" language in blog posts — the standard prelude to free-tier removal.
Profitability pivots — layoffs + "sustainable business" posts preceded the PlanetScale kill.
A new paid tier appears just below the free tier's capability — the free tier is now cannibalizing revenue; its days are numbered.
Grandfathering begins — "existing users keep X" means X is already dead; it just hasn't reached you yet.

If you're building on a free tier today

Export paths beat free capacity. Prefer services where leaving is one pg_dump away. The Heroku deletion hurt people who had no backup habit.
Treat card-required free tiers as short-term loans. When the tier dies, the card is already on file.
Keep your data layer portable — standard Postgres/MySQL/SQLite, no proprietary APIs you can't re-implement in a weekend.
The boring alternative is immune. A ~$5/month VPS running Docker has no free tier to lose. When you outgrow free, that's the upgrade that can't be rug-pulled.

Every service above has a tracked data page with dated verification. When the next one dies — and the pattern says one will — subscribers hear it first.