RoboDanny: the source of a personal Discord bot kept for study

The maintainer asks you not to run your own copy

RoboDanny is described as a personal bot that runs on Discord, and the description in the repository says it is a bot for servers the author likes. That framing matters more than usual here, because the running instructions say something no README usually says: the author would prefer that you do not run an instance of the bot, and instead invites you to use the join command with an invite URL so it can be on your server.

The stated reason for publishing the source at all is educational, specifically as an example of discord.py.

That is a clear division between what the project is and what it is not. It is not a community bot framework, it is not a product you deploy and operate for your own server, and there is no configuration guide or support commitment attached to it. The value is in the code: how a real bot of several thousand lines is put together.

The repository layout supports that reading. There is a `bot.py` entry point, a `launcher.py` that also handles database setup, a `cogs/` directory holding the features, a `migrations/` directory for the database schema, and the usual project files. The structure is a textbook discord.py application layout, which is exactly why it is useful to read.

The default branch is `rewrite`, which suggests the active development line is a rewrite of the bot rather than the code that runs the author's servers, and there are no GitHub releases, so there is no versioned artefact to install.

Cogs are the unit of feature organisation

The `cogs/` directory is where the features live, and the configuration template gives you a glimpse of what those features are.

The config file mentions a bot statistics webhook, a GitHub API personal token, an Open Collective personal token, the client id and client secret for the Open Collective Discord Integration application, a Challonge API key for the tournament cog, and keys for carbon's site and for bots.discord.pw. Each of those corresponds to a cog.

The tournament cog in particular tells you something about the project's character: this is a bot for communities that run esports tournaments, with Challonge as the bracket service. The Open Collective integration suggests community funding and sponsorship workflows. The GitHub token suggests the bot reads repositories, and the stats webhook suggests it reports its own activity to a channel.

The configuration template is the fastest way to understand a bot like this, because every key is a feature. Here is the template as the documentation gives it:

client_id   = '' # your bot's client ID
token = '' # your bot's token
debug = False # used to disable certain features
carbon_key = '' # your bot's key on carbon's site
bots_key = '' # your key on bots.discord.pw
postgresql = 'postgresql://user:password@host/database' # your postgresql info from above
challonge_api_key = '...' # for tournament cog
stat_webhook = ('<webhook_id>','<webhook_token>') # a webhook to a channel for bot stats.
# when you generate your webhook, take the token and ID from the URL like so:
# https://discord.com/api/webhooks/<id>/<token>
github_token = '' # your github API personal token
open_collective_token = '' # your open collective personal token
oc_discord_client_id = '' # the client ID of the Open Collective Discord Integration application
oc_discord_client_secret = '' # the client secret of the Open Collective Discord Integration application

The `debug` flag is annotated as being used to disable certain features, which is a common pattern for a bot that has grown a lot of optional behaviour.

And the documentation says something worth repeating: a lot of these configuration variables are undocumented precisely because the bot is meant for personal use. That is the clearest statement of the project's scope in the whole README.

PostgreSQL with migrations, and the pg_trgm requirement

The data layer is PostgreSQL, and it is set up before the bot is configured, because the migrations run against it.

The requirements are PostgreSQL 9.5 or higher and three statements in the `psql` tool:

CREATE ROLE rdanny WITH LOGIN PASSWORD 'yourpw';
CREATE DATABASE rdanny OWNER rdanny;
CREATE EXTENSION pg_trgm;

The `pg_trgm` extension is the one to notice. It provides trigram similarity matching, which is what a bot uses to implement fuzzy search over names, and it has to be installed before the migrations that depend on it. Creating the role and the database with an owner is also the standard pattern so that the bot's connection string can authenticate as a non-superuser.

After the configuration file exists, the schema is prepared with the launcher:

python3.8 launcher.py db init

The `migrations/` directory at the repository root holds the migration scripts, and the launcher has a `db` subcommand for the database lifecycle. That structure, a dedicated launcher with database commands and a migrations directory, is the pattern that scales, and it is the part of this repository that transfers most directly to a bot you write yourself.

The connection string goes in the config as `postgresql = 'postgresql://user:password@host/database'`, and the driver in the requirements is `asyncpg>=0.12.0`, so the database access is asynchronous, matching the async model of discord.py.

The setup path is Python 3.8, a venv, and a pinned git dependency

The installation steps are short and the runtime requirement is explicit: Python 3.8 or higher, described as required to actually run the bot.

The environment is a virtualenv:

python3.8 -m venv venv

and the dependencies come from the requirements file:

pip install -U -r requirements.txt

The requirements file is where the interesting dependency sits. Alongside `discord.py[speed]>=2.3.1`, `asyncpg>=0.12.0` and the usual utility libraries, there is a git dependency pinned to a specific commit:

git+https://github.com/Rapptz/discord-ext-menus@fbb8803779373357e274e1540b368365fd9d8074

That is a fork of the discord-ext-menus extension library, pinned by commit hash rather than by version, installed straight from GitHub. Pinning to a commit hash is the more precise way to reference a fork, because a branch can move and a tag can be republished, while a commit hash identifies one tree exactly. It also means the build depends on that repository remaining reachable.

The `discord.py[speed]` extra is worth noting for anyone reading the code. It installs the uvloop and similar components that make the async event loop faster, which matters for a bot that has to handle a lot of gateway traffic.

One more dependency tells you about the codebase: `pygit2` is a Python binding to libgit2, which means some part of the bot works with git repositories directly. That is consistent with the GitHub integration.

The tooling config says what kind of codebase this is

The pyproject.toml holds the formatting and type checking configuration, and reading it tells you how the code was written.

Black is configured with a line length of 125 and `skip-string-normalization = true`, so single quotes are preserved rather than rewritten to double quotes. isort uses the black profile with a line length of 125 and combines as imports and star imports.

Pyright is configured with `typeCheckingMode = "basic"`, pythonVersion 3.8, and `reportUnnecessaryTypeIgnoreComment = "warning"`, which is a nice touch because it catches type ignore comments that are no longer needed. The strictParameterNoneValue option is off, and the include list covers `cogs` and `cogs/utils`, meaning the type checker is pointed at the feature code rather than the whole tree.

A 125 character line length is noticeably wide, and it is a signal about the original style: this is code where lines were allowed to run long rather than being broken up aggressively.

The licence is MPL-2.0, with the licence text in LICENSE.txt. That is a file-level copyleft licence, so if you take individual files from this repository into a larger work, those files remain under MPL-2.0. This is a description of the licence terms, not legal advice.

The repository is not archived and the last push was on 2026-06-10, so the rewrite branch is still receiving work.

What a privacy statement from 2020 looks like, and what it does not cover

The README carries a section for the privacy policy and terms of service, and explains why: Discord requires the bot author to have one.

The whole content is short. It says there is not really anything to note and that no personal data is stored.

That claim sits next to a configuration template containing a database connection string, a GitHub personal access token, an Open Collective personal token, a Discord client id and client secret, and a stats webhook. Whether personal data is stored is a question about what the cogs write to PostgreSQL, and the visible documentation does not describe the schema beyond the migrations directory, so the statement cannot be checked from what is here.

The likely reading is that the personal data in question is Discord user data held transiently in the database for command state, rather than a retained record of individuals. The bot is described as a personal bot for the author's own servers, which is a different data protection posture from a public service with users who did not choose to be in the database.

If you are reading this repository because you want to run something similar for a community, the point to take is narrow and practical: the privacy statement is not a model to copy, it is a sentence written for a personal bot on the author's own servers. Anyone running a public bot needs to write their own statement that describes what their cogs actually store.

Editorial conclusion

Adopt RoboDanny as a reading reference if you are learning discord.py and want a real bot with migrations, cog structure and integrations rather than a tutorial snippet, and treat the source as an example rather than a product. Do not try to deploy it as your own service, since the maintainer explicitly asks that you not run an instance and leaves most configuration undocumented. Verify first that Python 3.8 or higher, PostgreSQL 9.5 or higher and the pg_trgm extension are available to you, and that you can supply the bot token and client id the configuration expects.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. Rapptz/RoboDanny on GitHub
4. README