danbooru/danbooru: Self-Hosting the Rails Image Board

What danbooru/danbooru Is, and Who It Is For

The repository describes itself as a taggable image board written in Rails. That single line carries the design: the tag is the primary object, and the image is what tags point at. Everything else in the codebase, from search to upload to moderation, is arranged around that relationship.

The intended audience is narrower than the phrase image board suggests. This is the source of a production site, published so that other people can run their own instance or contribute to it. The README points people at a Docker guide as the recommended way to run it, and at a manual installation guide that it explicitly calls much more difficult, not recommended, and not officially supported. If you want a board you install from a package manager and forget about, this is not that project.

It is also not only a web application. The README lists cloud services and microservices that certain features depend on: AWS for post and pool versions, Google Cloud for an optional BigQuery export, and separate IQDB, Reportbooru and Recommender services. A self-hosted instance is therefore a small constellation of processes, not one container.

The Tag-First Data Model and What Depends on It

Danbooru's value is the tag vocabulary. Tags are what make a large image collection searchable, and the application is built to treat them as first-class records with their own pages, aliases and categories. The repository layout reflects this: the application code lives under app/, with the database schema and migrations under db/, and the background jobs and models that maintain tag relationships are part of the same Rails application rather than a separate indexing layer.

The trade-off is that search quality is a function of curation discipline, not of the software. A fresh instance starts with an empty vocabulary, and the README does not describe any bootstrap tag set or import path. You either build the vocabulary yourself or you migrate one, and the repository does not document a supported migration path for that.

Some features are not implemented in this codebase at all. Post views, the missed searches report and the popular searches report are delegated to the Reportbooru service. Post recommendations require the Recommender service. Similar-image lookup is delegated to the IQDB service. That is a deliberate split, and it means a partial deployment produces a board where the core works and the discovery features are simply absent.

Installing Danbooru with Docker Compose

The README gives two Docker routes. The first is a one-line bootstrap that installs Docker Compose and starts the application:

sh -c "$(curl -sSL https://raw.githubusercontent.com/danbooru/danbooru/master/bin/setup)"

After that finishes, the README states that Danbooru is running at http://localhost:3000. Read the script before you pipe it into a shell, since it installs system packages.

The second route assumes Docker Compose is already present. Clone the repository, create the two local configuration files, and bring the stack up:

git clone http://github.com/danbooru/danbooru
cd danbooru
touch .env.local config/danbooru_local_config.rb
sudo docker compose up

The two touch commands matter. The docker-compose.yaml comments say to copy config/danbooru_default_config.rb to config/danbooru_local_config.rb, or .env to .env.local, and then edit them. Creating the empty files is the minimum; the defaults come from config/danbooru_default_config.rb.

There is also a browser route. The README links an Open in Github Codespaces badge, and the steps are to create a GitHub account, click the button, click Create new codespace, and wait a few minutes. The result is a full development environment with no local installation. For evaluating the tag model before committing to infrastructure, that is the cheapest path.

To tear everything down, the README gives these commands, and they are destructive:

sudo docker compose down --volumes # Delete all data and images in your Danbooru instance.
sudo docker image prune            # Clean up all unused Docker images.
rm -rf ~/danbooru                  # Delete the Danbooru code.

Backup, Restore and the Upgrade Path Are Compose Commands

The docker-compose.yaml file documents its own operations, which is more than many projects do. Upgrading is two commands:

docker compose pull
docker compose restart

Backup is three, covering the database, the images and the IQDB index:

docker compose run --rm -T danbooru bin/rails danbooru:database:backup > danbooru-database.pg_dump
docker compose run --rm -T danbooru bin/rails danbooru:images:backup > danbooru-images.tar
docker compose cp iqdb:/iqdb/data/iqdb.sqlite ./

Restore requires deleting the volumes first, then replaying the dumps into a fresh stack. That ordering is stated in the compose file and it is easy to get wrong: if you restore over an existing volume, you are not following the documented procedure.

The upgrade story is where the project's age shows. Recent releases listed for the repository stop in 2016, at 2.103.0. The last push to the default branch was on 2026-09-23, so the code is current even though the release tags are not. In practice the compose pull and restart pair is the upgrade mechanism, and there is no versioned artifact to pin against. The Dockerfile also carries a comment that .ruby-version and the Gemfile must be updated together when the Ruby version changes, and that those versions are used by bin/danbooru-dev-entrypoint to detect whether installed containers are outdated. Upgrading is therefore a container-image exercise, not a gem version bump.

Where a Self-Hosted Danbooru Breaks Down

The compose file says it plainly: it launches a minimal instance suitable as a quick demo or for personal use, and is not recommended for a large public-facing site. That is the project's own boundary, and it is the most useful sentence in the repository for anyone planning a deployment.

The dependency on AWS is the second constraint. The README explains that in production, for historical reasons, Danbooru relies on Amazon AWS to send pool and post versions to an SQS queue, with a separate archives service extracting them into a database. The compose files work around this with ElasticMQ as an SQS mock and a preconfigured archives service. That means the local stack is a simulation of the production topology. If you deploy without that simulation in place, version history is the feature that silently stops working.

Manual installation is a third boundary, and the README is blunt about it: much more difficult than Docker, not recommended, not officially supported. Anyone who cannot run Docker Compose is outside the supported path.

Finally, the licence situation deserves attention before you build on this. The repository metadata reports the licence as NOASSERTION, meaning GitHub could not classify the LICENSE file, while package.json declares MIT for the JavaScript package. Those two signals describe different scopes and the repository does not reconcile them. This is not legal advice; it is a reason to read LICENSE yourself before redistribution.

Alternatives and How They Differ

The obvious alternative is not another image board but a general-purpose media library. Software in that category typically organises files into albums and folders with metadata attached to each item, and search runs over those fields. Danbooru inverts the structure: tags are the organising principle and an image belongs to as many of them as apply, which is what makes queries like a combination of several tags possible in the first place. A folder-based library will not reproduce that without a tagging layer bolted on.

The other realistic alternative is not to self-host at all. The README links a Discord server and GitHub discussions as the support channels, and the Codespaces route exists precisely so that people can try the tag model without operating anything. If your goal is to understand how a tag-first board behaves, the Codespaces instance answers that question and the compose stack answers a different one.

Within the project's own family there is a further split worth naming. IQDB, Reportbooru and Recommender are separate repositories, not modules you can enable with a flag. Choosing this project means choosing its service topology, or accepting a board without reverse image search, view counts and recommendations.

Frequently Asked Questions About danbooru/danbooru

The questions below come from search data about the project and from what a new operator is likely to ask. Answers are limited to what the repository states.

Editorial conclusion

Adopt it if you want a tag-first image board you can run yourself and you are willing to operate Postgres, Redis, ElasticMQ and several companion services. Do not adopt it if you expect a packaged release, a managed upgrade path, or a board that works without a database and a background job runner. Before committing, verify what the docker-compose.yaml actually starts on your machine, read config/danbooru_default_config.rb for the settings you will need to override, and confirm that the licence file in the repository matches the MIT declaration in package.json.

Frequently asked questions

Official sources

1. danbooru/danbooru on GitHub
2. Issues
3. README
4. Releases