Redmine is free open-source software, so self-hosting costs you nothing in licensing and everything in server, sysadmin time, upgrades, backups and patching. This page gives you a line-by-line checklist to price your own situation, states RedminePRO's flat price against it, and is straight about the cases where self-hosting is still the right call.
Both halves of that sentence are true and the second half is the one that gets skipped.
Redmine is a mature open-source project. You can download it today, install it on a server you already own, and never pay anyone for a license. There is no seat count, no feature gate, no renewal, no vendor. For a certain kind of team that is the whole argument, and it is a good one.
What you take on with it is an application. Redmine is a Ruby on Rails app with a database behind it, a web server in front of it, mail going out of it, and attachments piling up inside it. Somebody has to own each of those layers — not once, at install, but continuously, for as long as the team uses the tool. That ownership is the cost. It does not appear on an invoice, which is exactly why it gets left out of the comparison.
Managed Redmine hosting is a decision to convert that ownership into a line item. You stop paying in engineer-hours and start paying in dollars. Whether that is a good trade depends entirely on what an engineer-hour costs you and how many of them this consumes, which is what the next section is for.
We are not going to publish a total-cost-of-ownership benchmark for self-hosted Redmine. Your server prices, your engineers' rates and your risk tolerance are yours, not ours, and a vendor-supplied average with our name on it would be worth exactly what you paid for it.
Here is the checklist instead. Fill in the right-hand column with your own figures and add it up. It takes about ten minutes and the number at the bottom is the only one worth comparing against a price.
| Line item | How to price it | Your monthly figure |
|---|---|---|
| Application server | Your VPS or EC2 instance for the Redmine app, at production size | — |
| Database | Managed database instance, or its share of the server if co-located | — |
| Storage that grows | Disk for attachments and the database, priced at next year's size | — |
| Backup storage | Off-site copies for your retention window, plus restore egress | — |
| Monitoring and alerting | Uptime checks, log retention, and whatever pages someone at 3am | — |
| TLS certificates | Free with automated renewal, or paid if your policy requires it | — |
| Outbound email | SMTP relay or transactional email so notifications don't land in spam | — |
| Staging instance | The second environment you test upgrades on (write “0” and note the risk if none) | — |
| Infrastructure subtotal | — | — |
| Line item | How to price it | Your monthly figure |
|---|---|---|
| Routine administration | Hours/month × loaded rate: user admin, plugin config, housekeeping | — |
| Security patching | OS and dependency CVEs. Hours/month × rate, averaged across the year | — |
| Backup verification | Hours actually restoring a backup and confirming it worked | — |
| Labor subtotal | — | — |
| Line item | How to price it | Your monthly figure |
|---|---|---|
| Redmine version upgrades | Upgrades/year × hours each × rate, including plugin testing | — |
| Ruby / Rails / gem upgrades | Major runtime upgrades/year × hours each × rate (the weekend ones) | — |
| Incident response | Realistic outage hours/year × rate, plus the work that stopped | — |
| Migration or rebuild | Hours to move to new infrastructure, spread over the years between moves | — |
| Annualized subtotal ÷ 12 | — | — |
Total: infrastructure + labor + annualized ÷ 12 = your real monthly cost of self-hosted Redmine. Three things that are not rows in that table and belong in the decision anyway:
Our side of the comparison is short, because the whole point of the model is that there is only one number.
| Plan | Price | Users | Projects |
|---|---|---|---|
| Startup | $24/mo | Up to 25 | Unlimited |
| Plus | $49/mo | Up to 100 | Unlimited |
| Business | $169/mo | Up to 250 | Unlimited |
| Enterprise | Custom | Unlimited | Unlimited |
Source: redminepro.com/pricing, verified 28 July 2026. Annual billing is exactly ten months' cost, marketed as two months free. Registered non-profits get 30% off the Business plan.
What that price covers, so you can strike the matching rows off your checklist: the server, the database, the storage, the TLS certificates, the monitoring, the outbound mail, the Redmine version upgrades, the Ruby and Rails upgrades, the operating-system patching, continuous encrypted backups with point-in-time recovery, and 24x7 support on every plan including Startup.
What it does not remove from your side: user administration, project configuration, trackers, workflows, custom fields and plugin choices. Those stay yours, because you get full Redmine administrator access on every plan. We take the machine, not the admin panel. If a managed host takes both, you have paid to lose control of your own tracker, which is a bad trade at any price. Compare the total at the bottom of your checklist against $24, $49 or $169. If your number is lower, self-host. We mean that. Full pricing and plan comparison.
There are real cases here, and a comparison page that pretends otherwise is not worth reading.
You already have an ops team with spare capacity. If you run a platform team that already operates Rails applications, has a patching cadence, has monitoring, and has a tested restore process, then Redmine is one more app on infrastructure you are already paying for and already staffing. Your marginal cost is close to your infrastructure cost, and most of our checklist collapses to near zero. Self-host it.
You need air-gapped or on-premises deployment. Some regulated environments, defense work and public-sector contracts require the application to run on a network with no route to the internet, or on hardware inside a specific building. No managed cloud service can meet that, ours included. If that is your requirement, the decision has already been made for you.
Your data is not permitted to leave your own hardware. Related but distinct: some contracts and national rules put the constraint on physical custody of the data rather than on network isolation. RedminePRO runs on AWS in US, EU or India and your data resides in the region you choose, which satisfies a lot of data-residency requirements — but it does not satisfy “on our own metal”, and we are not going to claim it does.
You want to modify Redmine core. Not install plugins — modify the source. If you are patching Redmine itself to fit a workflow nobody else has, you need to own the deployment, because you now own a fork and its upgrade path. That is a legitimate engineering decision and managed hosting is the wrong shape for it.
You have very few users and the overhead is trivial. Six people, one project, a small instance on a server that already exists, no compliance obligations, and an engineer who does not mind. The overhead is real but small, and $24/month for 25 seats you will never fill is not obviously the better deal. Flat pricing pays off when you grow into it.
If none of those five describe you, the checklist above is probably telling you something. Our comparison of every Redmine hosting provider.
Self-hosted Redmine does not fail on day one. Installation is the easy part and it is why the decision gets made. These are the things that arrive later, in roughly the order teams meet them.
Version upgrades with plugin incompatibility. Redmine ships new versions. Your plugins were written against an older one. The upgrade itself is usually straightforward; the afternoon spent working out which of your six plugins now throws on boot, and whether the maintainer of the abandoned one is coming back, is not. Every upgrade is a small compatibility project, and the longer you defer it the larger the jump becomes.
Ruby and Rails dependency drift. Underneath Redmine is a Ruby runtime and a Rails version, both of which reach end of life on a schedule you do not control. Once your Ruby is out of support you stop getting security fixes for it, and the upgrade you have been deferring becomes mandatory and large at the same time. This is the single most common reason a neglected Redmine instance becomes a rebuild rather than an upgrade.
Database growth and performance. Redmine's journal table grows with every field change on every issue, forever. Attachments accumulate on disk. Three years in, the issue list is slow, the search is slower, and the fix is index tuning and archival strategy — a database job, not a Redmine job. Nobody budgets for it because on day one the instance is fast.
Backups that have never been restored. A nightly dump to the same volume as the database is not a backup, and a backup that has never been restored is a hypothesis. The moment you need it is the moment you find out whether the attachments directory was included. Point-in-time recovery — restoring to 14:19 because someone bulk-edited 400 issues at 14:20 — is meaningfully harder to build than a cron job.
Unpatched CVEs. Redmine, Rails, the Ruby runtime, the web server and the operating system each publish security advisories. On an internet-facing instance holding customer data, staying current is not optional, and it is somebody's unbudgeted evening several times a year. The failure mode is silent right up until it isn't.
Email deliverability drift. Notification mail is the thing that makes a tracker part of the workflow instead of a website people forget to check. SPF, DKIM and DMARC alignment on a self-managed relay decays quietly, and by the time someone says “I never got the email” the team has already stopped trusting it.
The person who set it up leaves. Everything above is fine while the one person who understands the deployment is still there.
| RedminePRO | Self-hosted Redmine | |
|---|---|---|
| Software license | Included | Free, open source |
| Monthly cost | $24 / $49 / $169 flat, by plan | Your checklist total |
| Users at entry price | 25 | Unlimited, subject to your server |
| Projects | Unlimited on every plan | Unlimited |
| Server, database, storage | Ours | Yours |
| Redmine version upgrades | Ours | Yours, incl. plugin compatibility testing |
| Ruby / Rails / OS patching | Ours | Yours |
| Backups | Continuous, encrypted, point-in-time recovery | Yours to build, and yours to test |
| Uptime | 99.9% SLA on Business; 99.99% target sitewide | Your infrastructure and your on-call |
| Full Redmine admin access | Every plan, from Startup | Yes, plus root |
| Install your own plugins | Yes, on your instance | Yes |
| Modify Redmine core | No | Yes |
| Air-gapped or on-premises | No | Yes |
| Data location | AWS US, EU or India, chosen at signup | Wherever you put it |
| Support | 24x7 support on every plan | Community forums, or whoever you hire |
| Exit path | Files and database on request, self-host anytime | You already have them |
RedminePRO figures from redminepro.com/pricing, verified 28 July 2026. The self-hosted column has no published figures because there is no vendor to publish them — that is the point of the checklist above.
This is the cleanest migration we do, because there is nothing to translate. You are already on standard open-source Redmine and so are we. We do it for you, starting with a free assessment and a quote before you commit.
1. Free assessment. Send us a database dump and your files directory, or give us access to the instance. We tell you what your current version is, which of your plugins are supported, what needs upgrading on the way across, and how long the cutover will take — in writing, before you commit to anything.
2. We do the migration. Projects, issues, journal history, attachments, users, roles, custom fields and workflows land in your RedminePRO workspace. Our engineers run it; you review the result against your live instance.
3. Go live. You validate, we cut over, your team keeps working. Keep your old server running read-only for a couple of weeks if it makes you comfortable — most teams do, and none of them have needed it.
One piece of practical advice: if your instance is several major versions behind, say so at the assessment stage. Old instances migrate fine, but the version jump is the part that determines the timeline, and we would rather tell you that up front than discover it on cutover day. How migration works.
Worth stating plainly, because it is the argument against us and we would rather you heard it from us.
RedminePRO is standard open-source Redmine. Not a fork, not a suite built on a Redmine base, not a proprietary product with a Redmine-shaped interface. That means the thing you would be running yourself and the thing we run for you are the same software, and moving between them in either direction is a backup and a restore.
So the decision is reversible. We will provide your files and database on request and you can stand them up on your own server the same week. There is no schema to convert, no export format to reverse-engineer, and no data trapped in vendor-specific modules — because there are no vendor-specific modules. If in two years you hire a platform team and self-hosting starts making sense, take your data and go. That option existing is worth something whether or not you ever use it, and it is the reason we can afford to be honest on the rest of this page.