Skip to main content
Stackbastion

Draft, not yet published

Replit Always On vs real hosting: what you're actually paying for

7 July 2026· 5 min read · by Stackbastion

You turned on Replit Always On, your app stopped falling asleep, and now you’re wondering if you’re actually hosted for real. You’re not sure what the €7 a month is buying you, or whether it’s enough for paying users. Short answer: Always On solves one narrow problem, and production hosting solves about ten more that it doesn’t touch.

Why this happens

Replit’s default free Repls sleep when nobody hits them. The first request after a sleep has to wake the container, which can take several seconds. For a demo that’s fine. For a live app it looks broken.

Always On fixes exactly that. It keeps your Repl’s process running so it doesn’t cold-start. That’s the whole feature. It’s a keep-warm switch, not a hosting platform.

The confusion comes from the word “hosting.” When people say their app is “hosted,” they usually mean the full stack of things a production app needs: a stable URL, a real database that won’t reset, backups, room to handle traffic spikes, monitoring, and a way to recover when something breaks at 2am. Always On gives you one of those (uptime of the process) and leaves the rest to you.

Here’s the part that catches people out. On Replit, your app and your database often live in the same environment. When the environment restarts, or you hit a resource limit, or you fork the Repl, the data story gets complicated fast. Always On keeps the process up, but it doesn’t give you a managed, backed-up, independently scalable database. It doesn’t give you point-in-time recovery. It doesn’t give you a horizontal scaling story when 500 people show up at once.

How to fix it

You don’t “fix” Always On. You decide whether the stage you’re at needs more than it offers. Here’s the honest breakdown.

Always On is genuinely fine when:

  • You’re building, testing, or demoing.
  • Traffic is a handful of people you know.
  • Losing the data would be annoying, not a disaster.
  • Nobody is paying you for uptime.

You’ve outgrown it when any of these are true:

  • Real users depend on the app being up.
  • You store data you can’t afford to lose (customer records, orders, anything you’d have to email an apology about).
  • You need a custom domain with proper SSL that you control.
  • Traffic is spiky (a launch, a newsletter send, a Product Hunt post).
  • You need to prove to anyone (a customer, an auditor) where the data lives and how it’s backed up.

If you’re in the second group, the move is to separate your concerns. A real setup looks like this:

app process        ->  a host that runs your code (container or VM)
database           ->  a managed Postgres, separate from the app
backups            ->  automated, tested, off the app server
domain + SSL       ->  DNS you control, auto-renewing certificates
monitoring         ->  an uptime check that pings you when it's down

The key change is that the database stops living inside the same box as your app. That one decision fixes most of the “my data disappeared” and “I can’t scale” problems at once.

A minimal, boring version you can stand up yourself: a small VM, Docker for your app, a managed Postgres from any provider, and a reverse proxy like Caddy for automatic HTTPS. Caddy gets you SSL with almost no config:

yourapp.com {
	reverse_proxy localhost:3000
}

That’s a full working HTTPS site. Caddy fetches and renews the certificate for you. Compare that to keeping a Repl warm and hoping the database survives the next restart, and you can see the gap.

The cost jump is smaller than people expect. Always On is around €7 a month. A small VM plus managed Postgres lands somewhere between €15 and €40 a month depending on the provider, and you get real backups and real isolation for it. The question isn’t price, it’s whether your app has grown past the demo stage.

Or, we do it for you

Moving from a keep-warm Repl to a real, backed-up, monitored setup is the exact jump we handle. See what that costs on our pricing page, and note we currently onboard Lovable and generic Git-repo projects, so bring your code in whatever shape it’s in.

FAQ

Does Always On mean my app is backed up?

No. Always On keeps the process running. It says nothing about backups. If your data lives inside the Repl and something resets it, Always On won’t bring it back. Treat backups as a separate thing you have to set up on purpose.

Can I just use Always On for a paid product?

You can, but you’re accepting real risk. No tested backups, limited scaling headroom, and a data story that gets messy under load. For a hobby project that’s a fair trade. For anything with paying customers, the missing pieces tend to show up at the worst possible moment.

What’s the actual difference from “real” hosting?

Real hosting separates your app, your database, and your backups so each can be scaled and recovered on its own. It gives you a domain and SSL you control, plus monitoring that tells you when something’s wrong. Always On covers uptime of one process and stops there.

If I want a second opinion on my setup, what should I do?

If you want a second pair of eyes on your setup regardless of what you built it with, get a free production audit. We’ll tell you honestly whether Always On is enough for where you are, or where the gaps are.

Related posts