discordeno splits a Discord bot into packages you can pick from

One API surface, three runtimes, and the audience it targets

discordeno is a library for talking to the Discord API, written in TypeScript and published for Node.JS, Deno and Bun. The same codebase runs on all three, which matters for teams whose tooling differs between a local development machine and a deployment target.

The people it is aimed at are teams that already have a bot with scale problems. The README's feature list is organised around things like rate limit handling, identify limits, resharding and horizontal scaling, and the reference to a bot running on 100,000 servers or 150,000 servers sets the register. A hobby bot on a handful of guilds is not the design target.

Two defaults define the philosophy. There is no caching by default, so the library starts lean and you opt into the memory cost of keeping state. And the API is functional rather than class based, which the README presents as removing the difficulty of extending built-in classes while keeping the code fast.

The homepage is the documentation site at discordeno.js.org, and the README points to its getting started page for anything beyond the quick start.

Six published packages, and the choice of what to install

The README lists six npm packages, and this split is the central design decision of the project.

There is the umbrella package discordeno, plus scoped packages for types, utils, rest, gateway and bot. The table in the README shows a codecov coverage badge per package, which tells you the maintainers track test coverage separately for each one rather than for the repository as a whole.

The packages map onto separate responsibilities. The rest package wraps the HTTP side of the Discord API. The gateway package handles the persistent event connection. Types and utils are the supporting layers. The bot package is the one you reach for when you want the assembled bot.

Standalone components are the reason for the split. The README states you can have practically any component of a bot as a separate piece, including standalone REST, gateways and custom caches. If you do not want to depend on the bot package, you can compose from the lower layers instead.

The same thinking appears in the property removal feature. The README says you may remove any property the bot does not need, for instance Channel.topic, and that a few lines of code accomplish this for any property on any object, with the claim that this can save gigabytes of RAM. That is an unusual degree of control to have over a library's data model.

A functional API instead of extending built-in classes

The functional API is described as eliminating the challenge of extending built-in classes and inheritance while keeping the code simple and fast. In practice it means the objects Discord returns are plain data that you compose with functions, rather than instances of a class hierarchy you are expected to subclass.

That choice has consequences in both directions. It removes the familiar pattern of monkey-patching a prototype to add a method, which is where a lot of library coupling and upgrade pain comes from. It also means the library is not doing anything behind your back through hidden class behaviour.

The other side is that the shape of the API has to be learned rather than inferred from JavaScript conventions. A team coming from an object oriented Discord library will spend time finding the equivalent of each operation, and the docs at discordeno.js.org are the reference for that mapping.

It fits with the property removal story. If the model is data rather than a class with behaviour, deleting a field that your bot never reads is a well defined operation rather than a monkey patch that other code might depend on.

A separate REST process as the single point of contact

The REST section of the README makes the case for pulling HTTP traffic out of the bot process.

The first benefit is protection against invalid requests. The README states that a failed request can otherwise keep a bot down for an hour, and that the separate REST server lowers that maximum downtime to 10 minutes. The second is rate limits. As a bot grows, global rate limits have to be handled well, and the README argues that shards cannot communicate fast enough to handle them properly, while a single point of contact to the Discord API removes the problem. It also notes that numerous instances of a bot on different hosts can all connect to the same REST server.

The third benefit is continuity of queued work. The README makes the point that REST does not rest: separating it guarantees that queued requests keep being processed even if the bot breaks, and that updating or restarting a bot otherwise loses queued or processing messages and replies.

The last one is architectural. A bot dashboard can send requests from any location, directly, without the request travelling from dashboard to bot process to Discord, which frees the bot process to handle events.

The honest cost is operational. A separate REST server is a process you have to deploy, secure and keep reachable, and the README documents no simpler mode for teams that do not need it.

Proxy gateway updates and resharding without downtime

The gateway package has its own proxy design, and the README contrasts it with non-proxy bots.

On updates, the README says a non-proxy bot takes about 5 seconds per shard bucket to start up, so a bot on 100,000 servers faces a minimum of 8 or more minutes of downtime for a bot update. The Discordeno Proxy Gateway is described as resuming the bot code almost instantly, without wasting identify limits.

On resharding, the scenario is a bot started with 150 shards operating on 150,000 servers, where the shards support a maximum of 150 * 2500 = 375,000 servers. Discord stops letting a bot join new servers once that maximum is reached, so a resharding step becomes mandatory, and it is also the mechanism for moving to a new API version without downtime. The proxy provides automated and manual resharding, and both together.

The automated path starts the process in the background when you reach 80 percent of the maximum servers allowed by your shards, in the example at 300,000 servers. The README notes that the 80 percent threshold is customizable and that the requirement that identify limits have room for the resharding is also customizable. A manual trigger is available as well.

Turborepo, four runtime test suites and the example directory

The repository is a monorepo with the workspaces pattern over packages/*, managed with yarn. The root manifest declares the package manager as [email protected] and the module type as module, and it sets an engines requirement of node >=22.15.0. That node floor is worth noting before anything else, since it is stricter than many teams expect from a Discord library.

The build and test scripts all run through turbo, with separate tasks for unit tests on each runtime.

"build": "turbo build",
"test:unit": "turbo test:unit",
"test:deno-unit": "turbo test:deno-unit",
"test:bun-unit": "turbo test:bun-unit",
"test:integration": "turbo test:integration",
"test:e2e": "turbo test:e2e",
"check": "turbo check"

Running unit suites separately for Deno and Bun is the visible cost of the cross runtime claim, and it is a real one in terms of continuous integration time.

The examples directory is organised by audience rather than by feature, with minimal, beginner, advanced, bigbot and reaction-roles folders. The bigbot folder is the one to read if you are deploying at scale.

There is also a .env.example at the repository root.

DISCORD_TOKEN=
E2E_TEST_GUILD_ID=

Those two names are what the end to end tests expect, and the second one implies the tests need a guild you control.

Version 22 is still a beta and 21.0.0 is the last stable tag

The release history is the most important fact for anyone deciding what to install. The recent tags are 21.0.0 on 2024-12-28, 22.0.0-beta.1 on 2025-08-22 and 22.0.0-beta.2 on 2026-08-28. The root package.json version field reads 22.0.0-beta.2 and the package is marked private, so the published artifact version comes from the individual workspace packages rather than the root.

Two readings are possible and both are worth checking against your own plans. Either the 22 line is close enough to stable that many teams have moved, or the beta has been open long enough that you should look at what changed in the major version before committing. The gap between the two beta tags is over a year, which is long enough that the beta label does not tell you much about proximity to a final release.

The licence field on the repository says Apache-2.0, which is permissive and carries no copyleft obligation for a hosted bot.

On maintenance, the repository is not archived and the last push was on 2026-10-20. The README describes the project as actively maintained, and the presence of a hacktoberfest topic and per-package codecov badges is consistent with ongoing work. Whatever the version label says, the code is being changed.

Starting a bot with discordeno in four package managers

The README's getting started section is short, and the documentation site holds the detail. It lists four equivalent install commands for the bot package, one per package manager, which is what you would expect from a library that supports Node.js, Deno and Bun.

- npm install @discordeno/bot
- yarn add @discordeno/bot
- pnpm install @discordeno/bot
- bun install @discordeno/bot

The tip under the block invites you to check the feature list below before committing to the library, which is a fair warning given how much configuration the package split implies.

Two details to expect after installing. First, the credentials are not read from a config file format: the repository's own .env.example shows a DISCORD_TOKEN entry, so a token is the starting point. Second, the engines field requires node >=22.15.0, so check that before you start, not after the first failed run.

The remaining step, wiring the token into a client and registering event handlers, is documented on discordeno.js.org rather than in the README, so plan a trip to the docs site as part of the setup rather than expecting a copy and paste example from the repository root.

Editorial conclusion

discordeno fits teams that run a large bot on many hosts, that want REST and gateway traffic split across processes, or that need the same code on Node.js, Deno and Bun. It does not fit a small bot that wants one dependency and one process, because the package split means you assemble the pieces yourself and no caching is enabled by default. Before adopting it, confirm the version you install is the one you intend to ship, since 21.0.0 is the last tagged stable release and 22.0.0 is still published as beta tags, then read the proxy gateway setup before planning a resharding.

Frequently asked questions

Official sources

1. discordeno/discordeno on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases