REDbot
REDbot is lint for HTTP resources.
It checks HTTP resources for feature support and common protocol problems at the HTTP semantic and caching layers. You can use the public instance on https://redbot.org/, or you can install it locally.
Contributing to REDbot
Your ideas, questions and other contributions are most welcome. See CONTRIBUTING.md for details.
Setting Up Your Own REDbot
Installation
REDbot requires a current version of Python.
The recommended method for installing REDbot is using pipx. To install the latest release, do:
pipx install redbot
Or, to use the most development version of REDbot, run:
pipx install git+https://github.com/mnot/redbot.git
Both of these methods will install the following programs into your pipx binary folder:
redbot- the command-line interfaceredbot_daemon- Web interface as a standalone daemon
By default, redbot prints a text report for the URL. Use -o to choose another format: text_verbose adds an explanation of each note, and har produces an HTTP Archive (HAR) file. With -a (--assets), text and text_verbose also list the resources linked from an HTML response. The web interface accepts the same names in its format query argument (format=text, format=text_verbose, format=har).
Running REDbot as a systemd Service
REDbot can run as a standalone service, managed by systemd. This offers a degree of sandboxing and resource management, process monitoring (including a watchdog function), and a timer that garbage-collects saved tests.
See extra/README.md for the sample units and step-by-step setup.
Running REDbot in a Container
OCI-compliant containers are available on Github, and it's easy to run REDbot one using a tool like Docker or Podman. For example:
docker run --rm -p 8000:8000 ghcr.io/mnot/redbot
or
podman run --rm -p 8000:8000 ghcr.io/mnot/redbot
The daemon runs as an unprivileged redbot user (UID 999). Saving tests is off by default. To enable it, set save_dir = /var/lib/redbot in a config file that you mount into the container and pass as the command, and mount a named volume at /var/lib/redbot to keep the saved tests. The image provides that directory, owned by the daemon's user; a bind-mounted host directory must be writable by UID 999.
Web Bot Auth
REDbot can authenticate its outgoing requests using Web Bot Auth, which signs requests with an Ed25519 key using HTTP Message Signatures (RFC 9421). This lets origins verify that requests genuinely come from your REDbot instance. The implementation follows the IETF drafts and is not specific to any one verifier.
Requests are sent unsigned by default. REDbot only attaches a signature when the origin challenges for one -- that is, when it returns a 401, 403, or 429 response carrying an Accept-Signature header -- and then transparently retries the request signed. This avoids advertising the bot's identity to servers that don't ask for it.
Generating a key
Create an Ed25519 private key in PEM form:
> openssl genpkey -algorithm ed25519 -out web-bot-auth-key.pem
Keep this file private and readable by the REDbot process. The matching public key is published automatically (see below); you do not need to extract it yourself.
Configuring
Set these in config.txt (for redbot_daemon):
web_bot_auth_key = /path/to/web-bot-auth-key.pem
web_bot_auth_directory = https://your-redbot.example
web_bot_auth_directory is the HTTPS origin where your public key directory is hosted. When you run redbot_daemon, it serves that directory at /.well-known/http-message-signatures-directory (a JWKS, self-signed per the spec), so a verifier can fetch your public key. Make sure that path is reachable at the origin you configured.
web_bot_auth_directory is optional: if you omit it, REDbot uses the origin of ui_uri. Because ui_uri defaults to https://redbot.org/, enabling signing requires ui_uri to be set to your instance's real public origin — otherwise you would publish the wrong bot identity. Set web_bot_auth_directory explicitly if your key directory lives on a different origin than the UI.
For the command-line tool, pass the equivalent flags (there is no ui_uri, so the directory is required):
> redbot --web-bot-auth-key web-bot-auth-key.pem --web-bot-auth-directory https://your-redbot.example https://example.com/
Registering with a verifier
To be recognised by a specific verifier, register your directory URL with them according to their process.
Credits
Icons by Font Awesome. REDbot includes code from tippy.js and prettify.js.
1 maintainer
Metadata
1 maintainer
Release files for redbot 2.7.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| redbot-2.7.0.tar.gz | 339.3 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| redbot-2.7.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 714.2 kB
Release files / redbot-2.7.0.tar.gz
| Download URL | redbot-2.7.0.tar.gz |
|---|---|
| Size | 339.3 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
42e4005f47e323c868e496e254e34e80cc0e50250b42acf79a73f6f7417788af
|
|
BLAKE2b-256 checksum How to use checksums |
42a325a1d11819bf976afedccd94e584d389feaaee23f456f691bae965e6c0eb
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 16, 2026.
Transparency logRelease files / redbot-2.7.0-py3-none-any.whl
| Download URL | redbot-2.7.0-py3-none-any.whl |
|---|---|
| Size | 374.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
731afd0f1e282999693144adc4df53046ab19c355f5169e049d7fd762d0a02be
|
|
BLAKE2b-256 checksum How to use checksums |
33b948d6d09bbaabded38a9a6c955dede3c1987d0ef0da4271d9333b26882961
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 16, 2026.
Transparency log
