DEV Community: Chalom Ellezam

Your indie SaaS has zero working Postgres backups. Here's the 20-minute fix (and the drill you need to run before you sleep tonight).

Chalom Ellezam — Thu, 14 May 2026 08:05:30 +0000

I'm a senior backend tech lead in Paris and I run HostingGuru, a managed PaaS. I'll mention HG exactly once near the end. Everything else in this article works on any platform you ship on.

A founder DMed me last month about a Render Postgres instance that had been humming along for nine months without a hiccup. Stripe charges going through, customers happy, MRR pushing past €4k. He wanted my opinion on something else, but during the call I asked how often his database backed up. He paused, opened the Render dashboard, clicked Postgres, then Backups, and saw exactly one snapshot from the day he provisioned the instance.

This is not rare. I review side projects and small SaaS stacks every week, and "zero working backups" is the single most common operational bug in the deployment of someone who shipped fast and learned to operate later. It's also the cheapest bug in the world to fix. You can wire up a working strategy in twenty minutes. The reason most solo founders don't is that the canonical advice (configure AWS RDS, set up S3 lifecycle policies, write a Lambda, install Datadog) is written for a team of four. So we're skipping all of that.

The lie we tell ourselves about "managed" databases

Almost every managed Postgres provider has a "backups" tab. Render does. Supabase does. Railway does. Neon does. AWS RDS does. People glance at this tab once, see the word "automatic," and assume the problem is solved.

It is not solved, for three reasons.

First, the default retention window on free and hobby tiers is much shorter than founders think. Render's hobby Postgres retains daily snapshots, but only for a few days, and the snapshots stop the moment you exceed plan limits. Supabase free retention covers a single day on the current tier. Neon has branching but no automatic point-in-time recovery on the free plan past 24 hours. None of this is hidden, but I have not yet met an indie founder who has read the fine print on the plan they signed up for in 2024.

Second, "managed" backups are usually stored on the same vendor as your live database. If your account is suspended (billing failure, terms-of-service trigger, a misunderstanding on a 2am support ticket), your backups vanish with the rest of the instance. I have watched this happen twice in two years. Both founders had paying customers. Both lost data they would have paid me five figures to recover. There was nothing to recover.

Third, the restore path is almost never tested. A snapshot you cannot restore from in under fifteen minutes is not a backup. It is hope.

Working backups for a solo founder satisfy three properties: they run automatically, they live somewhere your primary vendor cannot touch, and you have personally restored from them at least once.

What a real backup strategy looks like for a 1-person SaaS

You want three things in place. None of them require a DevOps hire.

A nightly logical dump of your production database, pushed to an external store. "Logical" means pg_dump, not a filesystem snapshot. Logical dumps are slower than snapshots, but they are portable: you can restore them onto any Postgres of compatible major version, on any provider, from any laptop. For a SaaS with a database under 10 GB (which is most indie SaaS in their first two years), this is the right primitive.

A retention policy of at least thirty days, daily. For most products, the urgent question is not "what was the data five minutes ago" (that's what your live database is for). The question is "what did the data look like before the migration I shipped on Tuesday that quietly nuked the users.timezone column." Thirty daily snapshots covers nearly every realistic incident I've seen in fifteen years. If you need point-in-time recovery within seconds, you are past the threshold of this article and you should pay an ops person.

A restore drill, run once, written down. The single most useful operational habit I've ever developed is restoring a backup to a scratch database, running a quick query against it, and timing how long the whole thing took. The first time I did this on a project at koodos labs back in NYC, the restore "worked" but the encoding settings on the receiving instance differed enough that a couple of emoji-heavy columns came back mangled. Better to find that out on a Sunday afternoon than during an incident.

The 4-line cron job that gets you 80% there

Here is the smallest setup that satisfies all three properties. Drop it on any host with cron and pg_dump available, plus credentials to write to one external object store (Backblaze B2, Cloudflare R2, Wasabi, or AWS S3 if you must).

#!/usr/bin/env bash
set -euo pipefail

TS=$(date -u +%Y%m%d-%H%M%S)
FILE="/tmp/backup-${TS}.sql.gz"

pg_dump "$DATABASE_URL" --format=plain --no-owner --no-privileges \
  | gzip -9 > "$FILE"

rclone copyto "$FILE" "b2:my-bucket/postgres/${TS}.sql.gz"

rm "$FILE"

Four substantive lines. Put it in /etc/cron.daily (or your platform's scheduled-jobs feature), set DATABASE_URL and the rclone config in env vars, and you have a daily off-vendor backup. rclone is one binary, no dependencies, and it talks to virtually every cloud storage provider with the same syntax.

For retention, give the bucket a lifecycle rule: keep objects for 30 days, then delete. Cloudflare R2 and Backblaze B2 both have these in their UI under "Bucket settings." You don't need to write code for the rotation, just configure it once.

What this setup does not do: it does not protect you against a backup that is silently broken (a dump that says "succeeded" but is missing tables because of a permission issue, or a gzip that truncated because the disk filled up). The simplest defense is a size sanity check. If today's compressed dump is dramatically smaller than yesterday's, something is wrong, and you want a Telegram message before you find out the hard way.

Here is the version I actually use, which adds that check.

#!/usr/bin/env bash
set -euo pipefail

TS=$(date -u +%Y%m%d-%H%M%S)
FILE="/tmp/backup-${TS}.sql.gz"
LAST_SIZE_FILE="/var/lib/backups/last-size"

pg_dump "$DATABASE_URL" --format=plain --no-owner --no-privileges \
  | gzip -9 > "$FILE"

SIZE=$(stat -c%s "$FILE")
LAST=$(cat "$LAST_SIZE_FILE" 2>/dev/null || echo "$SIZE")
RATIO=$(awk -v a="$SIZE" -v b="$LAST" 'BEGIN{print a/b}')

if awk "BEGIN {exit !($RATIO < 0.8)}"; then
  curl -s "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" \
    -d chat_id="${TG_CHAT}" \
    -d text="Backup shrank to ${RATIO}x of yesterday. Investigate."
fi

echo "$SIZE" > "$LAST_SIZE_FILE"
rclone copyto "$FILE" "b2:my-bucket/postgres/${TS}.sql.gz"
rm "$FILE"

If you don't have Telegram alerting wired up yet, see article #4 in this series. The Telegram piece takes five minutes and is the thing I'd put on every project before I'd install Sentry.

A note for the Postgres pedants: --format=plain is intentional. Custom format (-Fc) is faster and smaller, and pg_restore is more flexible against it, but plain SQL is human-readable. I have personally done a partial restore by opening a backup in vim and copying out the rows I needed. You will not regret choosing plain text the first time you need it.

Restoring is the test you actually need to run

This is the step almost everyone skips. It is the step that turns "I have backups" into "I have working backups." They are not the same thing.

Once a quarter, do this:

# 1. Pull yesterday's backup down
rclone copyto b2:my-bucket/postgres/<yesterday>.sql.gz /tmp/restore.sql.gz

# 2. Spin up a scratch Postgres locally
docker run -d --name scratch-pg \
  -e POSTGRES_PASSWORD=test \
  -p 5433:5432 \
  postgres:16

# 3. Restore
gunzip -c /tmp/restore.sql.gz | psql -h localhost -p 5433 -U postgres -d postgres

# 4. Sanity-check a row count
psql -h localhost -p 5433 -U postgres -d postgres \
  -c "select count(*) from users;"

Time it. Write the elapsed minutes down. The number you want in your head is your recovery time: how long from "database is gone" to "product is back up." For most indie SaaS the answer should be under an hour, and most of that should be data transfer. If it takes you four hours to figure out how to restore, your backups are doing less for you than you think.

The first time you run this drill, you will hit one of these problems. The dump is missing a schema you didn't know about (Postgres has public plus often a pg_catalog, plus extension schemas like pgvector or pg_trgm). The Postgres major versions are incompatible because you upgraded the live instance and forgot the dump tooling. The gunzip produces a corrupted file because last night's S3 upload timed out and you only stored the truncated piece. The role definitions clash because you used --no-owner but a function depends on a specific role.

Every one of those is easier to debug on a Sunday afternoon than at 3am during an incident.

The three mistakes I see every single week

The first is using only the vendor's built-in backups. We covered this above. If your provider's account suspends, your billing card expires, or the region has a bad day, the backups go with the database. Off-vendor storage is not optional.

The second is backing up only the database. Indie SaaS often has uploaded user files (avatars, generated PDFs, CSV exports, AI-generated images) sitting on the same disk as the app, or in the vendor's local volume. If you are already using S3-compatible object storage for uploads, you are fine: those buckets have their own durability and you can mirror them with rclone sync on the same schedule as your DB. If you are storing uploads on the dyno's local disk, you have unbacked-up state, and the day the dyno is recycled you discover this. Move that to object storage first.

The third is the one I want to spend a paragraph on, because it bites people who think they did everything right. If your app stores PII encrypted at the column level (which it should, especially under GDPR), the database dump is useless without the encryption key. The key lives in an env var or a secrets manager. Back that up too. Store it separately, in a password manager or a dedicated secrets vault, and write down the recovery procedure. I lost an afternoon to this exact configuration drift on a client project a few years ago. The database came back fine and we still couldn't read half the columns.

What I built

I run HostingGuru because I spent fifteen years (Oney, BeReal, Ringover, koodos labs, agency contracts) writing variations of the cron above for every new project. At some point I got tired of rebuilding the same scaffolding and shipped a managed PaaS where daily off-vendor Postgres backups, encrypted env vars, and AI-driven Telegram alerts (including the "your backup shrank" pattern from above) are part of the default experience. EU and US data centers, GDPR, ISO 27001, the routine. The free tier doesn't sleep. That's the only mention you'll get. Everything in this article works on Render, Railway, Fly.io, Supabase, a raw VPS, or your own Kubernetes cluster.

What to do tonight regardless of which platform you use

Five steps, in order. Block off an hour.

Step one. Pull your live database with pg_dump from your laptop right now. Time it. If you can do it at all, you have a baseline. If you cannot (credentials are wrong, network rules block you, you've forgotten the password to the live DB role), fix that first. You need this skill to exist before you automate anything.

Step two. Create a bucket on Backblaze B2 or Cloudflare R2. Both have free tiers that cover a 10 GB SaaS for years. Generate an access key, store it in your password manager, and verify you can rclone copyto a test file into it.

Step three. Wire up the cron script from this article. Put it on whatever scheduler your platform exposes (Render scheduled jobs, Fly cron, GitHub Actions on a schedule:, your PaaS's on-demand script feature, or a /etc/cron.daily entry on a VPS). Run it once manually. Confirm the file lands in the bucket.

Step four. Set a lifecycle rule on the bucket: retain for 30 days, delete after. This step takes 90 seconds in the B2 or R2 UI. Without it, you'll pay for storage forever and the bucket will become a haystack.

Step five. Block off ninety minutes next weekend for the restore drill. Restore yesterday's dump to a scratch Postgres, run a row-count query, write down the elapsed time. That number is your recovery time objective. Now you can answer the customer who asks "what happens if you lose my data" without lying.

If you only do step one tonight, you've already moved the needle. Most founders haven't.

One question

I'd be curious from anyone reading: have you ever actually restored from a backup in production, not as a drill but because something went wrong? What broke in the restore that you didn't expect? The interesting failure modes are not in the docs, and I'd love to read them in the comments.

Previous posts in this series:

Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep.
I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.
Your AI app is silently burning $2,000/month and you don't know it. Here are the 5 patterns that bite founders.
Telegram alerts for any production app: a 5-minute setup (no SaaS, no signup, just curl)
How I built a Discord 'ship-tracker' bot in a weekend (and the 3-process architecture that keeps it alive 24/7)
I migrated 12 client projects off Heroku. Here's the playbook (and the 7 things that bit me every single time).
The Claude Code → production checklist: 15 things that aren't obvious until they bite you

The Claude Code production checklist: 15 things that aren't obvious until they bite you

Chalom Ellezam — Tue, 12 May 2026 12:14:16 +0000

Disclosure: I'm a senior backend tech lead and I run HostingGuru. This list applies to any platform; HostingGuru happens to handle a few of these for you automatically, which I'll flag honestly when relevant.

I've helped about a dozen non-technical founders take their first Claude Code MVP from localhost:3000 to a real production URL in the last six months. They are much better at shipping than the same founders would have been two years ago.

But the same 15 things keep biting them in the first two weeks after launch. Almost none of these are about the code being wrong. They are about production being a different environment with its own rules, rules nobody warned anyone about because everyone assumed you already knew them.

This is the checklist I now send to every founder before they go live. If you went live in the last 30 days and didn't go through it, you almost certainly have at least four of these issues right now.

1. Your `.env` file is in your git history

Even if your current code has .env in .gitignore, check git history:

git log --all --full-history -- .env
git log --all --full-history -- .env.local

If anything shows up, your API keys were exposed at some point. They are still exposed, because git history is forever. Rotate every key in that file. Today. Yes, even if the repo is private. Future you who makes the repo public for an open-source moment will thank present you.

2. You have one set of API keys for dev and prod

Same OPENAI_API_KEY, same STRIPE_SECRET_KEY, same SENDGRID_API_KEY in your laptop and on the production server. The first time you accidentally run a test script that fires 500 emails or charges 200 cards, you'll wish you had a *_DEV and a *_PROD. Make separate keys per environment. Today.

3. Your Stripe webhook is unsigned

When Stripe POSTs to /api/webhooks/stripe, you should verify the signature header before trusting the payload. If your code just reads req.body.amount and credits the user's account, anyone on the internet can hit that URL with fake events and give themselves credits.

The fix is three lines:

const sig = req.headers['stripe-signature'];
const event = stripe.webhooks.constructEvent(req.rawBody, sig, process.env.STRIPE_WEBHOOK_SECRET);
// Now use event.type, event.data — verified.

Required reading: Stripe's webhook signature docs.

4. You're using Stripe test keys in production

Your STRIPE_SECRET_KEY starts with sk_test_... instead of sk_live_.... Real payments hit Stripe's test environment, which... doesn't charge anybody. You launch, you celebrate the first sale, three days later you realize Stripe has $0 from you.

Same with STRIPE_PUBLISHABLE_KEY and the frontend pk_test_* vs pk_live_*. Match them. Double-check after every deploy in the first week.

5. Your database has no backup strategy

"I'll set up backups later" is a sentence I have heard about 100 times. Approximately zero of those people set up backups later. Then someone (often Claude) runs a migration that drops a table, and the conversation is over.

Most managed databases (Supabase, Neon, managed Postgres on any PaaS) have automatic daily backups built in but only if you turn it on. Click around your database dashboard now. If you don't see "Backups enabled," fix it before reading item 6.

For self-hosted: pg_dump to S3 / Cloudflare R2 nightly via a cron. Test the restore. Once. The 5 minutes you spend testing is the difference between "we recovered" and "we lost everything."

6. You have no rate limiting on AI endpoints

You have a /api/chat route that calls OpenAI. Someone (a scraper, a bored teen, your competitor) discovers it and hits it in a for loop. By the time you notice, your OpenAI bill is up by $400 and the abuser has stopped.

Even a stupid rate limit is much better than no rate limit:

// Crude but works
const ipHits = new Map();
app.post('/api/chat', (req, res) => {
  const ip = req.ip;
  const now = Date.now();
  const hits = ipHits.get(ip) || [];
  const recentHits = hits.filter(t => now - t < 60_000);
  if (recentHits.length >= 10) return res.status(429).send('slow down');
  recentHits.push(now);
  ipHits.set(ip, recentHits);
  // ... your real handler
});

10 calls/minute per IP. Most legitimate users won't hit it. Most abusers will. For real production, use a library (express-rate-limit, slowapi, etc.) with Redis-backed counters.

7. CORS is wide open

You have Access-Control-Allow-Origin: * in your headers or cors({ origin: '*' }) in your Express setup. For a public read-only API, fine. For anything with auth, this means any random website can make authenticated requests as your logged-in users.

Set origin to your specific frontend domain. If you need both https://yourapp.com and https://www.yourapp.com, use an allowlist:

const allowed = ['https://yourapp.com', 'https://www.yourapp.com'];
app.use(cors({ origin: (origin, cb) => cb(null, !origin || allowed.includes(origin)) }));

8. You haven't set up error tracking

Sentry takes 25 minutes to install. Until you have it:

Your users find bugs before you do
You spend hours guessing what broke from screenshots
You miss the bugs that don't generate user complaints (and there are a lot of those)

Install it tonight. Free tier covers 5K errors/month, plenty for any startup under 10K users.

npm install --save @sentry/nextjs   # or @sentry/node, @sentry/python, etc.
npx @sentry/wizard -i nextjs        # follows a guided setup

9. Your app ships source maps to production

Source maps make stack traces readable, but if they're served publicly, anyone can open Chrome DevTools and read your original (TypeScript / unminified) code. This includes your API logic, your prompts to OpenAI, your business rules.

For Next.js:

// next.config.js
module.exports = {
  productionBrowserSourceMaps: false,
};

Upload source maps to Sentry instead (so YOU can debug stack traces) and exclude them from the public bundle.

10. You have no `/healthz` endpoint

Most hosting platforms periodically ping a health endpoint to know if your app is alive. If you don't have one, the platform pings your homepage, which loads your full app stack including AI calls, which is slow and expensive.

Add one line:

app.get('/healthz', (_req, res) => res.status(200).send('ok'));

Configure your hosting platform's health check to point at /healthz. Cheap, fast, useful.

11. Your DNS TTL is too high

Most domain registrars default to a 24-hour or 4-hour TTL (Time To Live) on DNS records. This means when you change your domain to point at a new host, browsers and ISPs cache the old DNS for up to 24 hours.

Before any DNS migration, log into your registrar (Namecheap, OVH, Cloudflare) and set TTL to 300 seconds (5 minutes). Wait one TTL period. Then make your changes. Propagation will be minutes, not hours.

Do this before you need to migrate, not the day of.

12. Your runtime version isn't pinned

Claude Code generates code targeting whatever Node / Python / Ruby version it's currently aware of (often the latest). Your hosting platform might run an older default. Result: subtle bugs that work on your laptop and break in prod.

For Node, in your package.json:

{
  "engines": {
    "node": "20.x"
  }
}

For Python, create runtime.txt:

python-3.11.7

For Ruby, .ruby-version:

3.2.2

Pin once. Forget about it. Your future self never debugs "works on my laptop" again.

13. Server secrets are in your frontend bundle

In Next.js, environment variables prefixed with NEXT_PUBLIC_ are sent to the browser. If you accidentally name your server secret NEXT_PUBLIC_STRIPE_SECRET_KEY, you have just published it to every user's Chrome.

Rule:

NEXT_PUBLIC_* → safe for the browser (analytics IDs, Stripe publishable keys, feature flags)
Any actual secret → no prefix. Server-only.

Same idea in Vite (VITE_*), Create React App (REACT_APP_*), Astro, etc. Audit your .env for any "PUBLIC" variable that shouldn't be.

14. You have no monitoring on cron jobs

You set up a nightly job at 0 3 * * *. It worked for the first three days. It hasn't run in two weeks because of a node_modules issue you didn't notice. You only realize when you check the database and see no new data.

Two ways to know your crons are running:

Easy way: every cron pings a service like healthchecks.io (free for solo use). If the ping doesn't arrive within the expected window, it emails you.

0 3 * * * /opt/myapp/nightly.sh && curl -fsS -m 10 https://hc-ping.com/<uuid>

Harder way: hosted platforms with built-in cron observability. HostingGuru does this via its AI monitoring layer (more on that at the end). Render and Railway expose cron logs but you have to remember to look.

15. Your app crashes silently on startup, restarts forever

A crash on boot looks like this: your platform starts your container, your app throws an uncaught exception within 2 seconds, platform restarts, repeat. Externally, your domain just returns 503s.

If you don't have a process.on('uncaughtException') handler that logs to your error tracker AND alerts you on Telegram/Slack/email, this can go on for hours before you notice.

Minimum viable setup:

process.on('uncaughtException', (err) => {
  console.error('FATAL:', err);
  // Optionally: send to Sentry, post to Telegram, etc.
  process.exit(1); // let the platform restart cleanly
});

Then make sure your hosting platform's health check is configured (item 10), so when crashes happen it actually stops trying to restart endlessly.

The faster path through this list

Some of these are handled for you on managed PaaS platforms:

HostingGuru (full disclosure: I build it): encrypted env vars (so item 13's blast radius is smaller if you misname), AI-monitored crash loops (so item 15 pings you on Telegram automatically), built-in cron job monitoring with the same Telegram alert (item 14). The list of what you still need to do yourself remains long though: items 1–4 (key hygiene), 5 (backups), 6–7 (rate limiting + CORS), 9 (source maps), 11 (DNS), 12 (runtime pinning). The platform can't fix code-level decisions.
Render / Railway / Fly.io: similar pattern. Some items (env vars in dashboard, basic process restart logic) are handled. The code-level items remain yours.
VPS + Coolify or Dokku: you handle all 15 yourself. That's fine if you have the time and discipline. Most solo founders don't.

The right move is: pick a platform that handles a few of these so you can focus on the rest, then actually go through the rest.

What to do tonight, in order

Run git log -- .env (item 1) — 30 seconds. If anything appears, rotate keys immediately.
Check your Stripe key prefix (item 4) — 10 seconds. echo $STRIPE_SECRET_KEY | head -c 10. Should be sk_live_... in prod.
Add /healthz endpoint (item 10) — 2 minutes.
Add an uncaughtException handler (item 15) — 5 minutes.
Verify your database has backups enabled (item 5) — 2 minutes in your DB dashboard.

That's 10 minutes for the five most critical items. The other 10 you can do over the week.

If you build with Claude Code, this list is also a useful prompt: "Audit my repo against the following 15 items..." Claude will go through each one and tell you which apply, which don't, and give you a fix for the ones that do. It catches most of them. The audit takes maybe 15 minutes total.

What's the most embarrassing thing you've shipped to production that this list would have caught? I'm collecting horror stories for v2.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it.

4. Telegram alerts for any production app — a 5-minute setup.

5. How I built a Discord 'ship-tracker' bot in a weekend.

6. I migrated 12 client projects off Heroku. Here's the playbook.

I migrated 12 client projects off Heroku. Here's the playbook (and the 7 things that bit me every single time).

Chalom Ellezam — Mon, 11 May 2026 13:18:26 +0000

Disclosure: I'm a senior backend tech lead and I run HostingGuru. Six of these 12 migrations landed on HostingGuru. The other six went to Render, Railway, Fly.io, or back to a VPS. The playbook below works regardless of destination — it's the Heroku-side problems I want you to skip.

Since Heroku announced "sustaining engineering mode" in February 2026, I've been the person clients call when they need to get off the platform without breaking production. As of this week I've done 12 migrations — Rails apps, Django apps, Node services, Python workers — for clients ranging from 200-MAU side projects to 80K-MAU consumer apps.

If you're staring at your Heroku dashboard wondering when to leave, this is the post I wish someone had written before I started doing these.

It's two parts: the playbook (the order of operations that works), and the 7 things that bit me (the stuff nobody warns you about until you hit it at 11pm on launch night).

Part 1 — The playbook

Every migration I've done follows the same eight-step order. I've tried shuffling it. The shuffling always costs me. Just do it in this order.

Step 0: Decide the destination first

Don't start migrating until you know where you're going. Each destination changes step 4 and step 7 significantly.

Render: closest to old Heroku ergonomics, web service sleeps on free tier, Postgres is solid
Railway: best DX for small projects, usage-based pricing surprises at scale, Postgres reliability has been variable
Fly.io: best if you need multi-region, requires a fly.toml file
HostingGuru: managed PaaS, EU + US, AI monitoring built in, predictable pricing
AWS / GCP: only if you have a real DevOps person on the team
VPS + Coolify/Dokku: cheapest, you maintain the server

For the rest of this playbook I'll be platform-agnostic except where it matters.

Step 1: Inventory what's actually running

Before touching anything, list every dyno, every add-on, every config var, every scheduled job.

heroku ps --app yourapp        # web + worker dynos
heroku addons --app yourapp     # databases, redis, monitoring, etc.
heroku config --app yourapp     # env vars (don't paste this in Slack)
heroku features --app yourapp   # any legacy/labs features still on
heroku scheduler:jobs --app yourapp  # if using Heroku Scheduler

Pipe these into a markdown file in your repo (MIGRATION.md). You will need to refer to it 6 times.

Step 2: Provision the destination

On the new platform, create everything that needs to exist before the cutover:

The web service (don't deploy real code yet — a placeholder is fine)
Workers if you have them
Database (always Postgres for me; we'll cover the dump-restore in step 5)
Redis if you have Sidekiq/BullMQ
Object storage if you use S3-equivalent
Any external API webhooks (you'll need to update their target URLs in step 7)

Goal at end of step 2: every "thing" exists on the new side, empty.

Step 3: Copy env vars carefully

This is where every migration gets a paper cut. Heroku's heroku config output looks like this:

DATABASE_URL: postgres://user:pass@host:5432/db?sslmode=require
REDIS_URL:    redis://...
RAILS_MASTER_KEY: ...
STRIPE_SECRET_KEY: sk_live_...

Three things to watch:

DATABASE_URL will need to change to the new DB's URL. Don't paste the Heroku one.
Watch the trailing ?sslmode=require — this is the #1 silent migration killer (more on this in Part 2).
Heroku auto-generates PORT for you; on most platforms you do too, so don't manually copy it.

Step 4: Deploy code to the new platform — get "hello world" working

Push your code to the new platform. Don't migrate the database yet. Just confirm the platform can build your code and your /healthz endpoint returns 200.

If you have a deploy config file (render.yaml, fly.toml, hostingguru.yml, whatever), put it in your repo BEFORE the migration and merge it. Don't be discovering it works at 11pm.

Step 5: Database migration (the scary part)

Backup → restore. The commands are basically the same on every platform:

# From Heroku
heroku pg:backups:capture --app yourapp
heroku pg:backups:download --app yourapp --output /tmp/dump.tar

# To new platform (psql connection details from the new DB)
psql -h NEW_HOST -p NEW_PORT -U NEW_USER -d NEW_DB \
  -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public;"

pg_restore --verbose --no-owner --no-acl \
  -h NEW_HOST -p NEW_PORT -U NEW_USER -d NEW_DB /tmp/dump.tar

Then verify with row counts, every single table:

SELECT 'users' AS table_name, COUNT(*) FROM users
UNION ALL SELECT 'posts', COUNT(*) FROM posts
UNION ALL SELECT 'orders', COUNT(*) FROM orders;

Compare to Heroku. If anything mismatches, stop, investigate, don't proceed.

Step 6: Put Heroku in maintenance mode + flip DNS

heroku maintenance:on --app yourapp
# users see a "we'll be back" page

Then update your DNS provider (Namecheap, OVH, whatever) to point at the new host. Set TTL low (300 seconds) before this if you remember — DNS propagation will go faster.

Step 7: Final dump + restore

Yes, dump the database again. Heroku has been writing data for the last few hours while you set up. Do a fresh capture, restore on the new side. Then row-count verify again.

Yes, this means downtime equal to the dump-restore time. For most apps under 5GB, this is 5–15 minutes. Schedule the migration window.

Step 8: Reroute external webhooks, then drop maintenance mode

Anything that calls into your app from outside needs its target URL updated to the new host:

Stripe webhooks
SendGrid event webhooks
OAuth callback URLs (Google, GitHub, Slack)
Custom integrations
Cron jobs hitting your /api/... endpoints from external services

Then heroku maintenance:off. Then watch your logs for 10 minutes straight. If the logs are quiet and your /healthz is green, you're done.

Part 2 — The 7 things that bit me

This is the part nobody warns you about. Every one of these has cost me at least 45 minutes of debugging at least once.

Bite 1: The `heroku_ext` schema doesn't exist anywhere else

Heroku installs Postgres extensions in a special heroku_ext schema (not public). When you pg_restore to a non-Heroku Postgres, the restore tries to install extensions in heroku_ext and fails:

pg_restore: error: could not execute query: ERROR:  schema "heroku_ext" does not exist

The restore often appears to complete despite the error, but the extensions (uuid-ossp, unaccent, pg_trgm, etc.) aren't installed. Then your app boots and gets a function uuid_generate_v4() does not exist 500 error in production.

Fix: after restore, recreate the extensions manually:

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "unaccent";
CREATE EXTENSION IF NOT EXISTS "pg_trgm";

List of likely-needed extensions: heroku pg:psql --app yourapp -c "SELECT extname FROM pg_extension;" before you migrate.

Bite 2: `pg_stat_statements` is enabled by default on Heroku, often not elsewhere

If you have any internal slow-query monitoring (e.g. PgHero, a custom admin dashboard), it queries pg_stat_statements. On the new platform this extension is often not enabled by default. Your slow-query dashboard silently shows zero queries.

Fix: enable it on the new platform. On Render/Railway/HostingGuru it's a one-line config flag. On a VPS with your own Postgres, edit postgresql.conf:

shared_preload_libraries = 'pg_stat_statements'

Then CREATE EXTENSION pg_stat_statements;.

Bite 3: Heroku's `DATABASE_URL` bakes in `sslmode=require`

Heroku's connection string format always includes ?sslmode=require. Most apps rely on this being implicit. When you move, some platforms don't add it by default, and your Rails / Django / Node app starts logging cryptic SSL errors at higher load (when the connection pool churns):

PG::ConnectionBad: SSL connection has been closed unexpectedly

Fix: explicitly add ?sslmode=require to your new DATABASE_URL. Or set PGSSLMODE=require as an env var. Diff the connection strings character-by-character before flipping traffic.

Bite 4: Scheduled jobs run on different time zones

Heroku Scheduler runs jobs in UTC. Some platforms default to UTC, some default to the platform's region timezone, some default to whatever timezone the cron entry doesn't specify.

If you have a 0 9 * * * job that ran at 9am UTC on Heroku, and you migrate to a platform that interprets it as 9am local-time-of-some-California-datacenter, your "daily report at 9am Paris time" now runs at 6pm.

Fix: always explicitly check the new platform's cron timezone before migrating. Most modern platforms (Render, Railway, HostingGuru) are UTC. AWS EventBridge defaults to UTC. Older or self-hosted setups vary.

Bite 5: Heroku's `DYNO` env var doesn't exist anywhere else

Heroku sets DYNO=web.1 or DYNO=worker.1 automatically. Some apps use this to determine "am I a web process or a worker?" so they can skip certain initialization. After migration, DYNO is unset, and your worker process tries to bind to a port (because the "am I web?" check defaults to true).

Fix: grep your codebase for process.env.DYNO, ENV["DYNO"], os.environ.get('DYNO'). Replace with explicit env vars you set per process (PROCESS_TYPE=web vs worker).

Bite 6: Heroku Postgres "follower" replicas don't survive

If you used Heroku Postgres followers (read replicas) for analytics queries, those don't migrate. The new platform may or may not have a managed replica option, and the connection string format is always different.

Fix: if you don't use the replica heavily, just point all queries at primary for the first week post-migration. Then add a replica on the new platform if needed. Don't try to bring the replica online during the migration itself.

Bite 7: Buildpacks vs Docker — your build will behave subtly differently

Heroku auto-detects your stack via buildpacks (e.g. heroku/python, heroku/ruby). Some new platforms also use buildpacks (Render uses Nixpacks, Railway uses Nixpacks). Some require a Dockerfile.

Even when both use buildpacks, the specific buildpack version differs. I've seen the same requirements.txt install Python 3.11.7 on Heroku and Python 3.12.1 on Render — and then a library breaks because Python 3.12 deprecated something.

Fix: pin your runtime version explicitly. For Python, that's a .python-version or runtime.txt. For Ruby, that's .ruby-version. For Node, that's "engines": { "node": "20.11.x" } in package.json.

The full migration timeline I quote clients

For a "small to medium" Rails or Django app (1 web service, 1 worker, 1 Postgres < 5GB, < 20 env vars):

Step 0 (decide destination): 1–3 days (mostly waiting for client approval)
Step 1–4 (prep): half a day of focused work
Step 5 (DB migration dry-run): 1 hour
Step 6–8 (cutover window): 30–60 minutes with the team on standby

Total: roughly 2–3 hours of execution time in a 1-week calendar window. The week is for sanity, not because the work takes that long.

If anyone quotes you "we'll migrate Heroku in 30 minutes," they haven't done it. There's always something you didn't expect — most often one of the 7 bites above.

What I'd do if I were migrating today

Run the inventory (heroku ps, addons, config, scheduler:jobs) and put it in a markdown file today. You'll need it whether you migrate this month or in 6 months.
Pick a destination that fits your team's operational maturity. If you don't have a DevOps person, pick a managed PaaS. If you have someone who already runs Kubernetes, you have more options.
Pin your runtime versions in your repo before the migration. This is the cheapest insurance policy.
Do one dry run of the database migration to a throwaway DB on the new platform. Verify row counts. Then do the real one later.
Schedule the cutover for a Tuesday or Wednesday morning, not a Friday. If something breaks, you want a full work week to fix it.

A note on the platform I run

If you're picking a destination and you want one that ships with the operational stuff (Telegram alerts, log-pattern detection, EU data center, predictable pricing), HostingGuru is built around exactly that. Pro tier is €35/mo for 10 services with workers and on-demand scripts included (the same primitives Heroku had with worker: dynos and Heroku Scheduler). Free tier never sleeps.

If you pick another destination, the playbook above still applies — just translate "step 4: deploy code" to whatever that platform's deploy flow is.

Closing

Heroku is in maintenance mode, not gone. Your app will keep working there. But every month you delay migrating, you're betting that nothing breaks on a platform that's stopped investing in fixing things. That's not crazy in 2026. It just gets less crazy with time, not more.

Whenever you do migrate, the order of operations matters more than which destination you pick. Pick the order. Execute Tuesday morning. Watch the logs for 10 minutes. Then take Wednesday off — you've earned it.

What's the dumbest thing that broke during your migration? I'm collecting these for v2 of this post.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it.

4. Telegram alerts for any production app — a 5-minute setup.

5. How I built a Discord 'ship-tracker' bot in a weekend.

How I built a Discord 'ship-tracker' bot in a weekend (and the 3-process architecture that keeps it alive 24/7)

Chalom Ellezam — Fri, 08 May 2026 17:54:27 +0000

Disclosure: I'm a senior backend tech lead and I run HostingGuru. This bot runs on HostingGuru's Pro tier — but the architecture (web service + worker + scheduled job) works on any platform that supports those three primitives. I'll point out where each piece runs.

I co-run a small Discord community for indie founders building dev tools. About 220 members, mostly early-stage SaaS people, lots of Claude Code / Cursor enthusiasts. Every Monday I used to manually scroll through the previous week's #i-shipped channel and write a digest message: "this week we shipped X, Y, Z."

It took 30 minutes every Monday morning. After 5 weeks of it I did the math — 30 min × 52 weeks = 26 hours a year of me doing what a bot could do better. So one Saturday I built ShipTrack, the bot that's been keeping my Mondays free for 6 months now.

This is the build log. It's mostly about an architecture decision (3 separate processes instead of 1) that turned out to be the difference between "bot keeps crashing" and "bot just works."

What the bot does

Three things, in order of complexity:

Listens for the /ship slash command. When a member runs /ship "Launched my AI todo app — feedback welcome: link.com", the bot logs the launch into a database and reacts with 🚀 in the channel.
Tracks #i-shipped channel messages. When anyone posts in that channel (without slash command), the bot detects launch-shaped content (heuristic: contains a URL + at least one of "shipped", "launched", "live"), logs it, reacts.
Posts a weekly digest every Monday at 9am UTC. The bot pulls all launches from the last 7 days, formats them into a nice list, and posts it to #announcements with @-mentions of the founders.

That's it. Three things. But they map to three completely different kinds of computation, which is where v1 went wrong.

v1: the naive setup that crashed in 15 minutes

I started simple. One Node.js file. node bot.js. Deploy to a Render free web service. Done in 30 minutes.

It worked on my laptop. It worked for the first 14 minutes after deploy. Then Render's free tier put the service to sleep due to no incoming HTTP traffic — and a Discord bot doesn't get HTTP traffic by default. It maintains a long-lived WebSocket connection to Discord's gateway. Render couldn't see that traffic. To Render, my bot was idle. So Render killed it.

When the bot came back from sleep 30 seconds later, it tried to reconnect to Discord's gateway. Discord saw two sessions for the same bot. The old session got disconnected with a 4008 Reconnect and the new one inherited some weird state. Members started seeing the bot react to messages twice. Slash commands timed out.

This is the kind of bug that takes a long time to diagnose if you've never seen it before, because everything looks fine in your logs. There's no error, just slightly wrong behavior. I wasted 4 hours.

Why Discord bots are weirder than they look

The thing nobody tells you when you start: a Discord bot has two completely different communication channels with Discord's servers, and they have totally different operational requirements.

Channel 1: the gateway (WebSocket, persistent).

The bot opens a WebSocket to wss://gateway.discord.gg
Stays open forever
Receives every event in real time (member joined, message posted, reaction added)
Sends heartbeats every 41.25 seconds
If the connection drops for >60 seconds, you have to fully re-authenticate and resync state

Channel 2: slash commands (HTTP, on-demand).

Discord POSTs to YOUR endpoint when a user runs a slash command
You have 3 seconds to respond or Discord shows "interaction failed" to the user
Public HTTP endpoint with signed payload verification

These two channels don't fit on the same kind of host. The gateway needs always-on. The slash command webhook needs public HTTPS that wakes up fast. Most "deploy your Node app" flows assume one or the other, not both.

v2: three processes, three responsibilities

The architecture I landed on has three pieces:

┌──────────────────────┐    ┌──────────────────────┐    ┌──────────────────────┐
│  WEB SERVICE          │   │  WORKER               │   │  SCHEDULED SCRIPT     │
│  HTTPS endpoint       │   │  Always-on process    │   │  Runs Monday 9am UTC  │
│  Slash command webhook│   │  Discord gateway      │   │  Generates weekly     │
│  /api/discord/interact│   │  WebSocket connection │   │  digest               │
└──────────────────────┘    └──────────────────────┘    └──────────────────────┘
              │                         │                          │
              └─────────────────────────┴──────────────────────────┘
                                        │
                                ┌──────────────┐
                                │  Postgres    │
                                │  (launches)  │
                                └──────────────┘

Three separate deployments, one shared database. Each process does what it's good at and nothing else.

Process 1: the web service (slash commands)

This is a tiny Express app. One endpoint. Returns under 1 second.

// web-service/server.js
import express from 'express';
import { verifyKey } from 'discord-interactions';
import { db } from './db.js';

const app = express();
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf; }
}));

app.post('/api/discord/interact', async (req, res) => {
  // 1. Verify Discord signed the request
  const signature = req.get('X-Signature-Ed25519');
  const timestamp = req.get('X-Signature-Timestamp');
  const valid = verifyKey(req.rawBody, signature, timestamp, process.env.DISCORD_PUBLIC_KEY);
  if (!valid) return res.status(401).send('invalid signature');

  // 2. Discord sometimes pings to check liveness
  if (req.body.type === 1) return res.json({ type: 1 });

  // 3. Slash command — log the launch and respond fast
  if (req.body.type === 2 && req.body.data?.name === 'ship') {
    const userId = req.body.member.user.id;
    const username = req.body.member.user.username;
    const text = req.body.data.options?.[0]?.value || '';

    await db.launches.insert({
      user_id: userId,
      username,
      text,
      channel_id: req.body.channel_id,
      created_at: new Date(),
    });

    return res.json({
      type: 4,
      data: { content: `🚀 Logged your ship, ${username}!` },
    });
  }

  res.json({ type: 4, data: { content: 'Unknown command' } });
});

app.listen(process.env.PORT || 3000);

Deploy this as a normal web service. It can sleep on free tiers — Discord sends a request only when someone runs /ship, and 1 second of cold start before responding is fine. (For HostingGuru, I picked the Hobby tier with the always-on free guarantee anyway, but the architecture works either way.)

Process 2: the worker (gateway + reactions)

This is the long-running part. It opens the WebSocket connection to Discord and listens for messages. It can't sleep. Ever.

// worker/bot.js
import { Client, GatewayIntentBits, Events } from 'discord.js';
import { db } from './db.js';

const client = new Client({
  intents: [
    GatewayIntentBits.Guilds,
    GatewayIntentBits.GuildMessages,
    GatewayIntentBits.MessageContent,
  ],
});

const SHIPPED_CHANNEL_ID = process.env.SHIPPED_CHANNEL_ID;

client.on(Events.MessageCreate, async (msg) => {
  if (msg.author.bot) return;
  if (msg.channel.id !== SHIPPED_CHANNEL_ID) return;

  // Heuristic: contains a URL + a "shipped"-ish word
  const hasUrl = /https?:\/\/\S+/.test(msg.content);
  const hasShipWord = /\b(shipped|launched|live|released)\b/i.test(msg.content);
  if (!hasUrl || !hasShipWord) return;

  await db.launches.insert({
    user_id: msg.author.id,
    username: msg.author.username,
    text: msg.content,
    channel_id: msg.channel.id,
    message_id: msg.id,
    created_at: new Date(),
  });

  await msg.react('🚀');
});

client.on(Events.ClientReady, () => {
  console.log(`ShipTrack online as ${client.user.tag}`);
});

client.login(process.env.DISCORD_BOT_TOKEN);

Deploy this as a background worker. On HostingGuru this is the Pro tier worker process type — same Procfile-style declaration as Heroku's old worker: line:

# hostingguru.yml (or similar config)
processes:
  bot:
    type: worker
    command: node worker/bot.js
    always_on: true

The platform keeps it running. If it crashes, it restarts. If you push new code, it gracefully reconnects. No HTTP traffic required to keep it alive — that's the whole point of a worker process type vs a web service.

Process 3: the scheduled script (weekly digest)

This one runs once a week. It's an "on-demand" script — runs, finishes, exits. Costs almost nothing.

// scripts/weekly-digest.js
import { Client, GatewayIntentBits } from 'discord.js';
import { db } from './db.js';

const client = new Client({ intents: [GatewayIntentBits.Guilds] });
await client.login(process.env.DISCORD_BOT_TOKEN);

const since = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000);
const launches = await db.launches.find({
  created_at: { $gte: since },
});

if (launches.length === 0) {
  await client.destroy();
  process.exit(0);
}

const formatted = launches
  .map(l => `• <@${l.user_id}> shipped: ${l.text.slice(0, 200)}`)
  .join('\n');

const channel = await client.channels.fetch(process.env.ANNOUNCEMENTS_CHANNEL_ID);
await channel.send({
  content: `**📦 This week we shipped (${launches.length} launches):**\n\n${formatted}`,
  allowedMentions: { users: [] }, // notify in formatting only, don't ping
});

await client.destroy();
process.exit(0);

On HostingGuru, this runs as an on-demand script triggered by a schedule:

processes:
  weekly-digest:
    type: script
    command: node scripts/weekly-digest.js
    schedule: "0 9 * * 1"  # every Monday at 9:00 UTC

The platform spins up an ephemeral container at the scheduled time, runs the script, captures the output, exits. You pay for ~3 seconds of compute per week. If you've ever fought with Heroku Scheduler, you'll appreciate that the script lives in your repo, version-controlled, with the same env vars as the rest of your app.

Why this architecture matters

The naive temptation is to put all three in one Node process: HTTP server + Discord client + a setInterval for the digest. Don't. Three reasons:

Crashes blast radius. If your slash-command handler throws, the gateway connection survives. If your gateway disconnects mid-deploy, the slash commands keep working. Each process is independently restartable.
Scaling differs. If you have 5,000 slash commands an hour, you scale the web service. The worker stays at 1 instance (you only need one Discord gateway connection per bot). Different processes, different scaling profiles.
Costs differ. The worker burns CPU cycles 24/7 just maintaining a heartbeat. The script runs 3 seconds a week. Putting them on the same dyno is paying always-on prices for a once-a-week task.

This three-process pattern is what you want for any bot or background-heavy service: not just Discord. Slack apps. Telegram bots. Webhook receivers with async fanout. The shape repeats.

What I learned

WebSocket gateway = needs a worker, not a web service. Free web tiers will sleep your bot. Workers don't sleep on platforms that respect the worker primitive.
Slash commands ≠ gateway. They're HTTP, you can host them anywhere, but the 3-second response cap is real. Don't do heavy work inline — log to DB, respond, finish processing async.
Use a real database, not in-memory state. I tried "just use a JSON file" for v0. Workers restart, files vanish, members lost their launch history once. Two days later I wired Postgres.
Scheduled scripts > setInterval. A setInterval in your worker tied to wall-clock time will drift, miss runs during deploys, and double-fire if you scale to 2 instances. A scheduled script run as a separate process is exactly-once, exactly-on-time.
Always reply within 3 seconds. If your slash command handler does anything slow (database query > 1s, external API), respond with a deferred response (type: 5) and follow up later via Discord's webhook.

When this architecture is overkill

If you're building a bot for 5 friends to play a Discord trivia game, run it in one Node process on your laptop. You don't need three processes. You don't need a database. You probably don't need slash commands.

The three-process pattern starts paying off when at least one of these is true:

The bot is mission-critical (community would notice if it's down).
The bot has > ~50 users sending it traffic.
You need scheduled jobs that must run even if the bot crashed yesterday.
You're deploying it on a platform where free web tiers sleep.

For ShipTrack at 220 members + weekly digest, all four were true. So the three-process setup paid for itself the first time the worker crashed at 2am and the slash commands kept working through it.

A note on HostingGuru

The reason I'm building on HostingGuru (besides the obvious "I run it" disclosure at the top) is that the three primitives I needed — web service, worker, on-demand scheduled script — are first-class citizens on the platform. Same repo, same env vars, three lines of YAML config. No fighting with Heroku Scheduler vs Heroku dynos vs Heroku one-off heroku run jobs. No spinning up separate ECS task definitions on AWS.

If you're building anything with these three shapes — and most bots, webhook receivers, and background-heavy services have them — Pro tier (€35/mo) gets you 10 services with workers and on-demand scripts included. The free Starter tier supports the web service piece if you want to wire your worker elsewhere.

What's next

ShipTrack v3 is on my todo list. I want to add:

An LLM-powered launch summary at the bottom of each digest ("this week's theme: AI productivity tools")
A /profile @user command that shows someone's all-time launches
A leaderboard of "most active shipper this quarter"

If you've built a Discord bot recently and have hard-won lessons, I'd love to hear them in the comments. Especially the embarrassing v1 stories.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it.

4. Telegram alerts for any production app — a 5-minute setup.

Telegram alerts for any production app — a 5-minute setup (no SaaS, no signup, just curl)

Chalom Ellezam — Mon, 04 May 2026 12:36:33 +0000

Disclosure: I'm a senior backend tech lead and I run HostingGuru, where Telegram alerts ship as a built-in feature. This tutorial works on any platform — it's the manual version of what HostingGuru does for you. Useful even if you never become a customer.

There's a hierarchy of where production alerts go, ranked by how likely you are to actually see them.

Email → 14% open rate within an hour, less at 3am.
Slack → muted in 6 of 10 teams I've seen, especially "alerts" channels.
Phone-call paging (PagerDuty, Opsgenie) → works, but $20+/user/month and overkill for solo founders.
Telegram → notification on lock screen, no setup cost, works on every phone, you'll see it.

For a solo founder or a small team, Telegram alerts hit a sweet spot: the notification is annoying enough that you'll see it, easy enough that you'll set it up, and free. After 8 years of trying every paging tool, this is what I default to for early-stage projects.

Here's how to wire it up in 5 minutes, plus what I learned about what to alert on.

Step 1: Create a Telegram bot (60 seconds)

Open Telegram, search for @BotFather, start a chat.
Send /newbot.
Pick a name. Then a username (must end in bot, e.g. myapp_alerts_bot).
BotFather replies with a token like 7234567890:AAFq.... Save it. This is your TELEGRAM_BOT_TOKEN.

That's it. The bot exists. Now we need somewhere to send messages.

Step 2: Get your chat ID (60 seconds)

You need the ID of the chat where alerts will land. Two options:

Option A — Personal alerts (just for you):

Open a chat with your new bot. Send it any message ("hello").
Visit https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates in your browser.
Find the chat.id field in the JSON response. It's a number like 123456789. That's your chat ID.

Option B — Group alerts (for the team):

Create a Telegram group (or use an existing one).
Add your bot to the group.
Send any message in the group.
Visit the same getUpdates URL. The chat ID for groups is negative (e.g. -987654321).

Save the chat ID as TELEGRAM_CHAT_ID.

Step 3: Send your first alert (30 seconds)

The send API is one HTTP call. From a terminal:

curl -s -X POST \
  "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
  -d "chat_id=${TELEGRAM_CHAT_ID}" \
  -d "text=Hello from production"

Your phone should buzz immediately. If it does, the wiring is done. Now we just need to call this from your app when something interesting happens.

Step 4: Wire it into your app (3 minutes)

Node.js / TypeScript

// alerts.ts
const TG_TOKEN = process.env.TELEGRAM_BOT_TOKEN!;
const TG_CHAT  = process.env.TELEGRAM_CHAT_ID!;

export async function alert(message: string) {
  if (!TG_TOKEN || !TG_CHAT) return; // disabled in dev
  try {
    await fetch(`https://api.telegram.org/bot${TG_TOKEN}/sendMessage`, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        chat_id: TG_CHAT,
        text: message.slice(0, 4000), // Telegram cap
        parse_mode: 'Markdown',
      }),
    });
  } catch (e) {
    // never let alerting crash your app
    console.error('alert failed', e);
  }
}

Use it anywhere:

import { alert } from './alerts';

process.on('uncaughtException', (err) => {
  alert(`🚨 *Uncaught exception*\n\`${err.message}\`\n\nstack:\n\`\`\`\n${err.stack}\n\`\`\``);
});

// or in business logic
if (failed > THRESHOLD) {
  await alert(`⚠️ Stripe webhook retry rate at ${failed}/min — investigate`);
}

Python

# alerts.py
import os
import requests

TG_TOKEN = os.environ.get('TELEGRAM_BOT_TOKEN')
TG_CHAT  = os.environ.get('TELEGRAM_CHAT_ID')

def alert(message: str) -> None:
    if not TG_TOKEN or not TG_CHAT:
        return
    try:
        requests.post(
            f'https://api.telegram.org/bot{TG_TOKEN}/sendMessage',
            json={
                'chat_id': TG_CHAT,
                'text': message[:4000],
                'parse_mode': 'Markdown',
            },
            timeout=5,
        )
    except Exception as e:
        # never let alerting crash your app
        print(f'alert failed: {e}')

Wire it to the unhandled exception hook:

import sys
from alerts import alert

def excepthook(exc_type, exc_value, exc_traceback):
    alert(f'🚨 *Uncaught exception*\n`{exc_type.__name__}: {exc_value}`')
    sys.__excepthook__(exc_type, exc_value, exc_traceback)

sys.excepthook = excepthook

Plain bash (great for cron jobs)

#!/usr/bin/env bash
# Save as /usr/local/bin/tg-alert
curl -s -X POST \
  "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
  --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
  --data-urlencode "text=$1" > /dev/null

Then any cron job can do:

0 3 * * * /opt/myapp/nightly-backup.sh || tg-alert "❌ Nightly backup failed at $(hostname)"

That's the whole infrastructure. You're done.

Step 5: The rate-limiting trick (the part most tutorials skip)

Here's the failure mode of every "I just wired alerts" project: a bug fires at 200/sec, your phone buzzes 200 times in 10 seconds, you mute the bot in frustration, you miss the next real alert two days later.

You need a rate limiter between your code and Telegram. The simplest one: deduplicate identical messages within a window.

Node.js — in-memory dedupe

const seen = new Map<string, number>();
const DEDUPE_WINDOW_MS = 5 * 60 * 1000; // 5 minutes

export async function alert(message: string) {
  const key = message.slice(0, 200); // use first 200 chars as dedupe key
  const last = seen.get(key);
  if (last && Date.now() - last < DEDUPE_WINDOW_MS) return; // skip
  seen.set(key, Date.now());

  // ... rest of the send logic
}

This means the same alert won't fire more than once every 5 minutes, but different alerts still go through. A retry loop firing the same exception 800 times in 10 minutes will produce 3 Telegram messages, not 800. You'll still know it's happening.

Redis-backed (for multi-instance apps)

If your app runs on multiple servers, in-memory dedupe doesn't work. Use Redis:

import Redis from 'ioredis';
const redis = new Redis(process.env.REDIS_URL!);

export async function alert(message: string) {
  const key = `tg-dedupe:${hash(message.slice(0, 200))}`;
  const set = await redis.set(key, '1', 'EX', 300, 'NX');
  if (set !== 'OK') return; // already alerted in last 5 min

  // ... send to Telegram
}

The EX 300 NX does the magic: set the key with a 5-minute TTL, but only if it doesn't already exist. If two servers try to send the same alert simultaneously, only one wins.

What to alert on (the harder question)

The tutorial above is the easy part. The hard part is what to alert on. Bad alerts → alert fatigue → muted bot → you miss the real ones.

Five things that are usually worth a Telegram ping:

Uncaught exceptions in the main process — these usually mean a process is about to die or has died.
Job queue depth above N — if Sidekiq/BullMQ/Celery has more than e.g. 1000 jobs queued, something is producing faster than consuming. Investigate.
5xx error rate above 1% — not every 500 needs a ping, but the rate exceeding a threshold does.
Specific business events that mean money is leaking — failed payment retries, stale webhook signatures, expired refresh tokens.
Cron jobs that didn't run — if your nightly backup didn't fire by 3:30am, you want to know at 3:30am, not at 9am when you check email.

Five things that are usually NOT worth a ping:

Individual 4xx errors (these are mostly user error or scrapers).
Slow queries (log them, don't page on them).
Anything you can't act on in the next 30 minutes.
Anything where the action is "do nothing, it'll resolve itself" (most CDN hiccups, most rate-limit blips).
Anything informational ("user X signed up" — use a different channel for celebration).

The test I use: if I'm at dinner and my phone buzzes, will I be glad I knew, or annoyed? If the answer is "annoyed," it doesn't belong on Telegram.

A note on alert resolution

A subtle thing most tutorials skip: alerts should also tell you when something is fixed. If your job queue depth crossed 1000 and you got pinged, you also want a "now back to 0" ping when it normalizes. Otherwise you spend 20 minutes manually checking the dashboard.

The simplest pattern:

let inAlertState = false;

export async function checkQueueDepth(depth: number) {
  if (depth > 1000 && !inAlertState) {
    await alert(`🔴 Queue depth: ${depth}`);
    inAlertState = true;
  }
  if (depth < 100 && inAlertState) {
    await alert(`🟢 Queue back to ${depth}`);
    inAlertState = false;
  }
}

Two messages per incident, not 200. Your bot stays usable.

When to stop building this and use a platform

Everything above takes about an evening to wire up properly. For a small team, that's a great trade.

There are three signs it's time to stop building this and use a platform that does it:

You're spending more than 1 day a quarter maintaining your alerting setup.
You realize you need pattern detection (retry loops, token spikes, anomalous response times) — those are much harder to write yourself than threshold alerts.
You've muted your own bot more than once.

That's the gap HostingGuru fills. The platform tails your production logs, runs pattern detection automatically (retry loops, token spikes, hot fingerprints, anomalous latency, silent cron failures), and pings you on Telegram with a link to the relevant logs. No code in your app, no Redis dedupe to maintain — it's part of the hosting layer. €19/mo Hobby, €35/mo Pro.

If you're already deployed somewhere else, the homemade Telegram setup above is a fine start — and probably better than no alerts at all.

What to do after you finish reading this

Concretely, in the next 30 minutes:

Create the bot via BotFather.
Get your chat ID with getUpdates.
Add TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID to your env vars on whatever platform you use.
Drop the alert(message) helper into your codebase.
Wire it to your top-level uncaught exception handler.
Add the dedupe logic so a runaway loop doesn't spam you.

That's the minimum viable production alerting setup for any app. It costs $0, works in any country, lives on your phone, and survives every channel rotation in your team.

If you wire something interesting on top of this — anomaly detection, business event alerts, anything cool — drop it in the comments. I'm always looking for new patterns to steal.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

3. Your AI app is silently burning $2,000/month and you don't know it. Here are the 5 patterns that bite founders.

Your AI app is silently burning $2,000/month and you don't know it. Here are the 5 patterns that bite founders.

Chalom Ellezam — Wed, 29 Apr 2026 13:47:32 +0000

Disclosure: I'm a senior backend tech lead and I run HostingGuru, where built-in AI monitoring is the feature I'm proudest of. This article will mention HostingGuru once at the end, but the patterns and detection methods below work on any platform — I want this useful even if you never become a customer.

The cleanest version of this story is one I keep hearing from founders, with small variations each time:

"We woke up to a $2,400 OpenAI bill. The product still works. Sentry is green. Our error rate is normal. We have no idea what happened."

Then they dig in. They find a webhook handler that's been retrying a Stripe event for 11 days because a key was rotated and the retry logic capped out at "30 minutes between attempts" instead of "stop after 24 hours." Each retry calls an LLM to summarize the event for an internal log. 11 days × 48 retries × 8K tokens × $0.04. The math is unforgiving.

Or they find an agent that's been self-triggering. Or a context window that quietly grew from 4K to 80K tokens because nobody noticed a bug stuffing the entire conversation history into every prompt. Or a cron job that runs at 3am and produces output nobody reads, but produces it via Claude Sonnet at $3 per million input tokens.

This is the 2026 version of a problem that used to be small. AI made it expensive.

I want to walk you through the five patterns I see most often, why they're invisible to traditional monitoring, and what you can actually do about them tonight.

Why this is harder than it used to be

Pre-AI, a runaway loop in your app was annoying. It maxed out a CPU, your alerting noticed the CPU pegged, you got paged, you fixed it. Total damage: a few hours of degraded service, maybe a small AWS bill bump.

Post-AI, a runaway loop is expensive. Each iteration calls an LLM. Each LLM call costs real money. Worst of all, the loop doesn't show up as a problem in any of your existing tools:

Sentry: aggregates errors by fingerprint. Same retry loop = "1 issue, +850 events." It looks like one bug, not eight hundred.
CloudWatch / Datadog: traffic and CPU look fine — a retry loop is just a steady stream of requests.
Stripe / your billing dashboard: shows charges after they happen, on a 24-48h delay.
Your inbox: silent. The OpenAI / Anthropic / Stripe APIs don't email you when one customer is making 50,000 calls an hour.

The first signal you usually get is the credit card alert from your bank. By then, you're $1,000+ in.

Pattern 1: The infinite retry loop

The classic. A background job hits a transient error, your retry logic backs off exponentially, eventually retries every 30 minutes, but never gives up. The underlying issue is permanent: a webhook secret was rotated, an API key was deactivated, a file path was renamed. The job will retry forever.

If the job involves an LLM call (summarizing the error, deciding next action, generating a fallback response), every retry costs tokens. Multiply by however long until someone notices.

Real example I saw last month: a B2B SaaS doing email parsing. Their email parser used GPT-4 to extract structured data. One specific email format consistently failed validation downstream. The retry queue kept retrying. 11,000 emails × 6 retries × $0.10 per call = $6,600 wasted before the founder noticed.

How to detect it tonight: query your job queue (BullMQ, Sidekiq, Celery, whatever) for jobs that have been "active" or "failed" for more than 24 hours. Set a hard cap: any job that retries more than 10 times gets paged or dropped, no exceptions.

Pattern 2: The self-triggering agent

Multi-agent systems are particularly good at this one. Agent A produces output. Agent B reads agent A's output and decides "I should ping agent A for clarification." Agent A produces a clarification. Agent B reads it and decides "I should clarify the clarification." The conversation continues until you run out of context or money — whichever comes first.

I saw this kill a YC startup's monthly budget in 14 hours. They'd shipped a "research assistant" that orchestrated three agents. A user typed an ambiguous query. The agents started clarifying each other. By the time the user's session timed out, the system had made 4,200 LLM calls.

How to detect it tonight: hard-cap your multi-agent loops at 10 turns. After 10 back-and-forth iterations, the system returns whatever it has and exits. If you're using LangChain or similar, this is one config flag. If you've written your own orchestration, it's three lines of code.

Pattern 3: The "fingerprint aggregation" blind spot

This is the most insidious one because it specifically defeats Sentry / Bugsnag / Honeybadger.

Error monitoring tools group errors by fingerprint (basically a hash of the stack trace + error message). Same fingerprint = "this is the same bug." The dashboard shows "+842 events on this issue" with a slowly incrementing counter.

The problem: a retry loop firing the same error 800 times looks identical to 800 different users hitting the same bug once. Your error tool can't tell them apart. Both show up as "+800 events on the same issue." If you're not specifically watching event-rate per fingerprint, you'll miss the loop entirely.

The default Sentry alerts trigger on new issues, not on suddenly-very-noisy existing issues. So a bug that's been silently looping at 50/sec for 6 hours doesn't trip any alerts.

How to detect it tonight: add a custom Sentry alert on "any single issue with > 100 events per hour." Most teams forget this exists. It's the alert that catches the silent loops.

Pattern 4: The context window that quietly grew

Here's how this happens: you ship an AI feature with a 4K-token context window. Works fine in dev. In prod, a customer accumulates a long conversation history. Your code (or worse, Claude's code from when it built the feature) appends the entire conversation history to every new prompt without truncation.

Six months later, that customer has a 60K-token conversation. Every interaction now costs 15× what it did at launch. Multiplied across all your power users, you've quietly 5x'd your per-user AI cost without noticing — because the increase is gradual and the dashboard just shows "monthly OpenAI bill went up."

How to detect it tonight: log the input token count of every LLM call (most SDKs return this). Plot the p95 input token count over time. If it's trending up, you have context bloat. The fix is usually a sliding window or a summarization step.

This is also where I see the most "Claude Code did this and now I owe $400" stories. Claude is generous with context — it'll happily concatenate everything if you don't tell it not to.

Pattern 5: The cron job that never reads its output

Less dramatic, more common: a 0 3 * * * cron job kicks off every night at 3am. It runs an analysis. It generates a report. It writes the report to a database table or an S3 bucket. Nobody reads the report.

This was useful when you had it built last year. Then the team member who used it left. Then the report became stale. Then it became wrong. But the cron keeps running every night, calling the LLM, eating tokens. Quietly.

How to detect it tonight: list every cron job in your system. For each one, ask: "if this stopped running tomorrow, would anyone notice within 7 days?" If the answer is no, kill it. (You can always add it back if someone complains.)

What "good monitoring" looks like for AI apps

Traditional monitoring (Sentry, Datadog, CloudWatch) is great at finding errors. They're bad at finding patterns.

The patterns above all share two properties:

They're not errors. They're successful behavior at high volume.
They don't trigger alerts. Each individual call looks fine. Only the aggregate rate is wrong.

What you actually need is a layer that watches behavior, not errors. Some signals worth tracking:

Token usage per user per day (spike = investigation trigger)
LLM call rate per service (steady ≠ healthy if it's been steady for 18 hours unattended)
Job queue length over time (growing slowly = retry loop accumulating)
Per-fingerprint event rate (the Sentry blind spot above)
Cost per active user (rising = something's bloating somewhere)

You can build this yourself. It takes about 2 weeks of work for a backend engineer. You can also use a platform that has it built in, which is what I want to be honest about now.

What I built (and why I built it)

I'm a senior backend tech lead. I've shipped production systems for BeReal, Oney, Ringover. I built HostingGuru because the gap between "Sentry tells me when something errors" and "I get a Telegram ping at 3am that says 'this Stripe webhook handler has retried 200 times in the last hour, here's the link to the logs'" was the gap I kept finding myself filling manually for clients.

HostingGuru's AI monitoring tails your production logs and alerts on patterns, not errors:

Retry loops detected when the same operation fires faster than expected, regardless of error rate
Token spikes detected when a user's per-day LLM cost jumps significantly
Hot fingerprints detected when one Sentry-style issue suddenly explodes in event rate
Anomalous response times detected when p95 latency jumps without an obvious traffic cause
Silent cron failures detected when a job that ran consistently for 30 days suddenly stops

Alerts go to Telegram by default — because that's where founders actually look at 3am. (Email and Slack also supported.)

It works on any app deployed to HostingGuru, on any of the 14+ frameworks we support. The alerts and pattern detection are part of the platform — no extra config, no extra subscription.

If you've ever woken up to a surprise bill, this is the layer that would have caught it before it happened.

What to do tonight, regardless of which platform you use

You don't need to switch hosts to catch most of these. Five concrete moves:

Run a query on your job queue for any job retrying more than 10 times. Cancel them.
Cap your multi-agent loops at 10 turns in code. One commit.
Add a Sentry alert on "any single issue with > 100 events per hour."
Log token counts on every LLM call and check p95 input tokens trend. If trending up, fix context truncation.
List every cron job and kill any whose output nobody reads.

These five moves take an evening. They prevent the vast majority of the surprise-bill stories I hear. Whether you do them on HostingGuru, Render, Railway, AWS, or your own VPS, you should do them.

The harder truth

The hardest part of running an AI-powered product in 2026 isn't building it. AI tools made building it 10x cheaper. The hard part is operating it — knowing what's running, what it's costing, what's broken in a way that doesn't show up as broken.

The cost of a runaway loop went from "annoying" to "expensive" the moment AI became a per-call API charge. The tools we use to monitor production didn't get the memo. Sentry was designed in a world where errors were the primary problem; it's still the best at that, but it's not the right tool for "your tokens are leaking somewhere."

Until that gap closes across the whole industry, you have to build it yourself or use a platform that has it built in. Either path is fine. The one path that doesn't end well is "we'll find out at the end of the month."

If you've had a $2,000 surprise bill, what was the cause? I'm collecting these stories — drop them in the comments. The patterns repeat surprisingly often.

Previous posts in this series:

1. Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep

2. I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

I built my MVP with Claude Code. Now I need to deploy it. Here's what nobody tells you.

Chalom Ellezam — Mon, 27 Apr 2026 18:54:41 +0000

Disclosure up front: I'm a senior backend tech lead by trade and I run HostingGuru, one of the platforms mentioned at the end. I tried to make this useful even if you pick something else.

In 2026, a strange thing has happened. Hundreds of thousands of people who couldn't write a for loop two years ago are now shipping working software. They open Claude Code, Cursor, Lovable, or Bolt, describe what they want, and a few hours later they have a working app on their laptop.

I've watched this from up close. Friends who run agencies, founders who used to pay €30k for an MVP, business school grads with no engineering background — they all show me the same screen: a Mac terminal, an app running on localhost:3000, and a face that's half pride, half panic.

The pride: "I built this myself."

The panic: "How do I put it on the internet?"

That panic is what this post is about. Because the gap between "it works on my laptop" and "people can use it from a phone in another country" is wider than you think — and almost no one is writing for the person facing it for the first time.

The deployment cliff nobody warns you about

Building software with AI got 10x easier in 2 years. Deploying it didn't.

When you ask Claude Code to build a feature, it works. Maybe not perfectly, but it works. When you ask it "how do I deploy this?", you get one of three answers:

A list of commands that assume you already know what Docker is
A reference to "your hosting provider" — implying you have one
A polite suggestion to "consult your DevOps team"

You don't have a DevOps team. You don't have a hosting provider. You have a laptop and a working app and a launch date.

This is the deployment cliff. It's the moment where the AI assistant that taught you to code stops being useful, because deployment is half technical knowledge and half operational vigilance — and operational vigilance is exactly what AI is worst at.

The four things you actually need

Stripped of jargon, putting an app on the internet is four things:

1. A computer that's always on

When your app runs on localhost:3000, your laptop is the computer. The moment you close the lid, the app is gone. To stay online 24/7, your code needs to live on a computer that someone else keeps running. That's hosting.

2. An address people can type

localhost:3000 only works for you. To let other people in, the computer needs a public address — usually a domain like myapp.com. You buy this from a registrar (Namecheap, OVH, Gandi). Then you point it at the computer.

3. A place to store your secrets

Your app probably has API keys — to OpenAI, to Stripe, to whatever payments service you're using. These can't live in your code (anyone could see them). They live in environment variables — a secure storage that your hosting platform provides.

4. A way to know when something breaks

This is the one nobody mentions. Once your app is live, things break. APIs go down, retries fail, payments don't go through. The question isn't whether something will break — it's whether you'll know about it before your users do.

That's what monitoring is. It's the layer that watches your app and tells you when something's wrong.

If you're a non-technical founder, item #4 is the part that will quietly kill your launch. Not because the bug is hard to fix, but because you won't know it happened. Three days later a user emails "hey, your signup form has been broken since Tuesday" and you realize you've lost 70% of the people who tried to sign up.

Why most platforms aren't built for you

Now you Google "deploy app" and you hit a wall of options. Heroku, Vercel, Render, Railway, Fly.io, AWS, Google Cloud, DigitalOcean. Let me save you the research:

AWS, Google Cloud, Azure: Skip. These are infrastructure-as-toolboxes. They're powerful and cheap if you're willing to spend three weeks learning them. You're not. Don't even click.

Heroku: Was the easy answer for a decade. Entered "sustaining engineering mode" in February 2026 — meaning the company stopped shipping new features. Still works, but the trajectory is downward and the free tier is gone.

Vercel, Netlify: Great for frontends. If your app is purely a Next.js / React / static site, these are excellent. The moment you have a backend (a Node.js API, a Python script, a database connection), you're going to fight against the Serverless Functions abstraction. If you're not technical, this fight will exhaust you.

Render: The closest to old Heroku. Solid product. The catch: the free tier sleeps after 15 minutes of inactivity. Cold starts are 30 seconds. For a demo or a small product, that's a problem — your users see a blank screen for 30 seconds and many leave.

Railway: Slick UX, usage-based pricing. Good for small projects. The catch: usage-based billing is fair when traffic is small and surprising when traffic spikes. A runaway script can produce a 4-figure bill quietly.

Fly.io: Powerful, multi-region. Requires a fly.toml config file you'll have to learn to write or paste from documentation. Fine if you're a developer, more friction if you're not.

Self-hosted (a VPS on OVH/DigitalOcean + something like Coolify): Cheapest. You manage the server: OS updates, security patches, backups, SSL renewals, monitoring setup. Everyone tells you it's "not that hard." It actually is — when you're trying to focus on your product, not on Linux.

You see the pattern. Every option assumes you know one or two things you don't yet.

What "deploying for non-developers" actually needs to look like

Here's the honest list of what someone shipping their first AI-built MVP needs:

One simple action: connect your GitHub repo, click deploy. No fly.toml, no Dockerfile, no YAML, no terminal commands.
A free tier that doesn't sleep: because if you're showing a demo to your first 10 users and the site takes 30 seconds to load, you've lost the demo.
Domain + SSL handled for you: you should never have to type certbot. Type your domain, the platform deals with HTTPS.
Environment variables in a clean UI: paste your API keys, save, done.
Monitoring built in, not bolted on: when something breaks at 3am, the platform should tell you. Ideally on a channel you actually check (Telegram, email, Slack).
Predictable pricing: a flat monthly tier. €19, €29, whatever. Not "usage-based" that surprises you. You know your bill before the month starts.
A human you can ask: when you're stuck, you don't want a 200-page documentation site. You want someone who replies in a Discord or by email and says "oh, paste this in your env vars."

The platforms above each tick some boxes. None tick all of them, with one exception I want to be honest about.

What I built (and why I built it)

I'm a senior backend tech lead. I've shipped production systems for BeReal, Oney, Ringover. I've watched hundreds of friends try to deploy side projects and either give up or burn money on infrastructure they don't need.

So I built HostingGuru — a managed PaaS positioned exactly at this gap. It's not the cheapest. It's not the most powerful. It's the one I'd want my non-technical friends to use:

Free tier that never sleeps. Your demo stays online, period.
Connect GitHub, hit deploy. No Dockerfile. No YAML. No CLI required.
14+ frameworks supported out of the box: Next.js, Django, Rails, FastAPI, Express, Go, Rust, plus Docker if you want it.
Built-in AI monitoring with Telegram alerts. It tails your production logs and pings you when something looks off — retry loops draining your tokens at 3am, anomalous error spikes, response time degradation. This is the feature I'm proudest of, because it's the one most often missing.
EU + US data centers (Germany + Oregon). ISO 27001, GDPR-compliant. Important if your users are in Europe.
Predictable pricing. €19/mo Hobby (3 services). €35/mo Pro (10 services, custom domains, encrypted env vars, background workers).
Human support. I read every Discord message myself.

For non-technical founders specifically, we also offer white-glove setup for the Hobby tier: you tell us your repo, we set up the deployment and the domain, and you start with a working app. €19/mo + a one-time setup. You touch nothing.

If you're shipping your first Claude Code or Lovable app and you've been staring at AWS pricing tables for an hour, this is built for you.

What to do next, regardless of which platform you pick

Whether you go with HostingGuru, Render, Railway, or anything else, this is the order of operations that won't get you stuck:

Push your code to GitHub. If you don't have a GitHub account yet, make one. Every modern platform deploys from there.
Pick a platform that matches your tech. Next.js → most platforms work. Django/Rails → Render or HostingGuru. Static site → Netlify or Vercel.
Buy a domain. Cheapest from Namecheap or OVH (€10–15/year). Don't buy through your hosting platform — domains and hosting should be separate, so if you ever switch hosts you keep the domain.
Set up environment variables BEFORE deploying. Look at your .env file (the one you don't push to GitHub). Every line in there needs to be set on the platform.
Deploy a "hello world" version first. Not your full app — just confirm the platform can build something. Then add complexity.
Set up monitoring on day one. Even just an UptimeRobot ping every 5 minutes to your homepage. You want to know when the site is down before users tell you.
Set up alerts on a channel you check. Email is fine. Telegram is better. Slack if your team uses it. Not an internal dashboard you'll forget exists.

That's it. That's the whole thing. The first time you do it, it'll take an afternoon. The second time, twenty minutes.

A note on Claude Code specifically

If you built your app with Claude Code, you have one big advantage: the codebase tends to be cleaner and more conventional than what a beginner would write by hand. Most modern PaaS platforms can deploy it without modification, because Claude tends to use standard project structures (a clear package.json, a sensible requirements.txt, environment variables already factored out).

What you should not do: ask Claude Code to "deploy this for me." It can't. Deployment requires real-time interaction with the platform's API or dashboard, which an AI agent can't reliably do unattended yet. Claude Code is for building. Deployment is for you (or for a managed service that handles it on your behalf).

Closing

If you're reading this because you finished your first MVP last weekend and your laptop is uncomfortably warm, congratulations. The fact that the deployment step feels overwhelming is a sign you're about to learn something most engineers spent years learning. You'll do it once, it'll feel impossible, and then it'll be done.

If you want to skip that learning curve and have someone do it for you while you focus on the product, we offer that — that's HostingGuru. If you want to do it yourself with maximum DX, Render is also a great call. Either way: don't let the deployment step block your launch. Pick a platform tonight, ship something visible tomorrow.

What did you build? I'm curious what people are shipping with Claude Code these days. Drop a link in the comments.

If you found this useful, the previous post in this series was "Heroku just went into 'sustaining engineering mode'. Here are 5 alternatives whose free tier actually doesn't sleep" — a comparison of 5 PaaS options for the developer side of the same question.

Heroku just went into "sustaining engineering mode." Here are 5 alternatives whose free tier actually doesn't sleep.

Chalom Ellezam — Fri, 24 Apr 2026 08:00:27 +0000

In February 2026, Heroku quietly announced it was entering "sustaining engineering mode" — shifting focus away from new features toward "stability and security." They also stopped offering Enterprise contracts to new customers.

Translation, for the rest of us: Heroku is in maintenance mode. It still works. It's not getting better.

If you've been on Heroku (especially if you came back after the free-dyno era ended), this is a good moment to revisit the landscape. The PaaS market has actually gotten better since Heroku stopped innovating. The alternatives below all do parts of what Heroku did well — often for less money.

But here's the question I rarely see asked in "Heroku alternatives" listicles, and it matters a lot for side projects and MVPs:

Does the free tier actually stay up, or does it sleep after 15 minutes of inactivity?

This is the #1 gotcha in the alternatives market. A lot of "free" tiers aren't really free if your first user of the day gets a 30-second cold start. Below, each platform is evaluated specifically on that question, plus pricing, free-tier limits, and who it's actually best for.

1. HostingGuru

Free tier: never sleeps. This is the specific promise — your app stays online, period. One always-on service, free SSL, GitHub auto-deploy, a free custom subdomain. No credit card.

Paid tiers: $19/mo Hobby (3 services, custom domains, encrypted env vars) → $35/mo Pro (10 services, guaranteed resources, background workers, on-demand scripts).

Frameworks: 14+ including Next.js, Django, Rails, Laravel, FastAPI, Express, Rust, Go, Docker, static sites.

Data centers: Germany (EU) and Oregon (US). ISO 27001 / GDPR compliant.

What's different: built-in AI monitoring that tails production logs and pings the team on Telegram when something looks off — hangs, retry loops quietly burning tokens at 3am, unusual error spikes. Most PaaS products leave observability entirely to you.

Best for: solo devs, freelancers, and small teams who want a never-sleeps free tier to start on, and a predictable paid path from there. Also: anyone who needs EU hosting for GDPR reasons.

Caveats: smaller team than the big players. Discord + email is where help happens.

2. Render

Free tier: sleeps. Free web services spin down after 15 minutes of inactivity. Cold start is ~30 seconds. Free background workers don't exist.

Paid tiers: $7/mo Starter web service (no sleep, 512MB RAM, 0.5 CPU). Managed Postgres from $7/mo. Cron jobs, preview environments, background workers all available.

Frameworks: most things, with Dockerfile fallback for anything else.

What's different: probably the most "Heroku-like" option out there. Blueprints (infra-as-code), preview environments on PRs, cron jobs, background workers, managed Postgres. Polished product, long track record.

Best for: teams who liked the Heroku model and will pay $7+/mo right away. If you specifically want a free tier that stays up, Render isn't it.

3. Railway

Free tier: time-limited trial credit. You get ~$5 of trial credit that expires. After that, usage-based billing (roughly $0.000231 per GB-hour compute). No perpetual free tier.

Paid: pay-as-you-go; a typical small web service runs $5–20/mo depending on traffic and memory footprint.

Frameworks: anything that speaks HTTP, really. Nixpacks handles most stacks automatically.

What's different: slickest developer UX in this list. Deploy-from-GitHub is one-click. Usage-based billing is fair-feeling if your project is genuinely small, and scales smoothly if it grows.

Best for: builders who hate pricing tiers and prefer usage-based, predictable scaling. Not a fit if your MVP needs to run for free while you figure out product-market fit.

4. Fly.io

Free tier: 3 shared-cpu-1x VMs, ~256MB RAM each, ~3GB persistent volume. They've tightened the free allowance over time (it used to be more generous), but it's still one of the only real "free always-on" options outside HostingGuru.

Paid: pay-as-you-go beyond the free resources.

Frameworks: anything Dockerizable. There's a fly.toml file you'll touch.

What's different: deploy to multiple regions by default. Your app runs close to your users globally, not in a single region. More "infra-native" feel than the other options here — it leans toward the ops side of the spectrum.

Best for: devs who want edge/multi-region behavior, are comfortable with slightly lower-level abstractions, and don't mind writing a config file.

5. DigitalOcean App Platform

Free tier: static sites only. Dynamic web services start at $5/mo. Managed databases from $15/mo.

Paid: from $5/mo for a basic web service. Higher tiers unlock more CPU/RAM and autoscaling.

Frameworks: buildpack-based, supports the main stacks and Docker fallback.

What's different: lives inside the broader DigitalOcean ecosystem — Droplets, managed databases, Spaces object storage, Kubernetes. The upgrade path is clear: if you outgrow App Platform, you can move the same app to Droplets or DOKS without switching providers.

Best for: teams who plan to scale beyond PaaS later and want a single provider to grow into.

Quick comparison

Platform	Free tier stays up?	Min paid	Best for
HostingGuru	Yes, never sleeps	$19/mo	Always-on free start + AI monitoring
Render	No (sleeps 15 min)	$7/mo	Heroku-like, paid-from-day-one
Railway	Trial credit only	~$5–20/mo usage	Usage-based, predictable scaling
Fly.io	Yes (3 shared VMs)	Pay-as-you-go	Multi-region / edge
DO App Platform	Static only	$5/mo	Scale-out path inside DigitalOcean

How to actually pick

Three questions cut through the marketing:

1. Does your free tier need to stay up?
If yes → HostingGuru or Fly.io. If no → Render is probably the closest to Heroku ergonomics.

2. Do you want a tier ladder or usage-based pricing?
Tiers (HostingGuru, Render, DigitalOcean) are predictable and simple. Usage-based (Railway, Fly.io) is fair if your project is small — and occasionally produces surprises if traffic spikes.

3. Where does your data need to live?
For European customers or GDPR-sensitive workloads → HostingGuru or Fly.io both have EU regions. Render is US-primary (an EU region exists but less mature). DigitalOcean has global data centers but App Platform defaults to the US.

Migrating from Heroku

Most of these have a "deploy from GitHub" flow that makes migration fairly painless for standard stacks (Node, Python, Ruby, Go). The tricky parts are usually:

Scheduled jobs. Heroku Scheduler → each platform has its own cron story. Most support cron syntax natively now.
Background workers. Test carefully; resource limits differ.
Managed Postgres data migration. pg_dump + restore into the new managed DB is the universal answer. Expect 5 minutes of downtime for a small DB.
Environment variables. Most platforms let you bulk import from a .env file or paste from Heroku config vars.
Custom domains and SSL. Trivial everywhere — swap DNS, SSL auto-provisions.

For a Rails or Django app with one web dyno, one worker, and a Postgres DB, a full migration is usually a 1–2 hour job end to end.

Conclusion

Heroku's transition to "sustaining engineering mode" is, in a way, a gift. It forces a market that had gone quiet to start innovating again, and the alternatives above reflect that.

If your top priority is "free tier that stays up" — look at HostingGuru (what I build) or Fly.io. If your priority is "Heroku ergonomics, willing to pay $7/mo from day one" — Render. If your priority is "usage-based, no tiers" — Railway. If your priority is "future-proof path to bigger infrastructure" — DigitalOcean App Platform.

What are you moving to? I'm curious what specifically pushes people one direction or the other — the free-tier question, the pricing model, the frameworks supported, the region. Leave a comment, happy to answer specific migration questions.

If you want to try HostingGuru's always-on free tier, it's at hostingguru.io. No credit card, no sleep, GitHub-to-production in about 90 seconds. I'd love feedback if you give it a spin.

DEV Community: Chalom Ellezam

Your indie SaaS has zero working Postgres backups. Here's the 20-minute fix (and the drill you need to run before you sleep tonight).

The lie we tell ourselves about "managed" databases

What a real backup strategy looks like for a 1-person SaaS

The 4-line cron job that gets you 80% there

Restoring is the test you actually need to run

The three mistakes I see every single week

What I built

What to do tonight regardless of which platform you use

One question

The Claude Code production checklist: 15 things that aren't obvious until they bite you

1. Your .env file is in your git history

2. You have one set of API keys for dev and prod

3. Your Stripe webhook is unsigned

4. You're using Stripe test keys in production

5. Your database has no backup strategy

6. You have no rate limiting on AI endpoints

7. CORS is wide open

8. You haven't set up error tracking

9. Your app ships source maps to production

10. You have no /healthz endpoint

11. Your DNS TTL is too high

12. Your runtime version isn't pinned

13. Server secrets are in your frontend bundle

14. You have no monitoring on cron jobs

15. Your app crashes silently on startup, restarts forever

The faster path through this list

What to do tonight, in order

I migrated 12 client projects off Heroku. Here's the playbook (and the 7 things that bit me every single time).

Part 1 — The playbook

Step 0: Decide the destination first

Step 1: Inventory what's actually running

Step 2: Provision the destination

Step 3: Copy env vars carefully

Step 4: Deploy code to the new platform — get "hello world" working

Step 5: Database migration (the scary part)

Step 6: Put Heroku in maintenance mode + flip DNS

Step 7: Final dump + restore

Step 8: Reroute external webhooks, then drop maintenance mode

Part 2 — The 7 things that bit me

Bite 1: The heroku_ext schema doesn't exist anywhere else

Bite 2: pg_stat_statements is enabled by default on Heroku, often not elsewhere

Bite 3: Heroku's DATABASE_URL bakes in sslmode=require

Bite 4: Scheduled jobs run on different time zones

Bite 5: Heroku's DYNO env var doesn't exist anywhere else

Bite 6: Heroku Postgres "follower" replicas don't survive

Bite 7: Buildpacks vs Docker — your build will behave subtly differently

The full migration timeline I quote clients

What I'd do if I were migrating today

A note on the platform I run

Closing

How I built a Discord 'ship-tracker' bot in a weekend (and the 3-process architecture that keeps it alive 24/7)

What the bot does

v1: the naive setup that crashed in 15 minutes

Why Discord bots are weirder than they look

v2: three processes, three responsibilities

Process 1: the web service (slash commands)

Process 2: the worker (gateway + reactions)

Process 3: the scheduled script (weekly digest)

Why this architecture matters

What I learned

When this architecture is overkill

A note on HostingGuru

What's next

Telegram alerts for any production app — a 5-minute setup (no SaaS, no signup, just curl)

Step 1: Create a Telegram bot (60 seconds)

Step 2: Get your chat ID (60 seconds)

Step 3: Send your first alert (30 seconds)

Step 4: Wire it into your app (3 minutes)

Node.js / TypeScript

Python

Plain bash (great for cron jobs)

Step 5: The rate-limiting trick (the part most tutorials skip)

Node.js — in-memory dedupe

Redis-backed (for multi-instance apps)

What to alert on (the harder question)

A note on alert resolution

When to stop building this and use a platform

What to do after you finish reading this

Your AI app is silently burning $2,000/month and you don't know it. Here are the 5 patterns that bite founders.

1. Your `.env` file is in your git history

10. You have no `/healthz` endpoint

Bite 1: The `heroku_ext` schema doesn't exist anywhere else

Bite 2: `pg_stat_statements` is enabled by default on Heroku, often not elsewhere

Bite 3: Heroku's `DATABASE_URL` bakes in `sslmode=require`

Bite 5: Heroku's `DYNO` env var doesn't exist anywhere else