What Redmine costs to run after go-live
Redmine has no license fee. It is released under the GNU General Public License v2, so the cost of ownership is the recurring work and infrastructure that keep it running: servers, the database, backups, plugin maintenance, upgrades and the administrator time that ties them together. The one-time cost of rolling it out is covered on the implementation plan and cost page, so this section focuses on what you pay for every year after go-live.
Four situations usually trigger a cost-of-ownership review. The first is the renewal of a paid tracker, when the team needs a like-for-like comparison of the subscription against hosting and staff time. The second is an aging install still on an old branch. The 7.0.x line is the fully supported one, 6.1.x receives only bug fixes and security updates, 6.0.x receives only important security updates, and 5.1.x and older are unsupported. The third is plugin sprawl, where each added plugin is another component to test on every upgrade. The fourth is a single administrator leaving, which exposes undocumented procedures.
Confirm the current support status of your branch and the Ruby and database versions it needs before you estimate upkeep, because those dates set how often you must upgrade. Also list every installed plugin and whether its maintainer still publishes compatible releases. Ask any provider for a quote that separates hosting, database operation, backup testing, plugin review, upgrade work and periodic reviews, so each recurring line can be compared with your own staff time.
The short answer most teams reach is to keep daily administration in-house, such as user accounts, project setup and routine monitoring, and to buy a partner for the work that is heavier and less frequent: upgrades, plugin compatibility checks and periodic reviews of hosting, backups and access. This split keeps knowledge close to the people who use Redmine every day while handing off the tasks that need specialist testing.
What a cost-of-ownership study includes
A cost review ends with a model your team owns and can update. It is built from your current install and your own quotes, not from vendor list prices, because Redmine itself carries no license fee.
Inventory of the current install
We record the Redmine version, the Ruby and Rails versions in use, the database engine and version, installed plugins with their versions, attachment storage size and location, and every integration such as LDAP, SCM repositories or the REST API. Each item is checked against the supported release lines, so the model starts from what actually runs today.
Recurring cost model with owners
Every recurring line, such as hosting, database operations, backup storage, plugin maintenance, upgrade effort and administrator time, is listed with a named owner, a unit and a source for the figure. Items that are one-time, such as an initial migration, are kept in a separate section so recurring totals stay clear.
Comparison against your own quotes
When a paid tracker or hosted Redmine option is under consideration, we compare it using the quotes you have received, with the same scope, user count and support level applied to both sides. Where a quote is missing a component, such as data export or SSO, the gap is flagged rather than filled with an assumed price.
Upgrade and support calendar
The calendar maps Redmine's published support status for each release line against your own maintenance windows, Ruby and database end-of-life dates, and plugin compatibility checks. It shows when an upgrade is due, which plugins may block it, and what effort each cycle is likely to require.
Administrator runbook
A short runbook covers routine tasks: backups of the database and uploaded files, the upgrade sequence, cache clearing and restarts, plugin migration, and who to contact for each step. It lets a second administrator operate the install and keeps the cost model grounded in documented work.
What drives recurring cost and how to keep it down
This table lists the factors that change hosting, maintenance and administrator effort over time, why each one matters, and how to keep it under control.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Users and concurrent use | Active user count and peak simultaneous sessions set the sizing of the application server, background workers and database, and they grow the bill as headcount grows. | Confirm peak concurrency with the business before sizing, separate the application and database tiers, and revisit sizing after major team changes. |
| Attachment volume | Uploaded files grow storage and make every backup, restore and copy to a recovery environment take longer. | Set file size limits, agree a retention rule for old attachments, and place uploads on storage sized for growth with backups planned around it. |
| Number and age of plugins | Each plugin needs compatibility checks and testing before every Redmine upgrade, and abandoned plugins can block a move to the next supported branch. | Keep the plugin list short, record the owner and last release of each plugin, and remove any plugin no team still uses. |
| Integrations through the REST API and LDAP or SSO add-ons | Each integration needs its own API key handling, monitoring, change control and testing whenever Redmine or the identity provider changes. | Document every integration and its owner, use dedicated service accounts, and limit integrations to the stable API resources. |
| Number of environments | Staging and recovery copies multiply hosting, database storage, backup jobs and the time spent refreshing test data. | Keep one staging copy for upgrade testing, size it smaller where possible, and schedule refreshes instead of keeping extra copies running. |
| Distance from the supported branch | Installs that trail the current 7.0.x line need larger, riskier upgrade steps across Ruby, Rails and plugin changes, which costs more each time. | Plan regular minor upgrades on the supported line and confirm the branch status on the Redmine download page before each change window. |
| Compliance evidence requirements | Assessors may ask for access reviews, change records, backup restore tests and patch history, which take recurring administrator time to produce. | Agree the evidence list early, automate exports where the platform allows, and schedule restore tests and access reviews as recurring tasks. |
| Database hosting choice | SQLite is not suited to multi-user production use, so a production install needs a supported database server such as PostgreSQL or MySQL, with its own backups and patching. | Choose the database engine during planning, confirm the supported versions for your Redmine release, and include database operations in the support scope. |
How the cost review runs
The review turns an existing or planned Redmine install into a costed, owned model with a support calendar and a runbook your team can keep using after the engagement ends.
Inventory the current install and its status
We record the Redmine version, Ruby and database versions, installed plugins, hosting layout, backup jobs and optional components such as Sidekiq or ImageMagick. We compare the version against the support lines published on the Redmine download page, where 7.0.x receives full support and older lines receive less or none. Done when the inventory lists every component with its owner and its support status.
Build the recurring cost model with owners
We list each recurring line: compute and storage, database hosting, backup storage, plugin maintenance, upgrade effort and administrator time. For each line we name the internal owner and the budget holder, and we separate one-time costs from recurring ones. Ask for the hosting bill and staff time estimates from your own finance and operations teams. Done when every line has an owner and a source figure.
Compare against paid and hosted options
We compare the modeled cost of self-hosted Redmine with paid or hosted issue trackers you are considering. Redmine has no license fee under GPL v2, so the comparison depends on the written quotes you supply, covering licensing, hosting, support tiers, user limits and data residency. Ask each vendor for quotes that state what is included, what recurs and what changes with headcount. Done when each option has a comparable quote on the same time horizon.
Set the support and upgrade calendar
We draft a calendar for security reviews, Redmine patch releases, plugin compatibility checks, Ruby and database changes, and backup restore tests. Upgrade work follows the Redmine upgrade guide, so the calendar lists plugin migration and database migration steps for each planned move to a supported line. Ask your team which change windows and approval steps apply. Done when the calendar names an owner for every recurring task.
Hand over the model and runbook
We deliver the cost model, the comparison, the calendar and a runbook covering installation layout, upgrade steps, backup and restore procedures, and contacts for each owner. Your team reviews the handover and confirms each owner accepts their lines. Done when the model opens and recalculates without DeployOpen involvement and your named owners have signed off on their responsibilities.
Recurring cost components and who pays for them
This table lists the recurring cost lines of a self-hosted Redmine deployment, who pays for each one, and what to ask for in a quote, since the GPL v2 software itself carries no license fee.
| Cost line | Who pays | One-time or recurring | What raises it and what to ask |
|---|---|---|---|
| Application hosting | You, through your cloud account or data center, or a partner if it manages the environment | Recurring | Instance count, CPU, memory, load balancer and storage. Ask for monthly infrastructure line items. |
| Database operation and high availability | You, or a partner under a retainer | Recurring | Replication, failover and database patching on PostgreSQL or MySQL 8.0 to 8.4. Ask what HA scope and patch windows the quote covers. |
| Backups and restore testing | You, including storage for the database and uploaded files | Recurring | Retention period, data volume and restore test frequency. Ask for restore test evidence and recovery targets. |
| Optional components: Sidekiq, ImageMagick, Ghostscript, Pandoc | You, as the owner of the hosts and packages | Recurring when patched | Background job volume, attachment previews and document exports. Ask which components the quote includes and who patches them. |
| Plugin maintenance | You or a partner | Recurring | Number of plugins and their upkeep, since each is rechecked at every Redmine upgrade. Ask for compatibility checks per release. |
| Ruby, Rails and database upgrades | Your team or a partner, per upgrade project | Recurring, per upgrade cycle | 7.0 runs on Rails 8.1 and Ruby 3.2 to 4.0. Lines 5.1.x and older are unsupported, so catching up costs more. Ask for plugin checks in the quote. |
| Security patching on the supported branch | You or a retainer partner | Recurring | 7.0.x gets all fixes; 6.1.x bug and security fixes; 6.0.x important security fixes only; 5.1.x and older none. |
| Internal administrator time | Your staff, in hours rather than invoices | Recurring | User volume, custom fields, workflows and incident response. Ask what support hours a partner retainer covers. |
| Paid trackers and hosted Redmine | A vendor subscription, plus your team for any migration | Recurring subscription | Seats, support tier, storage limits and data export terms. Compare written quotes, not DeployOpen estimates. |
What usually inflates Redmine running costs
Redmine has no license fee, so most of the money goes to upgrades, plugins, data work, hosting and the people who keep the system running. The risks below are the ones that most often turn a low-cost deployment into an expensive one.
Upgrading several major versions at once
An installation left on an old branch must move through each supported step, and the upgrade guide expects database backups, configuration and plugin copies, and migrations run in order. Plan the path from your current version to the 7.0 line before the gap grows. Ask which plugins block each step and whether they have a 7.0 release.
Plugins abandoned upstream
Plugins are maintained separately from core Redmine, and some stop receiving updates or break after a Rails or Ruby change. Each one you depend on becomes a replacement or fork decision at upgrade time. Keep a register of installed plugins with their maintainers, last release and compatibility with your target version.
Legacy data work left to the team
The built-in importers for Trac and Mantis are marked obsolete and not working, and third-party scripts for other trackers are untested and unsupported. Migration therefore becomes custom mapping and scripted import, often over the REST API. Ask for a field mapping and a validation pass before budgeting the cutover.
SSO depending on unowned components
Core Redmine authenticates against LDAP, but SAML or OpenID Connect depends on a plugin or an authenticating reverse proxy. When that component has no named owner, login failures and certificate renewals fall to whoever is on call. Assign ownership for the identity component and its renewal schedule at the start.
Backups that were never restored
Backups of the database and uploaded files only prove value during a restore, and a backup that has never been tested often fails in an incident. Schedule restore tests to a separate host and time how long they take. Record the result, because that measured time is the figure you need for recovery planning.
Undersized hosting and SQLite in production
The installation guide says SQLite is not suited to multi-user production use, so a team that grows on it faces a database migration under pressure. Undersized application servers and missing background job capacity also slow the tool as users are added. Review database choice and sizing against projected user counts before go-live.
One administrator holding all knowledge
When one person understands the plugins, the database, the mail settings and the upgrade history, every absence or departure raises the cost of any change. Document the runbook, keep configuration in version control, and name a second person who has performed an upgrade with you.
How the cost picture changes by starting point
Redmine has no license fee under GPL v2, so moving from a paid tracker removes subscription charges but adds the work of running the software yourself.
- Removed: per-seat license or subscription charges, plus paid add-ons you no longer need.
- Added: servers or a cloud account, database, backups and monitoring that the vendor previously carried.
- Added: administrator time for upgrades, plugin checks and user administration.
- One-time: data migration. The built-in importers for Trac and Mantis are obsolete, and third-party Jira scripts are untested, so confirm the import method before you plan the cutover.
- Confirm: whether your current contract allows a parallel run and when the subscription can end.
An installation on 5.1.x or older is unsupported, so the upgrade cost comes before any recurring model. The upgrade guide sets the order: back up the database and files, copy configuration, uploads and plugins, then run the migrations.
- One-time: Ruby and Rails changes, because Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0 only.
- One-time: plugin compatibility checks, plus updates or replacements for plugins that do not run on 7.0.
- One-time: test migrations and a documented rollback plan.
- Recurring: staying on 7.0.x, the only line that receives new features along with bug and security fixes, so each stable release needs a planned review.
- Confirm: your current branch and plugin list, and whether an interim step on 6.1.x suits your plugin set.
A hosted service replaces much of the hosting and administration work, but the cost moves into contract terms. Compare what the subscription includes with what you would otherwise run and maintain yourself.
- Compare: the subscription price against hosting, database, backup and administrator time you would carry in-house.
- Confirm: where data is stored and processed, and whether backups and restore testing are included.
- Confirm: the plugin allowance, since plugins drive both cost and upgrade risk, and a service may limit which ones you can install.
- Confirm: which Redmine version the service runs and how quickly it moves to new stable releases.
- Confirm: LDAP and single sign-on options, because core Redmine handles LDAP natively, while SSO depends on plugins or a reverse proxy the service must support.
Running Redmine on Kubernetes spreads platform cost across several workloads, but the platform team's time still counts. The application work lands on whoever owns the cluster and the Redmine release cycle.
- Shared: cluster operation, ingress, storage classes and monitoring, which may already be funded for other applications.
- Added: container image builds, deployment manifest or chart maintenance, and upgrade testing for each Redmine release.
- Added: persistent storage for attachments and a database, either managed or run in the cluster, each with its own backup and restore work.
- Recurring: background job processing, such as Sidekiq, and its scaling and monitoring.
- Confirm: how the platform team charges for this work, and whether the cluster upgrade cycle matches the supported Redmine branches.
Offline environments avoid license costs, but patching, dependency supply and plugin sourcing move into your own intake process. Every update arrives through a transfer you control and approve.
- Recurring: offline patching, where each Redmine security release and Ruby update must be brought in, tested and approved.
- Recurring: mirroring of plugins and gem dependencies, so builds and upgrades do not depend on internet access.
- One-time: an internal mirror and an approved software intake process.
- Added: longer review cycles, which can keep you on an older branch for longer, so plan the gap against the supported-branch rules.
- Confirm: which optional components you need, such as ImageMagick, Ghostscript or Pandoc, and whether your accreditation permits them.
What the client needs to provide
A cost review is only as accurate as the inputs behind it. Before any estimate of Redmine's recurring cost is worked out, the client should gather the current Redmine version, the Ruby and database versions in use, and a list of installed plugins with a named owner for each. The version matters most: Redmine 7.0.x is the fully supported line, 6.1.x receives only bug fixes and security updates, 6.0.x receives only important security updates, and 5.1.x and older are unsupported. Confirm the exact Ruby version against the installation guide for that release, since the supported Ruby versions differ by Redmine line.
Next, collect the sizing and operating facts: user and project counts, attachment storage size, the backup schedule, and the date of the last restore test. A backup that has never been restored is a risk to price, not a line item to ignore. Also supply the hosting bills or quotes for the current setup, the integrations in use (LDAP, SCM repositories, the REST API, email issue creation), and any written quotes from paid or hosted issue trackers the organization is comparing against. Ask for the quotes in their original form so the review can compare scope, not just headline fees.
Name the administrators who run Redmine today and estimate how much of their working time it takes, including upgrades, plugin checks and user administration. This is often the largest recurring cost and the one most likely to be missing from the current budget. Then confirm three decisions: the target support line, the hosting model (own infrastructure, a managed host, or a hosted Redmine service), and the person who signs off the recurring budget. Without these three answers, the review can describe options but cannot produce a comparison the budget owner can approve.
Common questions about Redmine running costs
Does Redmine have a license fee?
No. Redmine is free software released under the GNU General Public License v2, so there is no license fee for the application itself. The cost of a deployment comes from the infrastructure it runs on, the database, backups, plugins, upgrades and the time people spend administering it. Any quote should itemize hosting, services and plugins separately, since the software itself carries no charge under the license.
How do I estimate the yearly running cost of Redmine?
Build the estimate from a driver list, then price each line with quotes from your own providers. The main lines are server or virtual machine hosting, the database and its backups, storage for attachments, email delivery, any commercial plugin licenses or maintenance, and the hours administrators spend on patching, upgrades and user requests. Separate one-time costs such as installation and data import from recurring ones, and ask every partner for a quote tied to a written scope so the figures can be compared line by line.
Can our own team run Redmine without a partner?
Often yes for daily administration, though upgrades and plugin reviews are harder to staff. Routine work such as creating projects, managing roles and workflows, watching the server and restoring from backup suits a team with Linux and database skills. Upgrades involve database migrations, Ruby and Rails changes and checking that each third-party plugin still works on the target version. Decide who owns those tasks before go-live, and confirm the current Ruby and database requirements in the installation guide.
How often must Redmine be upgraded, and what if we don't?
It depends on the release line you run, so check the download page for the current status before planning. The 7.0.x line receives new features, bug fixes and security updates. The 6.1.x line receives only bug fixes and security updates, the 6.0.x line receives only important security updates, and 5.1.x and older lines are unsupported. An unsupported installation stops receiving fixes, and the upgrade path grows longer, so schedule a recurring review before an incident forces the change.
Is hosted Redmine cheaper than running it ourselves?
It depends on the quotes, the data terms and the administrator time you would save. Compare the hosted subscription with your own hosting, database, backup and storage costs, plus staff hours for patching, upgrades and plugin checks. Then review where the data is stored, how backups are restored, which plugins the provider allows, whether the API and LDAP settings you need are offered, and what happens to your data at exit. A hosted plan is cheaper only when those terms match your requirements.
What does a partner retainer pay for after go-live?
A recurring retainer pays for ongoing work that someone must own after launch, scoped in writing before it starts. Typical items include monitoring and patching the server and database, applying point releases on your chosen line, testing plugins before each upgrade, restoring backups on request and handling agreed support requests. Ask for the written scope, the included hours and a clear list of what is billed separately.
How DeployOpen approaches Redmine cost reviews
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Redmine cost review starts from the costs your environment will actually carry. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Confirm which Redmine branch you would run, since 7.0.x is the fully supported line and older branches have different support levels.
- List the hosting, database, backup and file storage choices that the cost model must cover in your own cloud accounts or data centers.
- Inventory the plugins, LDAP or SSO needs, and API integrations that will add maintenance work after go-live.
How we build
- Model each cost component as one-time or recurring, with the person or vendor paid for each item named explicitly.
- Check Ruby, Rails and database version compatibility against the installation guide before choosing a hosting baseline.
- Document the upgrade procedure, including database migrations and plugin migrations, so administrator time can be estimated from your own plugin list.
How we hand over
- Deliver a written cost model with assumptions, cost drivers and the questions to put to any quote you receive.
- Provide runbooks for backups, restores and upgrades so your team can verify the figures in the model.
- Walk your administrators through the decisions that most affect recurring cost, such as plugin count and database choice.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the model is in use.
- Re-run the cost review when you move to a new supported Redmine line or change plugins, hosting or identity sources.
- Agree support boundaries in writing so you know which administrator tasks stay with your team and which are covered.
