Best Tech Stack for Building a Discord Bot as a Solo Developer

I've built and maintained several Discord bots over the past few years. The one that taught me the most was a moderation bot I built for a gaming community. It started as a 200-line script and grew into something much bigger. Every poor architecture decision I made in the first version haunted me for months. The stack I recommend now is the result of those lessons.

Discord bots are fun because the feedback loop is immediate. Run a command, see the result. But they're also systems that need to run 24/7, handle concurrent users, and scale to multiple servers. Picking the right tools from the start makes the difference between a bot that runs smoothly and one that constantly crashes at 3 AM.

The Recommended Stack

Why This Stack Works for Solo Developers

Discord bots need to be online all the time. Unlike a web app where a few seconds of downtime is barely noticeable, a Discord bot going offline means commands fail, events are missed, and users immediately notice. This makes hosting choice and reliability crucial.

The Node.js and Discord.js combination is the default for a reason. Discord.js has the largest community, the best documentation, and handles the WebSocket connection to Discord's gateway reliably. I've tried Python with discord.py (solid, but the async pattern is less intuitive if you come from web development), and even Go with discordgo (fast but the library is more low-level). For solo developers who already know JavaScript, Discord.js is the clear winner.

TypeScript isn't optional in my opinion. Discord's slash command system involves complex option types, permission flags, and interaction responses. TypeScript catches mismatches at compile time that would otherwise crash your bot at runtime. A user triggers a command, your bot crashes because you passed a string where a number was expected, and nobody's around to restart it. TypeScript prevents that class of bug entirely.

Library: Discord.js

Discord.js v14 is the current stable version and it's excellent. The builders pattern for creating slash commands, embeds, and components is clean and type-safe. Here's what I like about it.

The command handler pattern is well-established. Create a commands/ directory, put each command in its own file with a data property (the slash command definition) and an execute function, and load them dynamically on startup. Every serious Discord.js bot follows this pattern, and there are countless tutorials and examples to reference.

The event system is straightforward. Listen for messageCreate, interactionCreate, guildMemberAdd, and dozens of other events. The typing support means you get autocomplete for event data, which is a huge time saver.

One thing that tripped me up initially was the Gateway Intents system. Discord requires you to explicitly declare which events your bot needs access to. If you don't request the GuildMembers intent, you won't receive member join/leave events, and your bot will silently not work. Always check which intents your features require and enable them both in code and in the Discord Developer Portal.

Database: Start with SQLite

Here's an opinion that might surprise you. Use SQLite for your bot's database until you have a concrete reason not to. SQLite runs in-process, requires zero configuration, has no separate server to manage, and handles thousands of reads per second. For a Discord bot storing server configurations, user preferences, or game state, SQLite is more than enough.

I used PostgreSQL from day one on my first bot because "real applications use real databases." It added deployment complexity (now I needed a database server), increased hosting costs, and the connection pooling overhead was totally unnecessary for my data volume. When I rebuilt the bot with SQLite, everything got simpler.

The migration path is clean too. Start with SQLite via Prisma, and when you actually hit a limit (concurrent write contention from multiple shards, or you need full-text search), switch to PostgreSQL by changing one line in your Prisma schema and running a data migration. Prisma abstracts the database engine.

When to use PostgreSQL from the start. If your bot runs on 1000+ servers, handles high-frequency events (like message tracking), or needs complex queries with joins across large datasets. In those cases, the connection pooling and concurrent write handling of Postgres justify the complexity.

Hosting: Railway or Fly.io

Discord bots need a persistent WebSocket connection. This rules out serverless platforms like Vercel or Netlify Functions. Your bot needs to be a long-running process.

Railway is my first choice for solo developers. Deploy by connecting your GitHub repo, set your environment variables, and Railway keeps your bot running. The free tier gives you enough hours to run a bot part-time, and the $5/month Hobby plan gives you 24/7 uptime. Deploys happen automatically on git push.

Fly.io is the alternative if you want more control. It runs your bot in containers closer to your users (though for Discord bots, latency matters less than for web apps). Fly's free tier is also generous enough for a small bot.

For larger bots (100+ servers), consider a VPS from Hetzner ($4/month for a solid machine) with PM2 for process management. PM2 auto-restarts your bot on crashes, manages logs, and can run your bot in cluster mode if needed. The tradeoff is that you manage the server yourself.

What I'd Skip

Microservice architecture. Your bot doesn't need a separate service for commands, events, and the database layer. One process handles everything until you're running a very large bot. I've seen developers split a 500-line bot into three "microservices" for no reason. Keep it simple.

Docker for development. Use Docker for production deployment if your hosting requires it, but develop locally with tsx watch (TypeScript execute with file watching). The hot-reload cycle is faster than rebuilding containers.

Complex caching layers. Redis caching for a Discord bot with 50 servers is unnecessary overhead. Discord.js already caches guilds, channels, and members in memory. Use that cache. Add Redis only when you're sharding across multiple processes and need shared state.

Sharding before you need it. Discord requires sharding at 2,500 servers. Until you're close to that number, a single process handles everything fine. Premature sharding adds significant complexity to your database queries, caching, and command handling.

Web frameworks. Your bot doesn't need Express or Fastify unless you're building a web dashboard alongside it. The Discord gateway handles all communication. If you need a health check endpoint, a five-line HTTP server is enough.

Getting Started

Here's my first-day setup for a new Discord bot.

1. Create the project. Initialize a TypeScript project with npm init -y, install discord.js and tsx, set up your tsconfig, and create a basic src/index.ts that connects to Discord's gateway.

2. Set up the command handler. Create src/commands/ and add a ping.ts command. Register it with Discord's API using the REST module. Run the bot and test /ping in your test server.

3. Add your database. Install Prisma, create your schema with the models your bot needs (GuildConfig, User, etc.), and generate the client. Wire it into your command handler.

4. Implement your core feature. Whatever your bot actually does, build it now. Get it working end to end in your test server.

5. Deploy to Railway. Connect your repo, add the DISCORD_TOKEN environment variable, and push. Your bot goes online in about 90 seconds.

The best Discord bot stack is the one that stays out of your way while giving you the tools to build reliable features. This combination does exactly that. Start with the basics, ship your bot, and add complexity only when the number of servers or features demands it.