A to-be-released production-grade IPFS HTTP Gateway written in Go (using Boxo).
Rainbow is an implementation of the IPFS HTTP Gateway API, based on boxo which is the tooling that powers Kubo IPFS implementation. It uses the same Go code as the HTTP gateway in Kubo, but is fully specialized to just be a gateway:
- Rainbow acts as Amino DHT and Bitswap client only.
- Rainbow does not pin, or permanently store any content. It is just meant to act as gateway to content present in the network.
- Rainbow settings are optimized for production deployments and streamlined for specific choices (flatfs datastore, writethrough uncached blockstore etc.)
- Denylist and denylist subscription support is included.
- And more to come...
go build
rainbow
Use rainbow --help
for documentation.
Automated Docker container releases are available from the Github container registry:
- 🟢 Releases
latest
always points at the latest stable releasevN.N.N
point at a specific release tag
- 🟠 Unreleased developer builds
main-latest
always points at theHEAD
of themain
branchmain-YYYY-DD-MM-GITSHA
points at a specific commit from themain
branch
⚠️ Experimental, unstable buildsstaging-latest
always points at theHEAD
of thestaging
branchstaging-YYYY-DD-MM-GITSHA
points at a specific commit from thestaging
branch- This tag is used by developers for internal testing, not intended for end users
When using Docker, make sure to pass necessary config via -e
:
$ docker pull ghcr.io/ipfs/rainbow:main-latest
$ docker run --rm -it --net=host -e RAINBOW_SUBDOMAIN_GATEWAY_DOMAINS=dweb.link ghcr.io/ipfs/rainbow:main-latest
See /docs/environment-variables.md
.
Rainbow can be configured via command-line arguments or environment variables.
See rainbow --help
and /docs/environment-variables.md
for information on the available options.
Rainbow uses a --datadir
(or RAINBOW_DATADIR
environment variable) as
location for persisted data. It defaults to the folder in which rainbow
is
run.
Using a key file: By default generates a libp2p.key
in its data folder if none exist yet. This
file stores the libp2p peer identity.
Using a seed index: Alternatively, random can be initialized with a 32-byte, b58 encoded seed and a derivation index. This allows to use the same seed for multiple instances of rainbow, and only change the derivation index.
The seed and index can be provided as command line arguments or environment
vars (--seed
, --seed-index
). The seed can also be provided as a seed
file in the datadir folder. A new random seed can be generated with:
rainbow gen-seed > seed
To facilitate the use of rainbow with systemd
LoadCredential=
directive, we look for both libp2p.key
and seed
in
$CREDENTIALS_DIRECTORY
first.
Rainbow can subscribe to append-only denylists using the --denylists
flag. The value is a comma-separated list of URLs to subscribe to, for example: https://denyli.st/badbits.deny
. This will download and update the denylist automatically when it is updated with new entries.
Denylists can be manually placed in the $RAINBOW_DATADIR/denylists
folder too.
See NoPFS for an explanation of the denylist format. Note that denylists should only be appended to while Rainbow is running. Editing differently, or adding new denylist files, should be done with Rainbow stopped.
Rainbow ships with a number of possible blockstores for the purposes of caching data locally. Because Rainbow, as a gateway-only IPFS implementation, is not designed for long-term data storage there are no long term guarantees of support for any particular backing data storage.
See Blockstores for more details.
Over time, the datastore can fill up with previously fetched blocks. To free up this used disk space, garbage collection can be run. Garbage collection needs to be manually triggered. This process can also be automated by using a cron job.
By default, the API route to trigger GC is http://$RAINBOW_CTL_LISTEN_ADDRESS/mgr/gc
. The BytesToFree
parameter must be passed in order to specify the upper limit of how much disk space should be cleared. Setting this parameter to a very high value will GC the entire datastore.
Example cURL commmand to run GC:
curl -v --data '{"BytesToFree": 1099511627776}' http://127.0.0.1:8091/mgr/gc
While the logging can be controlled via environment variable it is also possible to dynamically modify the logging at runtime.
http://$RAINBOW_CTL_LISTEN_ADDRESS/mgr/log/level?subsystem=<system name or * for all system>&level=<level>
will set the logging level for a subsystemhttp://$RAINBOW_CTL_LISTEN_ADDRESS/mgr/log/ls
will return a comma separated list of available logging subsystems
Suggested method for self-hosting is to run a prebuilt Docker image.
An ansible role to deploy Rainbow is available within the ipfs.ipfs collection in Ansible Galaxy (https://github.com/ipfs-shipyard/ansible). It includes a systemd service unit file.
- Create a PR from branch
release-vX.Y.Z
againstmain
that:- Tidies the
CHANGELOG.md
with the changes for the current release - Updates the
version.json
file
- Tidies the
- Once the release checker creates a draft release, copy-paste the changelog into the draft
- Merge the PR, the release will be automatically created once the PR is merged
Dual-licensed under MIT Apache 2.0