DA

Danbooru

Self-hostable tag-based image board and gallery

Photo Management ★ 2.8k stars Hard setup MIT

Danbooru is the open-source software behind the well-known tag-based image board of the same name. It can be self-hosted to run a private, taggable image gallery with advanced search, pools, and a moderation system.

Key features

  • Tag-based image board
  • Advanced search syntax
  • Pools and favorites
  • Multi-user moderation

Pros & cons

Strengths

  • Powerful tagging system
  • Mature codebase

Trade-offs

  • Heavy resource needs
  • Complex to deploy

Danbooru replaces

Last reviewed Sep 13, 2026 · 847 words

Danbooru is the wrong tool for 9 out of 10 people who search for "self-hosted image gallery", and the only correct tool for the tenth. If what you want is your camera roll on your own disk, stop here and run Immich. If what you want is a collection of tens of thousands of images that must be findable by combinations of tags (character:x rating:safe -artist:y), with pools, favourites, tag aliases and a moderation queue, Danbooru is the most mature codebase on earth for that job, and you are about to pay for it with a 2 GB, multi-container Ruby on Rails deployment rated Hard for good reason.

It's a booru engine, not a photo manager

The software is the same code that runs the public site of the same name, which has been developed continuously since 2005, and the 2,804 GitHub stars understate how battle-tested it is. It has no face recognition, no map view, no mobile app that uploads your photos overnight. What it has is a tag model where tags have categories (artist, copyright, character, general, meta), implications (tagging cat_ears can imply animal_ears), aliases, and a search parser that handles negation, wildcards, ordering and metatags like width:>2000. The comparison in the catalogue to Pinterest and Eagle is fair only in the "organise reference images" sense; Danbooru is a database with a web front end, and it behaves like one.

Who actually runs it privately: illustrators and reference hoarders, small communities that want a private board, and archivists who have already outgrown folder names. The MIT licence matters for the community case, because you can strip the branding and modify freely.

The stack is five services before you upload a single image

The repository ships a Docker Compose file, and I would not attempt a deployment any other way. Expect, at minimum, the Rails app, PostgreSQL, Redis, an OpenSearch-family search engine for post queries, and an nginx front end, plus the image-processing toolchain (libvips, ffmpeg, exiftool) baked into the app image. The minRamMb figure of 2,048 MB in our catalogue is a floor for idle; a tag-heavy search across a large post table with OpenSearch resident wants 4 GB before it feels responsive. Budget a real x86 box, not a Raspberry Pi.

The setup order that works:

git clone https://github.com/danbooru/danbooru.git
cd danbooru
docker compose up -d
# then browse to http://localhost:3000

Check the logs the first time; migrations run on boot and take a minute. The first account created gets owner rights. Do that immediately, then close signups if this is private. Danbooru's config surface lives in config/danbooru_default_config.rb, and you override individual keys through environment variables prefixed DANBOORU_; read that file once end to end, because it documents 100-plus options nobody else will explain to you.

Where the complexity actually lives

Three places bite first-timers. Uploads go through a processing pipeline that generates preview, sample and original variants and writes them to a storage backend; if that path is not writable by the container user, uploads succeed in the UI and then 404. Tag implications and aliases are moderated by a request workflow designed for a site with thousands of contributors, so on a single-user instance you will approve your own requests, which feels odd until you find the direct admin actions. And upgrades track master; there are no version tags to pin, so an update is "pull, rebuild, migrate" and occasionally "read the commit log to learn what broke". Treat the database as the crown jewels and take pg_dump nightly.

Difficulty: Hard is honest. This is not a weekend project unless you already run Rails.

The alternatives that are easier and usually enough

If the tag search is the draw but a community is not, Hydrus Network is a desktop-first booru-style tagger that runs on a laptop and needs no reverse proxy. If the images are photos rather than artwork, Immich or PhotoPrism both offer labels, albums and a proper mobile experience with a fraction of the operational load, and the wider photos category has a dozen lighter options. Danbooru wins only when the tag vocabulary is the product and multiple people will maintain it.

What I'd do

For a private, single-user reference library under 20,000 images I would run Hydrus and never think about Rails. For a group board with three or more active taggers, a public or invite-only community, or an archive that will grow past 100,000 posts, I would run Danbooru from the Compose file on a 4 GB VPS or a spare mini PC, put Caddy in front for TLS, store originals on a disk you can grow, schedule a nightly pg_dump plus an rsync of the image directory, and update on a monthly cadence after skimming the commit log. Nothing else self-hostable searches tags this well; nothing else in this category costs this much attention either.

Compare Danbooru

1 head-to-head comparisons.

Similar photo management apps