A Bitnami Redmine stack is a good way to get Redmine running in an afternoon and a poor way to run it for five years. RedminePRO takes the whole thing over — including the stepped upgrade from whatever version you are stuck on — and the upgrade problem stops being yours.
A Bitnami stack is a self-contained bundle — its own Apache, its own Ruby, its own MySQL or MariaDB, all under one directory tree — which is exactly what makes the install easy and the upgrade hard. If you are reading this, the usual sequence has probably already happened: somebody stood up a Bitnami image, it worked, it kept working, and now it is three or four Redmine versions behind, the person who built it has moved on, and the upgrade path looks like a weekend nobody wants to spend. RedminePRO takes it over, as part of our done-for-you Redmine migration service.
Nothing about a Bitnami install is bad engineering. The burden comes from the bundling model.
The result is a system that runs fine right up until the day it has to change, and then it is a project.
You do not need to know this to migrate — we do the extraction — but knowing it makes the handover conversation short, and it tells you what you are actually responsible for backing up. A Bitnami stack keeps everything under one root, conventionally /opt/bitnami:
| What | Typically found at | Why it matters |
|---|---|---|
| The Redmine application | /opt/bitnami/redmine | Plugins, themes and any core files somebody edited |
| Attachments and uploaded files | redmine/files | Your file data — NOT in the database; a dump alone misses it |
| Database credentials / adapter | config/database.yml | Tells you MySQL/MariaDB vs PostgreSQL, and the DB name |
| Redmine configuration | config/configuration.yml | Mail settings, attachment path, SCM paths |
| Installed plugins | redmine/plugins | The list we audit |
| Database files | mariadb/data or postgresql/data | Do not copy raw — take a dump instead |
| Web server config | apache2/conf | Where your TLS certificate and vhost live |
| Stack version marker | properties.ini | Which stack generation you are on |
Layouts vary between stack generations and between the native installer, the VM image and the container image — containerized Bitnami Redmine typically persists to a mounted /bitnami/redmine volume instead. If your paths don't match, that is normal; send us ls output and we'll work it out.
What we ask you for: a database dump (mysqldump or pg_dump, not the raw data directory); an archive of the files/ directory; the contents or listing of the plugins/ directory; and your Redmine version from Administration → Information. That is the whole handover — three artifacts and a version number.
1. Assessment and plugin audit. Send the plugin list and the version. We come back within one business day with a written audit: which plugins run on the current Redmine version, which have a maintained successor, which are dead. On a stack a few years behind, expect at least one casualty. Better to know now.
2. Dump and transfer. You produce the database dump and the files archive. Your stack keeps running the entire time — nothing about this step touches production.
3. Restore and upgrade. We restore your data and run the Redmine upgrade path from your version to the current supported one. This is the part that would have been your weekend. Anything that fails does so on our copy, not your production system.
4. Dry run and validation. You get a working instance with your data and an admin login. Check the projects that matter, open attachments, run your saved queries, confirm the issue history reads correctly. Re-run as many times as needed.
5. Cutover. Final delta sync, DNS switch. Typical downtime: minutes, scheduled when you choose.
6. Decommission on your schedule. Your Bitnami box stays exactly where it is until you decide to turn it off. We never touch it.
On a Bitnami stack, a Redmine upgrade means standing up a new stack, moving the database and files, re-testing every plugin, and cutting over — and if it fails at step four you are restoring from a backup at midnight. That cost is why instances sit three versions behind. It is not negligence; it is a rational response to a bad ratio of risk to benefit.
On RedminePRO, upgrades are ours. They happen continuously and invisibly, they are tested before they reach you, and plugin compatibility is our problem to solve rather than yours to discover. You keep full Redmine administrator access to your instance, but the Ruby version, the database engine, the web server and the Redmine core underneath it stop being things you have to think about. It runs on AWS in US, EU or India, your choice at signup, with AES-256 encryption at rest via AWS KMS, TLS 1.2+ in transit, and continuous encrypted backups with point-in-time recovery. From $24/month for up to 25 users, unlimited projects on every plan. And if you ever want to go back: full database dump and files archive on request, any time. Managed Redmine hosting · Managed vs self-hosted.