Heroku killed its free dyno tier back in 2022, and the wave of “what do I use now” posts from Discord bot developers never really stopped, it just kept restarting every time a new host quietly changed its own free tier terms. That churn is the real story here. A platform that’s generous today can tighten limits in a point release six months from now, and a bot that’s been running fine for a year suddenly stops responding because a background worker got capped without much warning.

Discord bots have a requirement most tutorials gloss over: they need a persistent connection to Discord’s gateway, not just a server that responds to incoming HTTP requests. That single detail rules out a chunk of “free” hosting options that spin a project down after a few minutes of inactivity, since a sleeping bot means a bot that’s offline in every server it’s in. This guide walks through twelve real hosting options for 2026, flags which ones actually support the always-on connection a bot needs versus which ones will leave your bot showing as offline half the day, and gives a straight read on setup complexity for each.

The Sleep Problem, Explained

A lot of free-tier hosting saves money by spinning down idle projects and waking them on the next incoming request. That model works fine for a website nobody’s actively browsing at 3am. It breaks a Discord bot immediately, because the bot needs to hold an open WebSocket connection to Discord’s gateway around the clock to receive events like messages and reactions. If the host kills that process after fifteen minutes of no HTTP traffic, the bot silently drops offline until something happens to wake it again, which for a background worker with no public URL might be never.

Some developers work around this with an external uptime pinger hitting a small HTTP endpoint the bot exposes just to stay awake, which works on some platforms and violates the terms of service on others. Before building a workaround into your deployment, check the specific platform’s policy on keep-alive pinging, because getting a project suspended for violating usage terms is a worse outcome than an honest evaluation of whether the free tier fits a persistent bot in the first place.

1. Railway

Railway runs projects as persistent processes rather than sleep-on-idle functions, which makes it one of the more bot-friendly options here out of the box. Deployment from a GitHub repo triggers automatically on push, and the dashboard gives clear resource usage graphs so you can see exactly how close a bot is running to its allotted memory before it gets killed for exceeding limits. Node.js and Python both deploy with minimal configuration, usually just a start command and a few environment variables for the bot token.

The free tier runs on usage-based credits rather than a flat monthly allowance, so a bot with heavy traffic across several large servers can burn through the free allocation faster than expected. Monitoring usage in the first week after deployment avoids an unpleasant surprise when the credits run dry mid-month.

2. Render

Render’s background worker service type is built specifically for processes that need to run continuously without responding to HTTP requests, which is exactly the shape of a Discord bot. Deployment pulls straight from a connected Git repository, and the platform handles restarts automatically if the process crashes, which matters more than it sounds for a bot that occasionally hits an unhandled exception on a malformed message. Free tier web services do sleep on inactivity, but the background worker type specifically doesn’t follow that pattern the same way, making it the more relevant service type for bot hosting on this platform.

Build times can run a couple of minutes even for a small project, which isn’t a dealbreaker but is worth knowing if you’re used to near-instant redeploys elsewhere.

3. Fly.io

Fly.io deploys containers to physical machines distributed globally, which shaves meaningful latency off a bot’s response time for servers with members spread across regions. The free allowance covers a small number of always-on machines, genuinely always-on rather than sleep-on-idle, which makes it one of the more straightforwardly bot-appropriate free tiers on this list. Because it’s container-based, any language or framework that can run in a Docker container works here, not just the handful of officially supported runtimes some PaaS platforms limit you to.

The trade-off is a steeper initial learning curve than Railway or Render. Fly’s CLI-first workflow and configuration file expect more comfort with Docker concepts than a pure point-and-click deploy, so first-time bot hosters sometimes bounce off the setup before getting a bot running.

4. Replit

Replit’s browser-based editor lowers the barrier to entry about as far as it goes, letting a beginner write and run bot code without installing anything locally. The always-on feature, which keeps a project running continuously instead of sleeping, is a paid add-on rather than included in the free tier, and without it a free Replit project sleeps after inactivity the same way most sleep-on-idle hosts do. For learning to code a first bot and testing locally before deploying elsewhere, Replit’s instant environment is genuinely useful. For actually hosting a bot long-term on the free tier specifically, the sleep behavior makes it a weaker choice than Railway or Fly.io.

5. Glitch

Glitch shares Replit’s in-browser editing convenience and its sleep-after-inactivity limitation on the free tier. Projects wake on an incoming request, but a Discord bot with no public HTTP endpoint has nothing to wake it, so most bot developers pair Glitch with an external pinger hitting a small keep-alive route built into the bot’s code. Community remix features make it easy to find and adapt existing open-source bot templates, which is a genuine advantage for beginners building their first project from a working example rather than a blank file.

6. Oracle Cloud Free Tier

Oracle’s Always Free tier includes small VPS instances that stay free indefinitely rather than expiring after a trial period, which sets it apart from most cloud providers’ time-limited free credits. Running a bot on a raw VPS means full control over the environment, no sleep-on-idle behavior at all, and the ability to run multiple bots or other services on the same instance without separate hosting accounts for each. It also means handling your own process management, security updates, and monitoring, none of which a managed PaaS handles for you automatically.

Signup and instance provisioning on Oracle Cloud has a reputation for occasional friction, including capacity availability issues in some regions for the free-tier instance types. Patience during setup pays off given the tier’s genuinely generous long-term allowance once it’s running.

7. Google Cloud Run

Cloud Run’s scale-to-zero model bills only for actual compute time used, which sounds appealing until you remember that scale-to-zero means the container isn’t running when there’s no incoming request, the same fundamental problem sleep-on-idle hosting causes for a bot that needs a persistent gateway connection. Cloud Run works well for Discord’s newer HTTP-based interaction model, where slash commands arrive as webhook requests rather than requiring a standing gateway connection, but a traditional bot listening for messages and events needs the always-on gateway connection Cloud Run’s default model doesn’t naturally support without additional configuration to keep an instance warm.

8. AWS Lambda

Lambda’s generous free tier and event-driven model make it a genuinely strong fit specifically for slash-command-only bots built around Discord’s HTTP interaction endpoint, where each command invocation is a discrete event Lambda can handle without needing a persistent connection at all. For a traditional gateway-connected bot handling message events, reactions, and presence updates continuously, Lambda’s execution model fights against what the bot actually needs. Knowing which interaction model your bot uses before choosing Lambda saves a frustrating setup process discovering the mismatch after the fact.

9. Koyeb

Koyeb positions itself similarly to Railway and Render, with a free tier that includes always-on web services rather than sleep-on-idle functions. Deployment from Git or a container registry covers most common workflows, and the global edge network shortens response latency for bots serving international communities. It’s a newer platform than the others on this list, which means a smaller community and fewer troubleshooting threads to reference when something goes wrong, worth factoring in if you value being able to search for a specific error message and find someone else who already solved it.

10. Northflank

Northflank leans toward teams running multiple services together, with built-in CI/CD pipelines and database provisioning alongside the core hosting. For a Discord bot that also needs a database for persistent settings or user data, having both provisioned from the same dashboard avoids juggling separate accounts across a hosting platform and a database provider. The free tier’s resource limits are tighter than some competitors, which matters more for a bot serving a large number of servers than for a small personal project.

11. PythonAnywhere

PythonAnywhere targets Python specifically, and for a bot built on discord.py or a similar library, that focus translates into a simpler setup than general-purpose platforms expecting you to configure a runtime from scratch. The free tier includes always-on task scheduling for background processes, though the always-on console feature that keeps a persistent process running has narrower free-tier limits than the platforms built explicitly around background workers. It’s a reasonable choice specifically for Python developers who want less configuration overhead, less useful for anyone building in JavaScript or another language.

12. Hetzner Cloud

Hetzner isn’t free, but its entry-level VPS pricing sits low enough that it’s worth mentioning alongside the free options for anyone who has already outgrown free tiers or wants guaranteed always-on hosting without navigating free-tier restrictions and sleep behavior at all. A few dollars a month buys a full VPS with root access, comparable to what Oracle’s free tier offers but without the capacity availability issues some regions report, and with straightforward, predictable billing. For a bot serving enough servers that reliability starts to matter more than saving the last few dollars, it’s worth the small monthly cost.

Choosing Based on Your Bot’s Architecture

Traditional gateway-connected bots, the kind built with discord.py, discord.js, or similar libraries that maintain a persistent WebSocket, need genuinely always-on hosting. Railway, Render’s background worker type, Fly.io, and Oracle Cloud’s free VPS all fit that requirement without workarounds. Bots built entirely around Discord’s newer HTTP interaction model for slash commands can use event-driven platforms like AWS Lambda or Google Cloud Run more naturally, since each command invocation is a discrete, short-lived event rather than part of a continuous connection.

Beginners writing their first bot benefit most from Replit or Glitch for the development and testing phase, where the in-browser editor removes setup friction, even if the sleep behavior means graduating to a different host before running the bot in production for a real community. Developers comfortable with server administration get the most long-term value and control from Oracle Cloud’s free VPS or a low-cost Hetzner instance, trading initial setup time for a platform that won’t change its free-tier terms out from under a running bot.

Database and Persistent Storage

Most bots beyond the simplest command-response pattern need somewhere to store server settings, user preferences, or moderation logs, and free hosting tiers rarely include a database by default. Railway and Render both offer add-on database services, though free-tier storage limits are modest and worth checking against your bot’s actual data volume before assuming it’ll fit. Running SQLite as a local file works on a VPS like Oracle Cloud or Hetzner where the filesystem persists between restarts, but breaks on platforms that reset the filesystem on every redeploy, silently wiping stored data unless you’ve moved to an external database service instead.

Monitoring Uptime Without Violating Terms

For genuinely always-on platforms like Railway, Fly.io, or a VPS, uptime monitoring is about catching crashes rather than fighting sleep behavior, and a simple health-check endpoint paired with a monitoring service that alerts on downtime covers most needs. For platforms with sleep-on-idle free tiers, check the specific terms of service before setting up an external pinger to keep a project artificially awake, since some platforms explicitly prohibit this practice as a way of gaming free-tier limits, and getting a project suspended defeats the purpose of the workaround entirely.

Common Deployment Mistakes

Hardcoding a bot token directly in source code instead of an environment variable is the mistake that causes the most damage, since a public GitHub repo with a leaked token gets the bot hijacked or the token revoked by Discord’s automated scanning within minutes of a push. Every platform on this list supports environment variables specifically to avoid this, and there’s no good reason to skip that step even for a small personal project.

Not setting memory and restart limits is the second common failure. A bot with a slow memory leak that isn’t caught in testing will eventually get killed by the host’s resource limits, and without automatic restart configured, that means the bot stays down until someone notices and manually redeploys. Railway, Render, and Fly.io all restart crashed processes automatically by default, but a raw VPS setup on Oracle Cloud or Hetzner needs a process manager like systemd or pm2 configured explicitly, since a crashed process on a bare server just stays crashed with nothing to bring it back.

Ignoring rate limits from Discord’s API is the third trap, particularly for bots that fire off multiple messages or role changes in quick succession during a busy event. Discord’s rate limiting will start returning errors well before a host’s own resource limits become the bottleneck, and a bot that doesn’t handle those errors gracefully can end up stuck in a retry loop that burns through hosting resources for no benefit.

Cost Beyond the Initial Free Tier

A bot that stays small, serving a handful of servers with light command usage, will likely never exceed most platforms’ free allowances. Growth changes that math quickly. A bot added to hundreds of servers generates proportionally more gateway events, more command invocations, and more memory pressure from cached guild and member data, and usage-based platforms like Railway will show that growth directly in a rising monthly bill. Flat-rate VPS hosting like Hetzner or a paid Oracle Cloud tier caps that cost predictably regardless of how much the bot’s usage grows, which is worth factoring in early if a bot has any realistic path to serving a large number of communities rather than staying a small personal project indefinitely.

Building Bot Communities

Discord bot developers building support resources and documentation outside the Discord app itself can use a platform like Reign Theme to run a companion site with forums, guides, and command documentation that’s easier to search and reference than scrolling through Discord channel history.

Final Thoughts

The right Heroku replacement depends almost entirely on what kind of bot you’re running and how much server administration you’re willing to take on. Railway and Fly.io offer the closest experience to Heroku’s original simplicity while still supporting the always-on connection a traditional bot needs. Oracle Cloud’s free VPS and a low-cost Hetzner instance trade setup complexity for long-term stability free of shifting PaaS terms. Whatever you pick, confirm it actually supports a persistent connection before building anything on top of it, since that single detail is what separates a bot that stays online from one that mysteriously goes dark every few minutes.