docker-redmine packages Redmine with the database choices left open

One image, several database choices

The repository holds a single Dockerfile but a family of compose files, and that is the shape of the project. There is a base `docker-compose.yml` with PostgreSQL, and separate ones for MySQL, MariaDB, SQLite 3, memcached, SSL, and an AWS variant. The Redmine side takes its database settings entirely through environment variables, with `DB_ADAPTER`, `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASS`, `DB_NAME` and `DB_SSL_MODE`, so the same image runs against any of the supported backends. The default compose file uses PostgreSQL with a `sameersbn/postgresql:14-20230628` image and a healthcheck that runs `psql -U postgres`, and the Redmine service waits for that container to report healthy before it starts.

The quick start is two compose commands

The documented quick start downloads the compose file and brings it up:

wget https://raw.githubusercontent.com/sameersbn/docker-redmine/master/docker-compose.yml
docker compose up

Or you can start the two services in order, which is what the guide actually shows, because the Redmine container must not start before the database is ready:

docker compose up -d postgresql
docker compose up -d redmine

The compose file already sets the `DB_NAME`, `DB_USER` and `DB_PASS` variables and the `/srv/docker/redmine/*` volume paths, and the guide says to edit that file first if you need different values. The application needs a minute or two to start, then you point a browser at `http://localhost:10083` and log in with the username and password both set to admin, and the guide tells you to visit the Administration link and load the default configuration before creating projects. The published images are on Docker Hub, and since version 2.4.2 the builds are tagged, so `docker pull sameersbn/redmine:7.0.2` gives you a specific version, and there are also builds on GitHub Packages as `ghcr.io/sameersbn/redmine`.

The image is a Ruby base with nginx, supervisor and a long apt list

The Dockerfile is built on `ruby:4.0-slim-bookworm` and sets a set of environment variables up front, including the Redmine version at 7.0.2, a dedicated `redmine` user, the home and log directories, the assets directory, and `RAILS_ENV=production`. The apt list is long because Redmine needs so much: supervisor, logrotate, nginx, the MySQL and PostgreSQL clients, sudo, tzdata, imagemagick, pandoc, subversion, git, several version control systems, rsync, locales, openssh-client, a compiler toolchain, and the library packages for XML, YAML, curl, SSL, uuid, xslt and zlib, plus ImageMagick and Ghostscript for image handling, sqlite3, jq and curl. The comment on curl is that it is used for the healthcheck, which is visible in the compose file as a `curl -f http://localhost/up` test. The layout splits the build assets from the runtime assets, and the install step runs a shell script from the build assets directory.

Twenty-odd environment variables control the application

The compose file is the configuration reference, and reading it tells you what the image lets you change. On top of the database block there is the timezone, the port, an HTTPS toggle, a relative URL root for deploying under a subdirectory, and a secret token. There is a sudo mode toggle with a timeout, which is a Redmine feature for letting users run commands as another user. There is a concurrent uploads setting, and a trio of backup settings for the schedule, the expiry and the time. Mail is disabled by default, with the SMTP method, domain, host, port, credentials and a starttls flag, and IMAP has the same shape for incoming mail. There is a maximum upload size for nginx, and the volumes mount the Redmine data directory and the log directory as host paths under `/srv/docker/redmine`.

TLS is a documented workflow, not a flag

The SSL section is a sequence rather than a setting, and that reflects how certificates have to be produced. The Makefile generates them with openssl: a 2048 bit RSA key, a certificate signing request, a self-signed certificate valid for 365 days, and the dhparam file. The README then covers generating self signed certificates, strengthening the server security, installing the certificates and enabling HTTPS, and configuring HSTS, plus the case of using HTTPS with a load balancer and the case of deploying under a subdirectory with a relative URL root. The section on using an Apache proxy as a frontend is there for people who need to run the application behind a different reverse proxy than the bundled nginx. The self-signed route is fine for a lab and not fine for a public deployment, which the separation between the two sections implies.

Backups, plugins and themes are part of the image

The maintenance and extension sections are where this repository does more than package an application. Backups can be created and restored, and there is an automated backup schedule driven by the `REDMINE_BACKUP_*` variables, with an expiry for old copies. Plugins can be installed and uninstalled, and there is a reload path for development so you do not have to rebuild the image for every change. The same pattern applies to themes. Rake tasks are available for maintenance, and the shell access section tells you how to get into the running container. The development section describes how to upgrade to the next Redmine release, which is the procedure you follow when a new upstream version lands and a new image tag is cut.

A warning about plugins, and how the releases work

The one piece of advice in the README that deserves attention is a postscript under the version heading: if your installation depends on various third party plugins, please stick with the 2.6.xx series to avoid breakage. That is an unusually honest statement from a project that ships current tags, and it tells you that the current line tracks upstream Redmine closely and will not carry compatibility shims for old plugins. The release history shows two lines in motion, with 7.0.2 and 6.1.5 both published on 2026-10-01 and 7.0.1 earlier in August, so the 6.x line is still maintained alongside the 7.x line. The build pipeline runs on GitHub Actions with a build workflow, the Makefile has targets for building, quickstart, stop, logs and purge, and there is a release smoke test that uses throwaway named volumes so it does not need sudo.

Editorial conclusion

Adopt docker-redmine if you want Redmine in a container with the operational details already solved, since the repository ships compose files for every common database plus the TLS, backup and mail configuration that most people get wrong. Do not adopt it for a large installation with many third party plugins, because the README itself advises staying on the 2.6.xx series in that case to avoid breakage. Verify first that you change the default admin credentials and the SMTP placeholders before exposing it, and decide whether you need the internal database container or an external managed one, since the compose files cover both.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sameersbn/docker-redmine on GitHub