Redmine high availability guide | DeployOpen

Why Redmine high availability is harder than adding a second server

Adding a second Redmine application server does not make Redmine highly available by itself. Redmine high availability spans the web tier, the database, shared uploaded files, background jobs and the restore process, and a second application node only addresses the first of these. Teams that treat it as a simple duplication usually discover the gaps during their first failover, when users are already locked out and the project record is partly unavailable. Redmine has become the place where delivery and support work is tracked in many organizations. Issues, wiki pages, time entries and attachments hold the working record of releases and customer escalations, so an outage blocks people who are not in IT at all. That business weight is the reason to ask whether high availability is needed, not a reason to assume it is. For many internal instances, a single node with a database that is backed up on a schedule, a tested restore procedure and a documented rebuild plan meets the need better than a cluster that nobody rehearses. Multi-node designs make sense when the cost of an hour of downtime is high, when maintenance windows cannot be scheduled around users, or when a regulator or internal policy requires a defined recovery objective that a restore alone cannot meet.

The web tier is the easy part. Redmine runs as a Ruby on Rails application, and several application servers can sit behind a load balancer if they share the same database and the same configuration. The harder questions are where state lives. Session handling must be settled before the load balancer is configured, because a user whose requests land on a different node should not be logged out or see stale data. Each node also needs an identical deployment of Redmine, the same installed plugins and the same configuration file, and upgrades must roll across nodes in a way that keeps the schema compatible during the transition. Decide whether you will use sticky sessions or a shared session store, and write down how a plugin update reaches every node before you go live.

Attachments are the most common point of failure. Redmine stores uploaded files on the file system of the application server by default. If a user uploads a document through one node and the next request is served by another, the file may not exist there. Shared storage such as a network file system, object storage through a suitable plugin, or a clustered file service solves this, but each option changes permissions, latency, backup scope and the restore procedure. Confirm with your storage team how file ownership and permissions will work across nodes, and test an upload followed by a download through every node. Background jobs add another layer. Redmine's optional components include Sidekiq for background job queues in production, and email notifications and other asynchronous work must run exactly once or be safe to repeat. Decide which node runs the worker, how it is restarted and what happens to queued jobs during a failover.

The database and the restore process decide whether high availability is real. A replicated PostgreSQL or MySQL database protects against a server failure, but it does not protect against a bad migration, an accidental deletion or a corrupted upgrade, because replication copies those mistakes faithfully. Redmine's upgrade guide calls for backing up the database and uploaded files before running migrations, so backups of both must be independent of the replicas and restorable as a matched pair. MySQL deployments must also use transaction isolation set to READ COMMITTED, as the installation guide requires. Before committing to a design, ask your team to run a restore into an isolated environment, time it and confirm that attachments and database rows still match. Record the recovery point and recovery time the business actually needs, and let those numbers determine how much complexity you add.

Which Redmine components must survive a single node failure

Redmine high availability depends on every component a user request touches, not only the web tier. The cards separate the pieces that must be duplicated from those that depend on which features you enable, and they describe what users experience when each one fails. SQLite is not suited to multi-user production use, so a highly available design starts from PostgreSQL, MySQL or SQL Server.

Application servers behind a load balancer

Each node runs the Redmine Rails application, and the load balancer is the single address users reach. If one application node fails, the balancer should stop routing to it while the others keep serving the same installation, provided every node shares one database, one attachment store and identical configuration. If the balancer itself fails, all users lose access even when every application node is healthy, so it needs its own redundancy. Health checks should request a page that reaches the database before a node stays in rotation. Duplicate both tiers.

Replicated database engine

The database holds issues, projects, users and settings, so its failure affects every user at once. Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, and SQL Server 2012 or higher. Confirm the isolation level on every MySQL replica, because a replica configured differently from the primary can produce inconsistent results. Test how Redmine reconnects after a failover, and document who promotes a replica and how. Duplicate the database with replication.

Shared storage for attachments

By default, Redmine writes uploaded files to a files directory on disk, so the database does not hold attachment contents. Every application node must see the same files, or users will get missing downloads depending on which node answers their request. A database restore alone does not recover attachments, so the file store needs its own backups and restore tests. Confirm the storage type your platform team can operate, its availability model and how it is mounted on each node. Duplicate it, with a backup schedule that matches the database.

Sidekiq background job queue

The Redmine installation guide lists Sidekiq as the background job queue for production use. Background work covers tasks the web request should not wait for, such as sending notifications. If the queue backend or its workers stop, web requests still succeed, but deferred work piles up or stops, and users see late or missing notifications. Confirm which queue backend your design uses, run workers on at least one node beyond the first, and monitor queue depth. Duplicate the workers and the queue backend.

Optional tools for previews and conversion

The installation guide lists ImageMagick, Ghostscript and Pandoc as optional components. They support features such as image handling, PDF processing and document conversion, and the features that need them depend on which ones your users enable. A node missing one of these tools may fail only certain previews or exports, which can look like a random fault after a failover. Install matching versions on every application node, and test each dependent feature from each node. Duplication follows from the features your users need.

SCM repository integrations

Redmine integrates with Subversion, Git, Mercurial, Bazaar and CVS repositories, and its repository views depend on access to those repositories. If a repository host goes down, Redmine repository pages fail or show stale data while Redmine itself stays up. Decide whether repository access is a Redmine dependency or a separate service with its own availability target, and confirm where any local repository data lives on each node. This card applies only if you use repository integration.

Which database, storage and job layout fits your availability target

This table compares the main layout choices for a highly available Redmine deployment: how many application nodes to run, which database engine to replicate, where attachments live, and where Sidekiq workers run. Read each row for the conditions under which an option fits and the ongoing operational work it adds. The main takeaway is that every step up in availability adds failover, monitoring and administration work that someone on your team must own.

Decision	What it involves	Operational cost	When it fits
Application nodes: single node with backups	One Redmine application server, a regular database backup and a tested restore path into a rebuilt host	Low ongoing effort, but recovery is a manual rebuild that depends on whoever holds the runbook and backups	Internal teams where some planned downtime is acceptable and the restore process has been rehearsed
Application nodes: two or more behind a load balancer	Two or more Redmine app servers sharing one database and one attachment store, with a load balancer health check	Session handling, config drift between nodes, load balancer maintenance and patching every node in step	Users who cannot wait for a manual rebuild and have staff to keep identical nodes in sync
Database engine: PostgreSQL replication	A primary with one or more standbys, with a documented promotion and client reconnection path	Replication lag monitoring, failover tooling, and regular practice of promotion and rejoin	Teams already running PostgreSQL and comfortable operating its replication
Database engine: MySQL replication	A replicated MySQL 8.0 to 8.4 setup with transaction isolation set to READ COMMITTED as Redmine requires	Confirm the isolation setting on every node, verify replica consistency and plan for the same failover tooling as any replicated engine	Organizations with existing MySQL operations skills and a supported version in place
Attachments: shared network storage	A shared file system mounted on every application node for uploaded files	Storage latency affects page load and uploads, and the share itself becomes a dependency that needs its own backup and failover plan	Environments with an existing, well-run network file service and low-latency links between nodes
Attachments: object storage or file sync layer	Attachments held in object storage or synced between nodes by a file sync layer, with the Redmine configuration pointed at it	Plugin or configuration work to confirm support, sync conflict checks, and the need to back up the object store separately	Teams that can confirm Redmine's attachment handling works with their chosen store and who accept a more involved setup
Background jobs: Sidekiq on dedicated hosts	Sidekiq workers run on separate hosts with their own resource limits and queue monitoring	More hosts to patch and monitor, and a second place to check when jobs stall	Deployments with heavy background work, such as large notification or import volumes
Background jobs: Sidekiq co-located with web nodes	Workers run on the same hosts as the web application processes	Fewer hosts, but a busy job queue can slow web responses, and a failed node takes both roles down	Smaller deployments where job volume is light and the team wants a simpler layout
Cutover ownership	A second administrator who can run the database promotion, storage switch and load balancer change from the runbook	Staff time for drills, and a single admin becomes a bottleneck during an incident	Any layout above a single node, since failover depends on people as much as on tooling

How to build a Redmine HA cluster in the right order

This sequence builds a Redmine high availability cluster one layer at a time, so each layer is proven before the next depends on it. The order matters because application nodes, attachments and background jobs all rely on a database that already replicates and a storage layer that every node can reach. The result is a cluster where losing one node does not stop the service, and where a restore has been rehearsed rather than assumed.

Confirm the target Redmine branch
The platform owner and the implementation lead agree on the Redmine branch before any server is built. Redmine 7.0.x is the fully supported line and receives new features, bug fixes and security updates, while 6.1.x and 6.0.x receive narrower fixes. The download page currently lists 7.0.2 and 6.1.5 as stable releases, so the team should pin one exact version and record it in the build document. Check: a signed-off version number that every later step references, with the upgrade path to future 7.0 releases written down.
Confirm Ruby and Rails compatibility
Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, but it does not support JRuby. The team checks the installation guide for the chosen release, selects one Ruby version, and installs the same version on a staging node that matches the production operating system image. Any native gems or optional tools, such as ImageMagick, Ghostscript or Pandoc, are installed at the same versions on every node. Check: a staging node that starts Redmine, passes the built-in health page, and shows the Ruby and Rails versions in the administration information screen.
Build and prove database replication
The database layer comes first because every application node depends on it. For PostgreSQL, or for MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, the team configures a primary and at least one replica, then confirms that replication is running and that the replica is not lagging behind the primary in a way the business would notice. Failover behavior and how the application connects to the current primary are decided here, not later. Check: a test write on the primary, read back from a replica within the agreed lag window, and a documented failover test that promotes the replica and reconnects a test node.
Move attachments to shared storage
Redmine stores uploaded files on the application file system, so every node must see the same files directory before the cluster can serve users equally. The team mounts one shared storage location on each application node with the same path and ownership, and sets the Redmine file store to that path in the configuration. Storage choice, such as network file storage or object storage behind a mount, depends on the hosting environment and should be confirmed with the infrastructure team. Check: an attachment uploaded through node A, then downloaded through node B and matched by checksum against the original file.
Configure identical application nodes
Each application node is built from the same image or script and receives the same configuration file, the same secret token and encryption keys, and the same plugin set at the same versions. Secrets are kept in a store that the nodes read at start, not typed by hand on each server. Plugin compatibility with the chosen Redmine release is confirmed before the nodes are cloned, because a plugin mismatch on one node produces failures that look random to users. Check: a configuration checksum that matches on every node, a plugin list that matches on every node, and a login and project page load from each node individually.
Add the load balancer and session handling
The load balancer sends user traffic to the application nodes and removes any node that fails its health check. The team decides how sessions are kept consistent across nodes, either through a shared session store or through a sticky routing policy, and documents the choice together with its effect on logouts and node restarts. TLS termination and the forwarded headers Redmine uses for URLs are configured at this layer. Check: a logged-in user keeps working when one application node is stopped, and the health check removes that node from rotation within the configured interval.
Move background jobs to Sidekiq workers
Redmine can run background jobs such as email delivery and notifications through Sidekiq, which the installation guide lists as an optional component for production. The team moves job processing to dedicated worker processes that share the same Redis or queue backend and the same Redmine code version as the web nodes. Web nodes enqueue jobs but do not need to execute them, which keeps worker restarts from affecting user requests. Check: a job queued from a request on node A is executed by a worker on a different host, and the result, such as a delivered notification, appears in the logs.
Rehearse a full restore
The cluster is not finished until a backup has been restored into a separate environment and tested. The team restores the database from its backup, restores the attachment files from the shared storage backup, starts a Redmine node against both, and checks that the restored data matches the source. The rehearsal records how long the restore took and which steps were manual, so the recovery plan reflects what the team actually did. Check: a restored environment where a known issue, its attachment and its journal entries open correctly, with the rehearsal outcome signed off by the platform owner.

How single node, active-passive and multi-node Redmine differ

A single node runs the Redmine application, its background job worker and the database on one host, or keeps the database on a second host that is still one instance. This design is the simplest to run and reason about, but its availability depends on how quickly the service can be rebuilt. Recovery time is the main lever, so the restore path must be tested before it is needed.

Survives: application process crashes and restarts, and a lost host when the restore runs onto replacement infrastructure from current backups of the database and uploaded files.
Does not survive: loss of the host or storage without a usable backup, corruption that gets backed up before anyone notices, or a long outage while replacement hardware is provisioned.
Extra moving parts: scheduled database dumps, file backups of attachments, copies of configuration and plugins, and a written rebuild runbook.
Admin skills: Linux server administration, database backup and restore, and enough Ruby on Rails knowledge to run database migrations and restart services after a rebuild.

Confirm with the business owners what recovery time they can accept, then time a full restore into a clean environment to see whether that target is met.

What makes a Redmine HA build take more or less effort

This table lists the factors that move the effort and cost of a highly available Redmine build, with a note on how to keep each one under control. Read each row as a question to answer before scoping, since the answers determine how many nodes, databases and checks the build requires. Most of the savings come from fewer plugins, one database engine and reuse of storage and identity systems your organization already runs.

Driver	Why it changes effort	How to keep it down
Users, projects and issue volume	Larger databases and more concurrent sessions need more application node capacity and tuning of the database and cache layers.	Confirm peak concurrent users and project count early, and size the first build against measured load rather than headcount alone.
Attachment volume and file replication	Replicating uploaded files across nodes requires a replication mechanism, while mounting one shared store is simpler but makes that store a dependency.	Use an existing shared storage platform your team already operates, and agree a retention policy for old attachments before sizing.
Database engine and replication skills	PostgreSQL, MySQL 8.0 to 8.4 and SQL Server each bring different replication, failover and backup tooling, and a team without that skill adds learning time.	Standardize on the engine your database team already runs well, and confirm the MySQL isolation level setting if MySQL is chosen.
Installed plugins checked on every node	Each plugin must be verified against the Redmine version and Ruby version on every node, and plugins with native dependencies add build and test steps.	Remove unused plugins before the HA design starts, prefer maintained plugins, and keep a written list of approved plugins with their versions.
LDAP or SSO already in place	Native LDAP is part of Redmine, but SAML or OpenID Connect depends on plugins or a reverse proxy, which must be configured consistently across nodes.	Reuse the existing directory and authentication proxy, and avoid introducing a second login path during the HA project.
Number of environments	Development, staging and production each need the same node layout, database replication and restore testing, so every extra environment repeats part of the build.	Keep staging close to production in topology, but limit it to the components that affect behavior, such as the load balancer, database and shared storage.
Compliance evidence the client must produce	Assessors may ask for configuration baselines, backup and restore test records, access reviews and change logs, which add documentation and test work.	Ask early which evidence the assessor expects, and generate it from the build process (configuration as code, logged restore tests) rather than by hand.
In-house platform team availability	A team that already runs load balancers, databases and backups can absorb most of the work, while a small team will need more vendor support during build and handover.	Confirm which parts your team will own after handover, and make the support scope explicit in the written statement of work.

Why sessions, uploads and plugins break under load-balanced Redmine

A second Redmine application node usually fails in one of three places: user sessions, uploaded files and plugin code. Each one works on a single server and then breaks the moment a load balancer sends a request to a different node. Treat these three areas as the first items on the high availability design review, before any discussion of failover timing. The first failure is state held in one node's memory. If a session or any cache lives in the memory of one application process, a user who is logged in on node A may be treated as anonymous on node B. The symptom is a login that drops at random, or a form that fails with an invalid token after a page load. The fix is a decision the client must make explicitly: sticky sessions at the load balancer, or a session store that every node can read, such as a shared database or cache. Ask the team which session store the deployment uses and whether the load balancer is configured for session affinity.

The second failure is attachments written to local disk. Redmine stores uploaded files in a files directory on the application server unless the administrator configures another location. An issue created on node A with a PDF attached will show a missing file when a user is routed to node B, because that file exists only on node A. The same problem affects exports, avatars and any other file the application writes. Confirm where the attachments directory points on every node, and confirm that it is a shared mount, such as network file storage, that all nodes read and write. Backups must cover that same location, or a restore will silently lose files.

The third failure is drift between nodes after an upgrade or plugin change. Plugins live in the plugins directory of each installation, and a node that was updated late or with a different plugin version will behave differently from its peers. The Redmine upgrade guide calls for backing up the database and uploaded files, copying configuration, uploads and third-party plugins to the new installation, then running db:migrate and redmine:plugins:migrate. In a cluster, the two migration tasks run once against the shared database, while every node receives the same application code and the same plugin versions. Running them on each node in turn is a common mistake and can leave the schema and the code out of step.

Before the design is approved, ask the client for an inventory of installed plugins with their versions, and check each one for compatibility with the target Redmine release. Ask whether any plugin keeps files or caches on local disk, and whether it stores state in process memory. Confirm the session setup in the production configuration, including the session store and the load balancer's affinity settings. These checks take little time, and they show which of the three failures the deployment is most exposed to.

How to protect shared storage, database credentials and sessions

A Redmine cluster has more places to leak data and more places to misconfigure than a single server. The controls below cover the shared attachment volume, the database and secrets, transport security, API and plugin exposure, and the upgrade routine that keeps every node on the same supported release.

Limit the shared attachment volume to application nodes

Every Redmine node reads and writes the same attachment directory, so that volume holds every uploaded file in the instance. Export it only to the application nodes over a private network, deny access from anything else, and confirm that no other service mounts it. Check that file permissions let the Redmine service account write uploads without making the directory world-readable.

Separate application and replication database roles

The application should connect with a role that can read and write Redmine tables but cannot change server settings or manage other databases. Replication uses its own role with only the privileges it needs to stream changes. Ask your database team to confirm both roles in the target engine, PostgreSQL or MySQL, and to rotate each credential independently.

Keep secrets outside the code tree

The Rails secret token and the database password should live in a root-owned environment file or a secrets manager, not in configuration committed to the Redmine source directory. Each node needs identical copies to decrypt sessions consistently, so define how those values are distributed, who can read them, and how a rotation reaches every node in one change window.

Enforce HTTPS and matching TLS settings

Terminate TLS at the load balancer, redirect plain HTTP to HTTPS, and keep forwarded-protocol headers consistent so Redmine generates secure links and cookies. Each application node should carry the same cipher and protocol settings, because a node that accepts weaker TLS becomes the weakest path into the system. Test each node directly, not only through the balancer.

Control who can enable the REST API and issue keys

The REST API is off until an administrator enables it, and each user can generate a personal API key that acts with that user's permissions. Decide which roles may use the API, review who holds keys, and revoke keys for departed staff. Keys sent as URL parameters can appear in proxy and access logs, so prefer the request header and confirm logs are scrubbed.

Review every plugin before installing on all nodes

Plugins run inside the Redmine process on every node, so a plugin with a flaw or a hidden dependency affects the whole cluster. Review the source, its license, its maintenance history and its compatibility with the Redmine version you run. Install it on a staging copy first, then deploy the same plugin version to all nodes at once so behavior does not differ between them.

Keep the balancer admin and replication ports private

The load balancer management interface, the database replication port and any cluster coordination ports should sit on a private management network, not on public addresses. Restrict them with firewall rules to named administrator hosts or the other cluster members. Scan the public address range after each change to confirm that only the HTTPS listener is reachable.

Upgrade all nodes together on a supported branch

Redmine 7.0.x is the fully supported line and receives security updates, while 6.1.x receives only bug and security fixes and 6.0.x only important security fixes. Older lines are unsupported. Because all nodes must run the same code and the same migrated schema, schedule upgrades for every node in one window, back up the database and uploads first, and confirm the branch against the Redmine download page before each change.

How to prove failover and restores work before you rely on them

A high availability design for Redmine is only a claim until a test has exercised each failure path and recorded what happened. The point of this section is to define a test plan that shows the design fails safely: users keep working where the design promises it, data stays readable, and a restore from backup produces the same project record as the source. Run these tests in a staging copy built the same way as production, and treat any step that needs an undocumented manual fix as a failed test, not a finding to work around.

Start with the application tier. With two or more Redmine application nodes behind the load balancer, log in as a regular user, open an issue, and start editing a long text field. Then stop one application node and confirm whether the session still works, whether the next request is routed to the surviving node, and whether any unsaved edit is lost. Redmine keeps session state in its configured session store, so confirm with your team which store is in use and whether the load balancer uses sticky sessions. The result you record is the user-visible behavior, not only whether the health check turned red.

Next, stop the primary PostgreSQL or MySQL instance and carry out the promotion of a replica exactly as the runbook describes. Measure which steps need an operator, which configuration files change on the application nodes, and whether Redmine reconnects without a restart. Confirm the replication topology, the replica's lag before the test, and the database user and connection string that the application uses after promotion. If the runbook says a step is needed but nobody can point to it in the procedure, the runbook is incomplete and the test has found a gap.

Attachments need their own checks because they live on shared file storage, not in the database. Upload a file before the database failure and another after promotion, then open both through the web interface and the REST API from each application node. Confirm the file contents match the original checksum, not only the file name. Also verify that background jobs queued before a worker restart, such as those that process notifications or previews when optional components are installed, complete afterward. Record the queue depth before the restart and the queue depth once the worker is back, and confirm no job is dropped silently.

The restore test is the one auditors and engineers most often skip. Restore the latest database backup and the matching attachment files into a separate environment, then compare issue counts per project, attachment counts and sizes, and the set of user accounts that can log in. Each comparison should be run against the source with the same query, and the results should be saved with timestamps and the operator's name. Record the time the backup was taken, the time the restore finished, and any difference found. Be clear with the client that DeployOpen prepares this evidence and the control records, but independent auditors and certification bodies, not DeployOpen, issue audit reports or certifications. Ask your auditor in advance which format of evidence they accept.

What to monitor, back up, upgrade and document after go-live

Once the cluster is live, most of the effort recurs. Some items are one-time setup, such as alert thresholds, health check configuration and the first restore test, while others repeat on a schedule or with each release. Ongoing support, upgrades and continuous testing are available as DeployOpen retainers.

Load balancer health checks

Configure the load balancer to probe a Redmine endpoint on each application node and remove unhealthy nodes from rotation. This is one-time setup, but the check needs review after each Redmine or Ruby change. An endpoint that returns success while background jobs or database connections are failing hides the problem, so confirm what the check actually tests. Confirm how user sessions behave when a node leaves rotation, since users may be asked to sign in again. Record the expected response for each node in the runbook.

Replication lag and attachment storage

Track replication lag on the PostgreSQL or MySQL database, because a replica that falls behind can serve stale issue data after a failover. Watch free space on the shared attachment storage as well, since uploads grow with use and a full volume blocks new attachments on every node at once. Set alert thresholds during setup, then review trends on a regular schedule and after large imports. Confirm the lag metric and alert behavior with your database vendor's documentation.

Sidekiq queue depth and error logs

The Redmine installation guide lists Sidekiq as the background job queue for production, so its health affects users directly. A growing queue means jobs such as outgoing email routed through the queue are stalled, and users often notice this before any alert fires. Review application error logs on every node, because an error may appear on one node only and be hidden behind the load balancer. Confirm that Sidekiq workers run on hosts that can be replaced without losing queued jobs.

Backups taken at the same point

Back up the database and the uploaded files in one coordinated run, so an issue never refers to an attachment that the restore lacks. The Redmine upgrade guide also calls for backing up both before changes are made. Schedule restore tests against a separate environment and record how long each restore takes, because that measurement shapes your recovery plan. Confirm where copies are stored, how they are encrypted, and who is authorized to restore them.

Rolling upgrades within supported lines

Redmine 7.0.x is the fully supported line, 6.1.x receives only bug fixes and security updates, and 6.0.x receives only important security updates. Plan moves within 7.0 or from an older line, and confirm with your build whether database migrations run once against the shared database before other nodes restart. Run db:migrate and redmine:plugins:migrate in the order the upgrade guide gives, then clear the cache and restart. Check each plugin against the target Redmine version before the first node changes.

Runbooks and owner list

Write runbooks for failover, node replacement, secret rotation and restore, and test each one before it is needed. Secret rotation covers database credentials, the application secret and any API keys used by integrations. Keep an owner list that names a primary and a backup person for each component, including the load balancer, database, storage, Sidekiq and plugins. Review both documents after every upgrade, because a runbook written for an earlier node layout goes stale without warning.

What buyers and platform teams ask before building Redmine HA

How much does Redmine high availability cost to build and run?

Redmine has no license fee, so the cost comes from the infrastructure and the work around it. One-time costs include implementation labor, load balancer and database replication setup, shared storage configuration, restore testing and any plugin compatibility work. Recurring costs include application servers, the replicated database, attachment storage, backups, monitoring and the administrator time needed to operate the cluster. Background jobs add a queue component if Sidekiq is used. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for each component priced separately, with the assumptions behind each line and the hosting costs shown on their own.

How long does a Redmine HA implementation take?

The duration depends on the drivers in the effort table and is confirmed in the written scope, so no general timeline applies. The main drivers are the number of plugins that need compatibility checks, the chosen database engine and its replication model, whether attachments move to shared storage or an object store, how many environments must be built (for example staging and production), the level of load balancer and monitoring integration, and how many failover and restore rehearsals the client requires. Clients with a stable plugin inventory and an existing database replication setup usually reduce the schedule. Ask for a phased plan with the rehearsal dates written in, since failover testing often controls the go-live date.

Can our in-house team build Redmine HA without outside help?

Yes, if the team already has the right skills. The team needs experience operating PostgreSQL or MySQL replication, configuring a load balancer with health checks, and running a Ruby on Rails application in production, including its process manager, cache clearing and restarts. They also need to be able to rehearse failover and restore from backups, not only read about them. Redmine 7.0 runs on Ruby 3.2, 3.3, 3.4 or 4.0 and Rails 8.1, so the team must be comfortable with that stack. If any of these skills are missing, a partner can fill the gap through a fixed-scope build, or the team can take on the work with a retainer for review during the first cutover.

What does DeployOpen need from our team to start a Redmine HA project?

DeployOpen works inside the client's own infrastructure, so the first inputs are access and information. The client provides environment access to the cloud accounts, data center or air-gapped network where Redmine will run, plus the database engine and version, replication requirements, and details of current backups. Storage details are needed for attachments, including volume size, growth and whether shared file storage already exists. A plugin inventory listing each plugin, its version and its owner is required, since plugin compatibility controls the upgrade path. The client also names a single owner who can make decisions, and sets a restore window in which backup and failover tests can run without affecting users.

Is one well-tested Redmine server enough for our team?

It depends on what the team needs to stay up through. A single well-tested node can be adequate when a short outage is acceptable and the team can rebuild the server and restore the database and attachments within the time it allows. High availability adds value when the tracker is needed for daily delivery, support or change control, and downtime affects other teams. Even with one node, the database and attachment backups must be restored in tests, because a backup that has not been restored is unproven. Ask for a written comparison of recovery time with one node and with the HA design, based on the team's own service expectations, before deciding.

Does a Redmine HA design cover upgrades to newer Redmine versions?

No. High availability keeps the service running across a node or database failure, but it does not replace the upgrade procedure. Redmine's upgrade guide requires a backup of the database and uploaded files, copying configuration, uploads and third-party plugins to the new installation, running db:migrate and redmine:plugins:migrate, clearing the cache and restarting. In a clustered setup, these steps must be sequenced across nodes and tested in staging first. Redmine 7.0.x is the fully supported line, while 6.1.x and 6.0.x receive narrower updates. Ask for the upgrade plan, rollback steps and plugin checks to be included in the scope, and confirm the target version with your own risk owners.

Will a Redmine HA engagement include an audit report or certification?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access settings, backup and restore test results, and change records. It does not issue audit reports, attestations or certifications. Those come from independent auditors or certification bodies. Before scoping, ask which controls your assessor expects to see, which evidence should be captured during the build, and who on your side will provide the assessor with access to it. The written scope should list each evidence item the engagement will deliver so that the assessor's work is not left to guesswork.

Which Redmine version and database should an HA cluster use?

Start from a supported line. Redmine 7.0.x is the fully supported branch and receives new features, bug fixes and security updates, so it is the usual starting point for new clusters. The database choice affects the replication design. Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, and SQL Server 2012 or higher. SQLite is not suited to multi-user production use. Confirm that your chosen database and replication method are supported together with your Redmine version and Ruby version, and check the installation guide before any build decision is made.

How DeployOpen scopes, builds and hands over Redmine HA

DeployOpen plans, builds and documents Redmine high availability inside your own infrastructure, so the design fits your hosting, database and network rules. Each engagement starts with a written, fixed scope, and the work ends with tested restores and a handover your team can run.

How we scope

Confirm the target Redmine line, currently 7.0.x, and the Ruby and Rails versions it requires in your environment
Choose PostgreSQL or MySQL 8.0 to 8.4 for the replicated database, with the isolation setting Redmine requires
Define the load balancer, shared attachment storage and background job layout, including whether Sidekiq is needed

How we build

Deploy two or more application servers behind your load balancer with identical Redmine, plugin and configuration versions
Set up database replication and confirm failover behavior for Redmine sessions, attachments and scheduled jobs
Test failover of each tier under load and record the results against the agreed scope

How we hand over

Document the architecture, failover steps, plugin inventory and the configuration files your team must keep in sync
Run and record a restore test of the database and uploaded files, so recovery steps are proven before go-live
Walk your administrators through routine tasks such as applying upgrades, rotating credentials and checking replication health

How we support

Agree in writing which monitoring, patching and backup checks DeployOpen performs and which stay with your team
Plan Redmine upgrades and plugin compatibility checks on the high availability setup as a scoped task or retainer
Confirm with your team what support hours, response paths and escalation contacts apply after handover