Why Redmine security hardening starts with the branch you run
Redmine security hardening starts with the release branch you run, because every other control depends on receiving fixes for that branch. A self-hosted Redmine that holds project, customer or internal data needs a defined set of measures: staying on a supported branch, serving only over HTTPS, controlling accounts, sessions and API keys, reviewing plugins, limiting uploads, and backing up the database and attachments. Most of this is configuration and day-to-day operating discipline. It is harder than it looks because plugins, the Ruby and Rails versions and file handling all sit outside core Redmine's own release cycle, so a server can be patched at the core and still be exposed through a component nobody updated.
The Redmine download page sets out four support states. The 7.0.x line receives new features, bug fixes and security updates. The 6.1.x line receives bug fixes and security updates. The 6.0.x line receives only important security updates, and 5.1.x and older receive no updates at all. The latest stable releases listed there are 7.0.2 and 6.1.5, both dated October 1, 2026, and 6.0.11, dated August 26, 2026. Check the page on the day you plan the work, because point releases change. An installation on 5.1.x or older sits outside every security channel, so the first hardening task on it is a planned move to a supported line before any configuration change.
Treat the branch choice as a decision with named owners. Confirm which Ruby and Rails versions the target line requires: Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, and it does not support JRuby. Then inventory every installed plugin and ask each maintainer whether a version exists for the target line. An abandoned or lagging plugin is the most common reason a server stays on an older branch. Record the inventory, the owner of each plugin and the date it was last reviewed, because that list is what your security reviewers will ask for first.
Redmine has no paid edition. The software is free under GPL v2, so the cost of hardening is labor and operations: administrator time to track branches, test plugin compatibility, apply updates, renew TLS certificates and run restore tests, plus the hosting and monitoring the server needs. Most of these costs recur. Ask any partner quoting this work to split the scope into a one-time baseline (branch move, HTTPS, account and session policy, upload limits, backup design) and an ongoing set (patch cadence, plugin reviews, restore tests), and to state who performs each item and how often.
Which Redmine components and settings carry the attack surface
A hardening review of Redmine covers more than the application code. The exposure sits across the Rails and Ruby runtime, the web tier that terminates TLS, the database, the attachment store, and the settings that open inbound paths such as email, the REST API and LDAP. Each item below is a place where a misconfiguration or an unmaintained component can turn into an access or data exposure.
Rails application server and Ruby runtime
Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, and it does not run on JRuby. Confirm which Ruby version is installed, that it is still receiving security updates from its maintainers, and that the Redmine release on top of it is in a supported line. Check which process user runs the application and that the server is not started with root privileges.
Reverse proxy and TLS termination
The web server or reverse proxy that accepts browser and API traffic is where HTTPS is enforced, certificates are held, and HTTP is redirected. Review the protocol versions and cipher configuration it offers, whether it forwards the correct client and protocol headers to Redmine, and whether the application is reachable directly on its internal port from outside the network.
Database engine and isolation settings
PostgreSQL, MySQL 8.0 to 8.4, SQL Server 2012 or higher, and SQLite are the supported options, and SQLite is not suited to multi-user production use. For MySQL, confirm transaction isolation is set to READ COMMITTED. Review which database account Redmine connects with, whether it has rights beyond its own schema, and whether that account is separate from administrative access.
Attachment files directory
Uploaded files are stored in a files directory outside the database, so filesystem permissions and backup coverage matter as much as application roles. Confirm that only the Redmine service account can write to it, that it is not served directly by the web server, and that it is included in the same backup set as the database so attachments and issue records stay consistent.
Email configuration for issue creation
Email-based issue creation lets inbound messages create or update issues, so the mail receiving path is an input channel. Review which mailbox is polled or piped, which sender addresses or domains are accepted, how the mail handler authenticates to the mail server, and which tracker and project the incoming mail can write to.
REST API switch and API keys
The REST API is disabled until an administrator enables it, and it accepts HTTP basic authentication or a per-user API key sent as a parameter or in the X-Redmine-API-Key header. Confirm whether the setting is on only where needed, who holds API keys, and whether keys passed as URL parameters could appear in proxy or application logs.
LDAP authentication settings
Redmine authenticates against LDAP natively, so the directory connection, bind account, search base and user attribute mapping decide who can sign in and with which group membership. Review whether the bind account is least-privileged, whether the connection uses encryption, and whether accounts disabled in the directory are also blocked in Redmine.
Installed plugins
Plugins run inside the Redmine process with its database and file access, and they are maintained separately from core. Inventory each plugin, its source, its compatibility with the installed Redmine version, and the date of its last update. Plugins that are abandoned, unsigned by a known maintainer, or written for an older release are the most likely place for unreviewed code to enter.
Which hardening choices fit your risk and what each costs to run
This table compares the main Redmine hardening choices against the risk they address and the recurring work they create. Read each row for when the option fits and what your team will have to keep doing after go-live. The main takeaway is that the cheapest-looking option often moves cost into key rotation, plugin review or restore testing rather than removing it.
| Hardening choice | When it fits | Operational cost to run |
|---|---|---|
| TLS terminated at the application server | Small single-server installs with no existing reverse proxy to reuse | Certificate issuance and renewal are handled on the Redmine host, and restarts are needed when certificates change |
| TLS terminated at a reverse proxy | Organizations that already run a proxy or load balancer with central certificate management | Proxy configuration, header forwarding checks and proxy patching become part of the Redmine change process |
| Local Redmine accounts only | Very small user populations with no directory, or a short-lived pilot | Password policy, joiner and leaver tasks and account reviews are done by hand inside Redmine |
| LDAP-backed accounts | Organizations with an Active Directory or LDAP directory and an existing joiner and leaver process | Directory group mapping, service bind account rotation and testing after directory changes |
| Authenticating reverse proxy in front of Redmine | Organizations that need single sign-on or multi-factor sign-in enforced before Redmine is reached | Proxy and identity provider configuration must be kept in step with Redmine upgrades and certificate changes |
| REST API enabled for named integrations | A known integration such as time entry sync or issue creation from another system | Each integration needs a named owner, a test plan for each Redmine upgrade and a review of the resources it reads |
| REST API disabled | Teams with no integration need, or where the API is not needed for any approved workflow | Low ongoing cost, but any future integration requires a change request and re-enabling by an administrator |
| Per-user API keys with scheduled rotation | Integrations that act as a real user and where traceability of actions matters | Keys must be reissued and updated in each integration on a schedule you define, and users who leave need key revocation |
| Shared credentials for integrations | Rarely appropriate; sometimes used for legacy scripts that cannot hold a per-user key | Shared secrets must be changed whenever anyone with access leaves, and actions cannot be traced to one person |
| Plugins limited to a vetted list | Regulated or customer-facing installs where each plugin's code and maintainer are reviewed first | Each plugin is re-reviewed and tested against every Redmine and Rails upgrade, which adds time to each change window |
| Open plugin installation | Lab or internal test instances with no sensitive data | Lower approval effort, but unknown code runs with access to all project data and upgrades can break silently |
| Self-managed backup schedule | Teams with in-house database and storage operators who can run and monitor backup jobs | Someone must own the schedule, check job results, store copies off-host and run restore tests on a set cadence |
| Managed backup service | Organizations that prefer a contracted service with defined restore responsibilities | Recurring service fees and a shared responsibility matrix to confirm, including who tests restores and how long copies are kept |
How to harden a Redmine server in sequence
This sequence moves a Redmine install from its current state to a supported, encrypted, narrowly exposed server with managed accounts, controlled API and plugin use, bounded uploads and separate backups. Each step closes with a check, so the final verification run tests a known baseline rather than an assumed one.
Confirm the installed branch and support status
The administrator records the exact Redmine version and Ruby, Rails and database versions in use, then compares the Redmine version against the release lines on the official download page. 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. If the server is on an unsupported line, plan the move to 7.0.x as a separate upgrade project before continuing, since later steps assume a branch that still receives security fixes. The step closes when the version, its support status and the upgrade decision are written into the change record.
Put Redmine behind HTTPS and redirect plain HTTP
The team places a reverse proxy or load balancer in front of the application, terminates TLS there with a currently maintained certificate, and configures Redmine to generate HTTPS URLs. Plain HTTP requests are redirected to HTTPS, and the Redmine host setting and any cookie security flags are set so that session cookies are only sent over TLS. The check is a scripted request to the plain HTTP address that must return a redirect to HTTPS, followed by a review of the response headers on a logged-in session to confirm the cookies carry the secure attribute.
Restrict network paths to the database and application
The network team limits inbound traffic to the proxy ports, allows the proxy to reach the Redmine application server, and allows only the application servers to reach the database, mail relay and any LDAP directory. The database listens on a private interface and is not reachable from user networks or the internet. The administrator confirms this from outside the trusted network by scanning the public address and from an application host by checking the database connection, so the step closes with a scan that shows only the proxy ports open.
Set administrator, password and session policy
The administrator reviews the authentication settings in the installed version and confirms the exact option names, since they change between releases. Typical items to decide are the minimum password length and complexity, password expiry, account lockout or login-failure limits, session lifetime, and whether self-registration and password-reset email are allowed. The default administrator account is renamed or disabled, a named administrator is created with multi-factor authentication enforced at the proxy or identity layer, and LDAP-backed accounts are confirmed to follow the directory's policy. The step closes when a test login with a non-compliant password is refused and an idle session expires within the configured lifetime.
Decide on the REST API and manage its keys
The team decides whether any integration needs the REST API. The API must be enabled by an administrator, so if no integration requires it, it stays disabled. If it is enabled, each integration uses a dedicated user with the smallest role that works, and API keys are issued per user rather than shared. Keys are stored in a secrets manager, rotated on a schedule the team sets, and revoked when an integration or person changes. Basic authentication should be checked against the HTTPS-only policy. The step closes with a request made with a revoked key, which must be refused, and a listing of which accounts hold keys.
Review each plugin before enabling it
For every plugin, the administrator checks the source code, the maintainer's recent activity, the published compatibility with Redmine 7.0.x and the Rails and Ruby versions in use, and the list of open security issues. Plugins that are unmaintained or incompatible are removed or replaced before the upgrade or hardening work is signed off. Plugins are installed on a staging copy first, and the installed list with versions is recorded. The step closes when each enabled plugin has a written review and a version pinned in the configuration, and no plugin is installed that lacks one.
Set upload limits and patch conversion tools
The team sets a maximum request body size at the proxy and a matching maximum attachment size in Redmine, and restricts allowed file types where the business allows it. If ImageMagick, Ghostscript or Pandoc are installed, the administrator confirms from the operating system package records that each is patched to a current release, and removes any that are not needed, since these tools parse user-supplied files. The check is an upload of an oversized file and a disallowed type, both of which must be refused at the proxy or in Redmine, plus a package query showing the conversion tool versions.
Configure backups separate from the application host
The team configures scheduled database dumps and copies of the attachment storage, and writes them to a location that is not the application host, with encryption at rest and restricted access. Configuration files and the list of enabled plugins are included, since the upgrade guide treats these with the data. Retention periods are set by the data owner. The check is a restore into an isolated test environment, which must start Redmine with the database contents and attachments from the backup, and the step is not closed until that restore has succeeded at least once.
How API keys, plugins and uploads get locked down
Redmine exposes four surfaces that attackers and careless users reach first: API keys, installed plugins, file uploads and project permissions. Each one needs an owner, a documented setting and a review step that runs on every upgrade, not only at go-live.
API key handling
Redmine accepts a per-user API key as a request parameter or in the X-Redmine-API-Key header, so a key pasted into a log, a shared URL or a chat message works for anyone who finds it. Keep keys out of access logs and query strings where your proxy allows it, and tell users to rotate a key they have exposed. Enable the REST API only when a named integration needs it, and confirm which accounts hold keys.
Plugin inventory and review
Plugins run inside the Redmine process with the same privileges as the application, so each installed plugin is part of your attack surface. Keep a written inventory with source, version and owner, and remove plugins nobody uses. Before each upgrade, check that every remaining plugin supports the Redmine branch you are moving to and that its updates are applied in the same change window.
Upload size and storage limits
Attachments can be large and can carry hostile content, so limit upload size at the reverse proxy and again in the application, and set the values from your own acceptance policy. Store attachments in a directory that the web server cannot execute or serve directly, with restrictive file permissions. If you enable optional document converters such as ImageMagick, Ghostscript or Pandoc, treat them as separate components and keep their packages patched.
Role and project access review
Redmine's role-based permissions are set per project, so access drifts as projects are created, copied and archived. Review each role's permissions, confirm who can view, edit and manage members, and check the anonymous role and any project marked public. A public project exposes its issues and wiki to anyone who can reach the server, so confirm that setting with the project owner before each review cycle closes.
Upgrade-linked security checks
Security settings only stay correct if they are re-checked when the code changes. Each upgrade should repeat the API, plugin, upload and permission checks against the new branch, because defaults and plugin behavior can change between releases. Record the results alongside the database and attachment backups taken before the upgrade, so a rollback has a known-good baseline.
Keeping on a supported branch without breaking plugins
The Redmine branch you run is the first hardening control, because it decides which security fixes you can receive at all. The Redmine download page lists 7.0.x as the fully supported line, with 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, so a server still on 6.0 should have a dated plan to move to the 7.0 line. Redmine 5.1.x and older receive no updates. Check your installed version against these lines now, and record who owns the decision to move and by when.
Before any move, confirm the runtime. Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0. It does not support JRuby. Run the version check on the actual application server, not only on the build host, and confirm that the Ruby version your service manager starts is the one in use. Then review every third-party plugin for compatibility with Rails 8.1 and the target Ruby version. A plugin that has not been updated is often the step that blocks an upgrade, so ask the plugin maintainer for written compatibility or plan a replacement before scheduling the change.
The upgrade procedure in the Redmine upgrade guide is short but order-sensitive. Back up the database and the uploaded files first, and confirm that the backup can be restored. Copy the configuration, the uploads and the third-party plugins to the new installation. Then run db:migrate and redmine:plugins:migrate, clear the cache and restart the application. Skipping the plugin migration or the cache step can leave the application running with stale data or a plugin in an inconsistent state, so treat each step as a checkpoint in your change record.
This section covers only the reason for staying on a supported branch and the core procedure. The sibling topic on Redmine upgrades and support covers the full migration path from older installs to 7.0, including plugin checks and what ongoing support includes. Whatever path you take, repeat the security review after each upgrade. Settings, roles, plugin versions and the API setting can change during a move, and an upgrade that succeeds technically can still leave a control weaker than before. Budget for that review as recurring administrator time, since Redmine has no license fee to offset it.
What drives hardening effort and how to keep each part down
This table lists the factors that change how much work a Redmine security hardening project takes, with a practical way to reduce each one. Read each row as a question to answer about your own instance before requesting a quote, since the largest drivers are usually plugins, user sources and API exposure. The main takeaway is that a smaller, better-documented installation is cheaper to harden and cheaper to keep hardened.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Number and type of plugins | Each plugin adds code to review, may lag behind the Redmine branch, and can carry its own file upload, permission or API behavior that must be checked. | Remove plugins nobody uses, confirm each remaining plugin supports your Redmine branch, and record the owner and reason for each one. |
| Number of projects and roles | Role-based access control must be checked per project and per role, and inherited or overlapping permissions take longer to trace and test. | Consolidate roles into a small set of documented permission sets and review project membership on a fixed schedule. |
| User sources: local accounts, LDAP or authenticating proxy | Local accounts need password, lockout and session policy set inside Redmine, while LDAP or proxy setups move part of that work to the directory or proxy and add integration tests. | Pick one primary source of identity, disable unused login paths, and confirm which policy settings are enforced by Redmine and which by the directory or proxy. |
| REST API serving external integrations | Enabled API access exposes resources to every authenticated user and each integration needs its own key handling, scope review and logging. | Enable the API only if an integration needs it, limit use to named integrations with dedicated service accounts, and rotate or revoke keys when integrations change. |
| Attachment files and total storage | Backups, restore tests and upload limits must cover every stored file, so larger attachment sets mean longer backup windows and more files to check for dangerous types. | Set file size and type limits early, archive or purge old attachments under a documented retention rule, and size backup jobs from measured storage totals. |
| Number of environments (development, staging, production) | Each environment needs its own configuration, secrets and hardening checks, and drift between them is a common source of rework. | Keep one configuration template and apply it to every environment, and limit non-production copies to sanitized data. |
| Age of the installed branch and runtime | Older Redmine branches and Ruby or Rails versions may need several upgrade steps, plugin compatibility work and dependency fixes before hardening can start. Redmine 5.1.x and older are unsupported, and 6.0.x receives only important security updates. | Move to a supported branch before hardening, confirm the Ruby version against the installation guide for your release, and plan upgrades on a regular cycle instead of in one large jump. |
| Compliance evidence requirements | Assessors may ask for configuration exports, access reviews, change records and restore test results, and each one must be collected and dated. | Agree the evidence list at the start, generate exports from the same configuration source, and keep one tested backup and restore procedure with dated records. DeployOpen prepares evidence; independent auditors decide whether controls are met. |
How to test that the hardening holds and fails safely
Verify each hardening control with a test you can repeat, and write down what it returned. Start with transport. Request the site over plain HTTP and confirm that it redirects to HTTPS before any Redmine page is served. Then inspect the certificate from outside your network: confirm the hostname matches, the chain is complete and the expiry date falls well outside your renewal window. Check that the renewal job ran on its last schedule and that a failed renewal raises an alert, because a certificate that renews on paper but never reloads into the proxy still fails users. Next, confirm access control. Sign out, then request the URL of a private project, its issue list and an attachment link. Each should be refused or redirected to login.
Test the REST API from both sides of its setting. If an administrator has disabled the API, an unauthenticated call to an issues endpoint should return an error, and so should a call that uses a valid key. If the API is enabled, a request with no key and a request with an invalid key should both be refused. Repeat the test with the key sent as a parameter and in the request header, since each path is checked separately. For uploads, send a file just above the configured limit to the public address and confirm that the proxy rejects it before it reaches Redmine. Then send the same file directly to the application, bypassing the proxy, and confirm that Redmine rejects it too. A limit at one layer leaves the other layer open, so read the values from your own configuration and confirm them with the test.
Confirm that a removed plugin is gone at every layer. The plugin directory should no longer exist on disk, the plugin should be absent from the administration plugin list after the application restarts, and any URL it served should return not found. Check the restart itself, because a plugin can stay loaded in a running process until the service restarts. The restore test matters most. Restore the latest database dump and attachment copy into a separate environment that has no route to production email or integrations, using the same Redmine version and plugin set as the source. Log in with a test account, open a project with attachments, and confirm that files open and match their recorded sizes. Note how long the restore took and whether any step needed manual work. A backup that has never been restored has not yet been proven.
Record every check in a single register with the date, the tester, the control, the steps, the expected result, the actual result and the location of the evidence. A failed check is a finding that needs an owner. Assign it, fix it, and rerun the same test before closing it. Keep the failure details as well, since an error page that exposes a stack trace or a version number is itself a result to report. A test run is different from a configuration checklist. A checklist confirms that a setting was written. A test run sends requests to the running system and observes what comes back, which is how you learn whether the hardening holds. DeployOpen runs security testing of applications and APIs as a separate service, scoped in writing before work starts, and its results feed your own remediation tracking.
What to monitor, back up and document after hardening
Hardening a Redmine server is not a one-time task. The controls that keep it secure depend on staying on a supported release, noticing failures early, restoring data when needed, and recording who owns each control. The cards below cover the recurring work that keeps those controls in place after go-live.
Track release lines and security notices
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. Check the download page on a regular schedule to see which branch your server runs and whether a newer patch has been published. Confirm with your platform team how these checks are logged and who acts on them when a security update appears.
Watch application and proxy logs
Review Redmine application logs and reverse proxy access logs for repeated failed logins, unusual API errors, and requests to administrative paths. Failed login spikes and API calls returning authentication errors are early signs of password guessing or leaked API keys. Confirm which log shipping and alerting tool your organization uses, and where Redmine and proxy logs are retained.
Monitor plugin releases and maintainer notices
Every third-party plugin adds code that runs inside Redmine and may not receive the same security attention as the core. Keep a current list of installed plugins, their versions, and their maintainers, then check their release notes and notices before each Redmine upgrade. Remove plugins that are no longer maintained or that do not match the supported Redmine line.
Back up database and attachments
Schedule backups of the Redmine database and the attachments directory, since the upgrade procedure itself calls for backing up both. Store copies off the application host so a single server failure or compromise does not remove them. Test restores on a separate system at a regular interval, because a backup that has never been restored is unverified. Confirm the backup tool and retention period with your platform team.
Rotate API keys and certificates
The Redmine REST API authenticates with per-user API keys, and those keys grant the same access as the user who owns them. Set a rotation cadence for API keys used by integrations, and remove keys belonging to users who have left. Track TLS certificate expiry dates for the HTTPS endpoint so renewals happen before outages. Confirm the rotation cadence and the ownership of each key with your security team.
Document configuration and change records
Keep a written record of the Redmine configuration, the list of approved plugins, and the owner of each hardening control, such as session policy, upload limits, and API access. Record every upgrade with its date, the versions changed, the plugin compatibility checks performed, and the person who approved it. Auditors and future administrators rely on this record to confirm what was changed and why.
What buyers and engineers ask before hardening Redmine
What does hardening Redmine cost when the software is free?
Hardening carries no license fee, so the cost is labor and running costs. Staff time or partner time pays for the configuration work, HTTPS setup, identity decisions and plugin review. Hosting for the application and database servers, backup storage and offsite copies are recurring costs. Most of the spend recurs: security updates arrive on each supported release line, plugins need compatibility checks after every upgrade, and backups need periodic restore tests. To compare quotes, ask each provider to list effort or fixed deliverables for every item, which plugins are in scope, what ongoing support covers and who holds server access after handover. Cost rises with plugin count, custom integrations and the number of environments.
How long does a Redmine security hardening project take?
Duration depends on the installation, not on a standard timeline. The main drivers are how old the installation is, how many plugins it runs, how many environments must share the same controls, and which integrations such as LDAP, the REST API or email ingestion need review. An install on a branch that is no longer supported may need an upgrade to the 7.0 line first, which adds testing time. This page does not give a fixed duration. The timeline is set in a written scope that lists deliverables, environments and dependencies, and it is agreed before work starts. Ask for milestones tied to each environment and a clear list of steps that wait on your decisions.
What does the client need to provide for hardening?
The work needs access, decisions and a complete inventory. Provide administrator access to the application, web, database and backup servers, or a named contact who can run the changes. Make decisions on the HTTPS certificate source, whether users sign in through LDAP, a reverse proxy or a plugin, and the password and session policy you must meet. Supply a full list of installed plugins, themes and integrations, including every system that calls the REST API. Name one owner who approves changes, signs off test results and accepts the handover. A staging environment or a window for a test restore is also needed, along with the backup retention rules your organization already follows.
Can our own team harden Redmine without outside help?
Yes, if the team already has the skills and time. Hardening touches the Linux host, the web server and TLS configuration, the database, the Ruby and Rails runtime, and the Redmine application settings. Your team needs working knowledge of each layer and the ability to test upgrades in staging. The larger ongoing load is recurring: reading security advisories, applying updates to the supported line, rechecking plugins after each upgrade and running restore tests. If the team cannot commit time to those reviews every cycle, a retainer for ongoing support may suit you better. Either way, ask for a written scope so you can compare it with your internal estimate.
Why is SQLite a poor fit for multi-user Redmine production?
SQLite is a poor fit because the Redmine installation guide says it is not suited to multi-user production use. Redmine supports PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, and SQL Server 2012 or higher. For a team with concurrent users, plan for one of those databases with its own backup and restore process. Moving an existing SQLite database later means a data migration that needs testing, so decide before go-live. The choice affects backups, replication for high availability and how upgrades run database migrations. Confirm the database version you select against the installation guide before you build.
Does hardening Redmine make our system compliant with a standard?
No. Hardening prepares controls, configuration and evidence, but it does not make a system compliant on its own. Compliance is assessed by an independent auditor or certification body, which issues any attestation or certificate. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications. Before you start, identify the framework that applies, the control IDs in scope and the evidence the assessor expects, such as access reviews, change records, backup restore logs and patch history. Hardening the Redmine host and application covers part of those controls, and the remainder depend on your processes.
Which Redmine release line still receives security updates?
The 7.0.x line is the fully supported line, with new features, bug fixes and security updates. The 6.1.x line receives only bug fixes and security updates, and the 6.0.x line receives only important security updates. Lines 5.1.x and older are unsupported and should be upgraded before hardening. Redmine 7.0 runs on Rails 8.1 and supports Ruby 3.2, 3.3, 3.4 and 4.0, and it does not support JRuby. Check each plugin against the target version before upgrading, because plugins may lag behind core releases. Confirm the current release list on the Redmine download page when you plan, since point releases change.
How DeployOpen works on Redmine security hardening
DeployOpen hardens self-hosted Redmine inside your own infrastructure, starting from a written scope that covers the version line, transport, authentication, API, plugins, uploads and backups. Each change is built, tested and documented so your team can run and verify the server after handover.
How we scope
- Confirm the Redmine branch you run and whether it sits on the fully supported 7.0 line or needs an upgrade first.
- Inventory HTTPS termination, password and session settings, API enablement, installed plugins, upload limits and backup coverage.
- Agree the scope in writing before work starts, since engagements are fixed-scope with defined deliverables and timelines.
How we build
- Apply HTTPS, password and session policy, and API key handling changes in a staging copy of your Redmine server first.
- Review each installed plugin for maintenance status and compatibility, and remove or document those that are not needed.
- Set file upload limits and configure database and attachment backups, then test a restore against the documented procedure.
How we hand over
- Deliver a written configuration record covering settings changed, the reasons for each change, and the verification steps performed.
- Document the backup schedule, restore procedure and the upgrade steps that apply when moving between Redmine stable releases.
- Walk your administrators through the checks they will repeat after patches, plugin changes and routine maintenance.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial hardening work is handed over.
- Retainer scope can cover tracking Redmine security releases and applying them on your agreed schedule in a test copy first.
- Ask any provider which Redmine branch they will support, how plugin compatibility is checked, and who restores backups during an incident.
