Moebooru: a heavily modified danbooru1 running on Rails

A danbooru1 fork that stopped looking like one

Moebooru describes itself as an image board, and the project description says plainly what it is in relation to the software it came from: a fork of danbooru1 that has been heavily modified. That matters when you are evaluating it, because a fork usually means a slightly different set of features with the same architecture, and the word heavily suggests the difference is larger than that. The topic list of the repository mentions Ruby on Rails, PostgreSQL, ImageMagick and CoffeeScript, which is a picture of a server side application with a thin front end, and the code layout matches it, with an `app/` directory, a `config/` directory, a `db/` directory and a `public/` directory in the usual Rails arrangement. The licence is ISC, the default branch is master, and the last push was on 2026-10-10. The project publishes no GitHub releases, so the deployment story is a checkout rather than a version.

The stack, and the warning that it moves

The requirements are listed plainly: Ruby 3.3 or later, PostgreSQL 15 or later, the Bundler gem, node.js 20.0 or later, and ImageMagick, plus whatever the gems in the `Gemfile` need. The documentation also says that this is an ongoing project and that there will be more changes to the requirements as the project goes, which is an unusually direct warning that the target list itself is provisional. For RHEL there is a separate list of packages, marked as untested, including gcc, gcc-c++, git, jhead, libxslt-devel, libyaml-devel, nodejs, openssl-devel, pcre-devel and the PostgreSQL 15 development and server packages, and the note says the base, EPEL, dnf module and official PostgreSQL repositories contain everything needed. Two of those entries, jhead and ImageMagick, tell you what the image pipeline is doing, since both are about reading and rewriting image metadata and thumbnails.

The database user needs createdb

Setup starts with PostgreSQL. After the database is initialised, you create a user for the application, and the one requirement worth noting is that the user needs the `createdb` privilege, because the initialisation steps that follow create databases:

    postgres# create user moebooru_user with password 'the_password' createdb;

The password in the example is a placeholder, so any real deployment should set its own. This is a small step, but it is the one most often done wrong, since a user without `createdb` fails later during database reset with a permission error rather than at the point where the problem was introduced.

Development runs from a rake reset

The development setup is a short sequence of commands, and the order matters. You run `bundle install`, then create `config/database.yml` and `config/local_config.rb`, then initialise the database with `bundle exec rake db:reset`, then bring the schema up to date with `bundle exec rake db:migrate`, then start the server with `bundle exec rails server`, and finally start the asset builder with `npm run build -- --watch`. Two things stand out. The application is a standard Rails app with a normal `rails server`, so the usual Rails tooling applies. And the frontend is a separate build that runs in watch mode, which means the JavaScript is compiled by a node tool rather than served by the asset pipeline, and that you need both a Rails process and a node process running for a working development environment.

Configuration is halfway to environment variables

The configuration file for local settings is `config/local_config.rb`, and the project ships an example of it, `config/local_config.rb.example`. The documentation is candid that it is moving towards environment variable based configuration and lists the variables currently supported. `MB_DATABASE_URL` sets the database connection with the syntax `postgres://<user>(:<pass>)@<host>(:<port>)/<dbname>`, `MB_MEMCACHE_SERVERS` takes a comma separated list of memcache server addresses, `MB_PIWIK_HOST` sets the host the application will try to contact for analytics and defaults to false when unset so Piwik is not used, `MB_PIWIK_ID` sets the site ID analytics data is sent for, and `MB_THREADS` sets the number of application threads, which is currently used to size the memcached connection pool and defaults to 1. That last one is a quiet performance lever: the default pool is one connection, so a deployment with concurrency needs it raised.

The list is short and the direction is clear, which is a hint that this configuration surface is not finished. Anything not in the five variables above still lives in the local config file, so a deployment has to use both mechanisms.

The frontend is a small esbuild bundle

The JavaScript side is modest, which suits an image board where the pages are server rendered. The package manifest lists esbuild with a less plugin as the build tool, jQuery as the DOM library, and a set of small libraries that each do one thing: autocompleter for search suggestion, cropperjs for image cropping, timeago for relative timestamps, js-cookie for cookies and mousetrap for keyboard shortcuts. The build script is a `build.js` file at the repository root, the lint step runs semistandard over the root JavaScript, the application JavaScript and the assets directory, and the package is declared as an ES module. The presence of cropperjs and autocompleter tells you that the heavy interaction is concentrated in the upload and search flows, which is where an image board actually needs JavaScript, and the absence of a framework dependency is consistent with the Rails server rendering the pages.

Editorial conclusion

Moebooru suits an operator who wants to run an image board with a Rails codebase they can read, where the PostgreSQL and ImageMagick requirements are acceptable and the frontend is a modest esbuild bundle rather than a modern SPA. It is a poor fit if you need the danbooru1 feature set, because the fork is described as heavily modified and the documentation here does not catalogue what was kept and what changed, and it is a poor fit for a host without ImageMagick and a memcached instance. Before deploying it, read config/local_config.rb.example, decide how much of the configuration you want in environment variables, since the list of supported variables is short and still growing, and create the database user with the createdb privilege the setup instructions ask for, because the initialisation step needs it.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. moebooru/moebooru on GitHub
4. README