# szurubooru: An Image Board Engine for Small Communities > Szurubooru is a Danbooru style image board engine written for small and medium communities, with a JSON REST API, token based client authentication, a full tagging system with categories, implications, aliases, pools and duplicate detection, and a Docker Compose deployment of a server, a client and PostgreSQL. **rr-/szurubooru** — Image board engine, Danbooru-style. - Repository: https://github.com/rr-/szurubooru - Stars: 1,024 · Forks: 241 - Language: Python - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/rr-szurubooru ## A Board Sized for a Community, Not a Platform Szurubooru is an image board engine inspired by services such as Danbooru, Gelbooru and Moebooru, dedicated for small and medium communities. That word dedicated is the positioning. The large booru services are built for very large catalogues, thousands of users and a moderation workload that needs a large organisation behind it. Szurubooru takes the same shape of application and scales it down to the size where a community runs its own instance. The name has roots in Polish and has an onomatopoeic meaning of scraping or scrubbing, and it is pronounced as shoorubooru. The name suits the design, because the entire data model is organised around the act of tagging. The feature list is a complete description of a booru. Post content covers images in JPG, PNG, GIF and animated GIF, videos in MP4 and WEBM, and Flash animations. There are post comments, post notes and annotations including arbitrary polygons, post rating and favouriting, comment rating, and a rich search system with a rich privilege system. The interface has browser configurable endless paging and a browser configurable backdrop grid for transparent images. What is missing is as telling as what is there. There is no global search federation, no public account system and no activity feed, because those are features of scale that a small community does not need. ## Tagging Is the Data Model, Not Just a Label The tag features are the heart of the engine, and they are more than a string on a post. Autocomplete works both in search and while editing tags, which is the difference between a tag field and a tag system. Tag categories let a community decide which tags are meaningful in which dimension, so a search can filter on a category rather than on a flat namespace. Tag suggestions help with the discovery problem, and tag aliases handle the case where the community has not agreed on one spelling. Tag implications are the feature that separates a booru from a folder of images. Adding a tag automatically adds another, which is how a community encodes a rule such as a character always implying its series. It is a small declarative mechanism with a large effect on how the archive stays navigable, because the alternative is a moderator writing the same implication by hand on every upload. Pools and pool categories extend the idea from a single tag to a curated set. A pool is a deliberate grouping, and the categories let a community organise pools against each other, which is how a board supports both the canonical set and a seasonal or thematic one. Duplicate detection closes the loop, because on a board where the same image is posted twice by accident, a search that returns it twice is a search that has failed. ## A JSON REST API With Token Authentication for Clients The engine exposes a rich JSON REST API, documented separately in doc/API.md, and uses token based authentication for clients. The two decisions are related. A JSON API with token authentication is the shape that a separate front end can use, and the repository is indeed split into a client/ and a server/ directory with the compose file running them as two images. The token model also suits the deployment, because the client container is a static front end and the server container is the API, and a token is a credential a script can hold rather than a session a browser manages. The privilege system is what the tokens are checked against. A rich privilege system means the API is not just read and write but a set of capabilities, which is what a community board needs when some users can delete posts and others cannot, or when a moderator needs to edit tags on someone else's upload. The API documentation is a separate document from this README, so the specifics of the endpoints and the token model live there. ## Client, Server and PostgreSQL in Three Containers The recommended deployment is Docker, with the installation instructions in doc/INSTALL.md, and the compose file in the repository is a working template. The stack is three services. The server image is szurubooru/server:latest, the client image is szurubooru/client:latest, and the database is postgres:11-alpine with a restart policy of unless-stopped. The server depends on the database and the client depends on the server, so the ordering is handled by compose. The configuration is a set of environment variables on each service. The server takes POSTGRES_HOST, POSTGRES_USER and POSTGRES_PASSWORD, with the database name defaulting to the same as the user and the port defaulting to 5432, plus LOG_SQL for verbose SQL logging and THREADS for the worker count. The client takes BACKEND_HOST, which points at the server service, and BASE_URL, which is what the browser is told to call. Storage is the part to think about. Both services mount a data directory, the server with write access and the client read only, and the database has its own mount for the PostgreSQL data directory. The media lives outside the containers, so a container can be replaced without losing the archive, and the compose file parameterises the mount points through environment variables rather than hard coding paths. ## Reading Media From the Web, and What It Still Accepts Two media features are worth pulling out, because they show what the engine is for. The first is the ability to retrieve web video content using yt-dlp. A community board is often a link archive as much as an upload repository, and letting the server fetch a remote video means the copy is hosted alongside the other posts rather than being a link that can rot. The dependency is named in the feature list and points at the yt-dlp project. The second is Flash animations, which is listed alongside the image and video formats. That is a legacy format, and its presence says something about the age of the codebase and the kind of archive the project serves. The formats in total are images in JPG, PNG, GIF and animated GIF, videos in MP4 and WEBM, and Flash animations. The picture and video browser, the notes and annotations with arbitrary polygons, and the WeChat style picture and video picker in the client are the other user-facing pieces around that media. The screenshots in the README show the post list and the post view, which is the two screens any booru is judged on, since that is where the tagging, the rating and the metadata all come together. ## The Release Line and What the Version Numbers Say The release history is old and small. The tags are 2.5 from 2021-06-05, 1.1.0 as Last boss from 2016-04-13, and 1.0.2 as Minor UI enhancements from 2016-04-13. The codenames are worth a moment, because they show how the project communicated. 1.0.2 is named Minor UI enhancements and 1.1.0 is named Last boss, which suggests a project that shipped a big structural change and named it, and then a much larger gap followed before 2.5 arrived. The repository is not archived and the last push was on 2026-07-27, so work is still landing in the tree even though the published version line has not moved in a long time. There are no GitHub releases, and the licence is GPLv3 with the text in LICENSE.md. For an evaluator, the practical conclusion is that this is a maintained codebase with a slow release cadence, which is a common pattern for a project whose users are a handful of communities running their own instances. The risk is not that the code is abandoned, it is that the compose file still points at a Postgres 11 image and a stack that predates current container practice, so the deployment is where the age shows rather than in the application logic. ## Conclusion Szurubooru fits a small community that wants its own board with a proper tag taxonomy rather than a generic gallery with upload, and that is comfortable running three containers and a PostgreSQL database. It is a poor fit for a single user or a small archive, because the whole architecture is built around a multi-user site with a privilege system, and it is a poor fit for a team that wants a managed service, since there is none. Before deploying, read the installation instructions in doc/INSTALL.md, and note that the compose file expects a Postgres 11 image and a separate data mount for the media, and that the version line has not moved much since 2.5 in 2021 even though the repository is not archived. The project is GPL-3.0 licensed, the last push was on 2026-07-27, and it publishes no GitHub releases. ## FAQ ### What is szurubooru? It is an image board engine inspired by Danbooru, Gelbooru and Moebooru, dedicated for small and medium communities. It supports images, videos and Flash animations, comments, notes and annotations, a JSON REST API, token based client authentication, a rich search and privilege system, and a full tagging system with categories, implications, aliases, pools and duplicate detection. ### How do I deploy szurubooru? Docker is the recommended route, with the instructions in doc/INSTALL.md. The compose file runs three services, szurubooru/server:latest, szurubooru/client:latest and postgres:11-alpine, with the media stored in a data mount shared by the two application containers and the database in its own volume. ### What are the tag features in szurubooru? Autocomplete in search and while editing tags, tag categories, tag suggestions, tag implications where adding a tag automatically adds another, tag aliases, pools and pool categories, and duplicate detection. Post rating and favouriting, comment rating and a rich privilege system are also part of the feature set. ### Can szurubooru pull in web videos? Yes. The feature list includes the ability to retrieve web video content using yt-dlp, so a remote video can be fetched and stored alongside the other posts rather than only being linked. ### How current is the szurubooru release line? The most recent tag is 2.5 from 2021-06-05, with 1.1.0 and 1.0.2 from April 2016 before it. The repository is not archived and the last push was on 2026-07-27, and the project publishes no GitHub releases. ## Sources - [Issues](https://github.com/rr-/szurubooru/issues) - [License: GPL-3.0](https://github.com/rr-/szurubooru/blob/master/LICENSE) - [README](https://github.com/rr-/szurubooru/blob/master/README.md) - [Releases](https://github.com/rr-/szurubooru/releases) - [rr-/szurubooru on GitHub](https://github.com/rr-/szurubooru) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rr-szurubooru