02 Module · Why Redmine

The tracker that cannot
change its pricing.

Redmine is unfashionable, and that works in its favour. It has been shipping since 2006, it runs an unlimited number of users on a small virtual machine, and the database is on a disk you own.

First released: 2006
Written in: Ruby on Rails
Seat licence: None
Licence: GPL v2

Companies find it harder to leave their project tracker than almost any other software, and they rarely think about it. That is why the pricing keeps moving.

Your tracker accumulates the most valuable and least portable asset in the company: the record of why things were decided, including every issue, the arguments in the comments and the estimates that turned out to be wrong. After a decade that archive is institutional memory, and it sits in somebody else's database.

That gives the vendor a hold over you. It is why per-seat pricing can triple across a renewal cycle and be paid anyway, and why an export feature that technically exists never quite produces something you can import anywhere.

Redmine has no vendor in that position. It is a Rails application you run, storing everything in a PostgreSQL database you back up, under a licence nobody can revoke.

Argumenten · The case

Eight reasons,
in order of how often they matter.

Ranked by what comes up in the third year of running it, rather than what wins a bake-off in the first week.

01 There is no seat licence

Add the whole company, every contractor, and the client who wants to watch their own project. The hundredth user costs the same as the tenth, which removes a whole category of procurement conversation.

02 The database is yours

Issues, time entries, wiki and attachments in PostgreSQL you can query, dump, restore and hand to an auditor. Reporting is done in SQL, with no integration tier to buy.

03 It adapts to a regulated process

Custom trackers, custom fields and per-role workflow transitions mean the tool matches an ISO or MDR process instead of fighting it. Most hosted trackers make you adopt their opinion of how work happens.

04 Migrations keep the history

From Jira, Trello or Asana with issue numbers, attachments, authors, timestamps and relations intact. A migration that renumbers everything and drops the comments amounts to a fresh start with extra steps.

05 It is small

A company-wide tracker runs comfortably on a two-core virtual machine. There is no cluster or service mesh: one machine with a database and nginx, described in a single NixOS module.

06 Time tracking is built in

Hours attach to issues and roll up to projects and versions natively, so the numbers you invoice against and the numbers you plan against come from the same place.

07 A REST API without a plan tier

Everything the interface does, the API does. You can build dashboards, deployment hooks and a local language model that answers questions about the backlog without your roadmap leaving the building.

08 Twenty years and still here

Redmine has outlived FogBugz, Rally, Pivotal Tracker and several acquisitions of the trackers that were going to replace it. For the system that holds your institutional memory, staying power is the main requirement.

Jämförelse · Side by side

Against a hosted tracker

Costs are for a 90-person company, which is roughly the size at which the arithmetic stops being theoretical.

Concern	Hosted SaaS tracker	Redmine, as we run it
Cost at 90 users	€1,000–€3,200 / month	~€40 / month of virtual machine
Cost at 900 users	Ten times more	A bigger virtual machine
Price changes	At the vendor's discretion	Not applicable
Where the data lives	Their region, their entity	Your disk, your jurisdiction
Reporting	Built-in charts, then an upgrade	SQL against your own database
Workflow customisation	Within the vendor's model	Per tracker, per role, per field
API limits	Rate-limited, sometimes tiered	Yours to saturate
Backups	Their problem, and their RPO	Nightly, off-site, restore-tested monthly
Interface	Modern, and redesigned without warning	Dated, and stable for a decade
Who patches it	Them	Us, or you, on your schedule

Hur vi driftar · Our install

What goes into a Chenborg Redmine.

We do not ship a default install with a theme on top. The whole system (Ruby version, gems, plugins, database, TLS, backup schedule) is one module in your repository, so rebuilding the server is a command and upgrading is a commit that can be reverted.

Redmine on NixOS with PostgreSQL, reproducible from a single file
Migration from Jira, Trello, Asana or an older Redmine with history intact
SSO against your existing directory, plus enforced 2FA
Custom trackers, fields and per-role workflows that match your process
Nightly encrypted backups to a second European region
Restore tested monthly, with the evidence emailed to you
Optional local-LLM assistant over the REST API, on your own hardware

The Redmine engagement in detail

redmine.nix

# The whole tracker, declared once.
services.redmine = {
  enable  = true;
  package = pkgs.redmine;
  database.type = "postgresql";

  plugins = {
    inherit (pkgs.redminePlugins)
      redmine_agile
      redmine_checklists;
  };

  settings.rest_api_enabled = 1;
};

services.postgresqlBackup = {
  enable    = true;
  databases = [ "redmine" ];
  startAt   = "02:30";
};

# Restored and verified monthly.

Nackdelar · The downsides

When Redmine is the wrong answer.

We would rather lose the engagement than install this somewhere it will be resented. Redmine is the wrong choice when:

The interface is a hiring issue. It looks like 2009 because much of it dates from then. A design-led team that judges a company by its tracker will judge this one harshly, and that is a legitimate cost.
You want chat, docs, whiteboards and roadmaps in one place. Redmine tracks issues and time. It is not designed as a suite, and the plugins that try to make it one are usually a mistake.
Nobody will own the machine. Self-hosting means somebody patches, monitors and restores. We can do it, but if the answer is "nobody, and no budget for you either", buy the hosted product.
You are fifteen people and growing fast. At that size the seat licence is not yet a problem and the operational overhead is not yet worth it, so come back at eighty.
You need deep native integrations with a specific commercial platform. The API will get you there, but you will be building what you would otherwise buy.

The case is strongest for organisations of eighty or more people, with a regulated or unusual process, a long institutional memory worth keeping, and at least one person who is happy to own a server.

Eight reasons,in order of how often they matter.