OpenProject security hardening guide

Why OpenProject security hardening starts after the install

Hardening OpenProject means deliberately configuring TLS, admin and API access, authentication policy, attachment storage, PostgreSQL access and patching. It is a separate job from getting the application running, and it starts once the install works. If you have decided to run OpenProject in your own cloud accounts, data centers or air-gapped network, you also own the security boundary around it. Nobody else will set that boundary for you. OpenProject is licensed under GPL-3.0 and the Community edition is free, so the software arrives without a vendor-operated security layer. Whichever edition you choose, the configuration, the patching and the monitoring fall to your team or to the partner you engage.

The install is harder to get wrong than the surroundings, which is why the work is easy to underestimate. OpenProject starts with working defaults, so the application can appear ready long before it is safe to expose to users. The real exposure sits in the services around it: the reverse proxy that terminates TLS, the PostgreSQL database that holds project data, the file storage that holds attachments, and the identity provider that decides who can sign in. Each of these needs its own review. Ask who can reach the database port, which hosts can read the attachment directory, whether the proxy enforces current TLS settings, and whether the identity provider enforces multi-factor authentication for administrators. Those answers belong in your hardening baseline, not in the install notes.

Hardening also does not end at go-live because OpenProject ships on a regular cadence. Releases in this period were 17.7.0 on August 5, 2026, 17.8.0 on September 2, 17.9.0 on September 30 and 17.9.2 on October 15, 2026. Each release can change defaults, add features or fix security issues, so the baseline must be checked against every update. Subscribe to the release notes, set a patch window your change board approves, and test each update in a staging copy that mirrors your proxy, database and identity settings. Confirm the PostgreSQL version and extensions required by the release before you upgrade the database, because a database move can break a deployment that worked last month.

Start with three decisions. First, name an owner for the OpenProject security baseline and a backup for that role. Second, decide whether you need single sign-on, LDAP group synchronization or custom branding, since OpenProject lists these among its Enterprise features, and that choice changes what you must harden and what you must license. Third, agree on the evidence you will keep, such as configuration records, patch logs and access reviews. A partner can prepare systems, controls and that evidence, and you should ask for the scope and deliverables in writing before work starts. An independent auditor or certification body, not the implementation partner, decides whether the controls meet a standard.

Which OpenProject components carry the OpenProject security hardening boundary

These six components form the hardening boundary of a self-hosted OpenProject instance. Each holds a different kind of data or trust, and a weakness in one can bypass controls set in another. Review them in the order a request travels, from the proxy to the application, database, storage and host, then to any external identity or file links.

Reverse proxy and TLS termination

The reverse proxy or load balancer terminates TLS for every browser and API client, so it decides which protocol versions and cipher settings users negotiate and whether plain HTTP is ever served. A misconfigured forwarding header or an exposed upstream port can let a client reach the application without passing the proxy's controls. Check certificate handling, redirect rules, which headers the application trusts and whether the application port is reachable from outside the network. Confirm the proxy-related settings in the OpenProject administration guide for your version.

Application container or package

The OpenProject application runs as a Docker container or from a .deb or .rpm package, and it handles sessions, the permission model, the API and the administration interface. Compromise at this layer exposes project data and administrator accounts, and an outdated image or package keeps known flaws in place. Check which image tag or package version is deployed, who can pull or replace it and whether the process runs with only the privileges it needs. Confirm the supported installation method for your release in the system requirements.

PostgreSQL database access

OpenProject keeps project data, users and permissions in PostgreSQL, which must be version 16 or later with the pg_trgm, btree_gist and unaccent extensions installed. Any account with direct database access can read or change this data without passing through application permission checks. Check that the application uses its own role rather than a superuser account, that network access is limited to the application hosts and that the extensions come from trusted packages. Confirm the database requirements for your release before changing anything.

Attachment storage location

Uploaded files and attachments are stored outside the database in a storage location that needs its own access controls and backup rules. Anyone with read access to that location can retrieve documents that the application would only show to authorized project members. Check the owner and permissions of the storage directory, whether it sits on a shared volume reachable by other workloads and whether backups of it carry the same restrictions as the database. Confirm where your version stores attachments and how that location is configured.

Host operating system

Packaged installs run on Ubuntu 22.04, Debian 12, RHEL 9.x or SUSE Linux Enterprise Server 15, and the host carries its own patching, service accounts, logging and firewall rules. A host that is out of support or unpatched exposes the application and database regardless of their settings. Check that the host release is supported for your OpenProject version, that only required ports are open, that remote administrative access is restricted and that updates are recorded. Container and Kubernetes deployments apply the same questions to the container host and cluster.

Identity provider and Nextcloud links

Single sign-on through SAML, OIDC, CAS, Kerberos or Okta is an Enterprise feature, and the Nextcloud integration links files to work packages in the Community edition, with OpenID Connect sign-on for it as an Enterprise add-on. Each link creates a trust relationship, so a weak identity provider configuration can grant access and a Nextcloud connection can expose files across systems. Check which sign-in methods are enabled, how group membership maps to roles and which Nextcloud credentials and folders the integration can reach. Confirm these settings for your edition in the administration guide.

Which hardening choices fit your risk profile and team capacity

This table sets out the main hardening decisions for a self-hosted OpenProject, the option each one offers, the operational work it creates and the teams or risk profiles it suits. Read each row as a choice you can make on its own, then check the operational cost against the people who will own it. Settle TLS, admin separation and database reachability first, since they apply to every deployment, and treat identity-provider enforcement as the choice that depends most on plan and existing tooling.

Decision	Option	Operational cost	Fits when
TLS termination	Terminate TLS at a reverse proxy or load balancer in front of OpenProject	Your team renews, rotates and monitors certificates on that layer	Your organization already runs managed proxies with certificate automation
Admin access	Separate named admin accounts used only for platform changes	Two identities per administrator and a recurring review of admin role membership	Several people administer the instance and changes must be attributable to a person
API access	Named service accounts with roles limited to each integration	One account per integration to create, review, rotate and retire	Several systems read or write work packages on a schedule
Password and 2FA	Native password and two-factor settings inside OpenProject	Your team configures and tests the policy and rechecks it after upgrades	Accounts are local, the team is small and no identity provider is available
Password and 2FA	Enforcement at the identity provider through SSO on an Enterprise plan	Enterprise subscription per named user, plus SSO setup and identity provider administration	A central identity team already enforces two-factor for other applications
Attachment storage	Attachments on the local disk of the application host	Backups must capture the host, and capacity grows on one machine	A small user base on a single host with a simple backup routine
Attachment storage	Attachments on network storage or object storage	Mounts or buckets need access controls, monitoring and backup coordination	The storage team already runs shared volumes; confirm the supported setup for your release first
Database access	PostgreSQL reachable only from the application network	Firewall rules and an administrative path, such as a bastion host, to maintain	Production systems where the database holds all project data and access must stay narrow
Patch scheduling	Apply each minor release and security patch within a scheduled window	Regular upgrade effort and a test instance to rehearse each change	Your change process can absorb frequent minor releases, such as 17.7.0 and 17.8.0 in 2026

In what order to harden OpenProject, and how to confirm each step

The sequence moves from measuring the current install to limiting exposure, then to identity, data and operations. Each step ends with a check you can repeat after later changes. Confirm every setting path against the documentation for your installed version before you apply it.

Record the baseline before changing anything
The platform admin records the installed OpenProject version, the install method, the operating system, the PostgreSQL version, the enabled modules and plugins, every administrator account, and the current configuration values. Store this as a dated baseline so every later change can be compared against it. Check the release notes to confirm the version is still in a release line the vendor supports. The step is done when the baseline is saved in your change system and a second person has reviewed it.
Limit host and network exposure
The infrastructure team limits network exposure before any application setting changes. Inbound traffic should reach only the reverse proxy on its HTTPS port, the application port should be bound to the internal interface or blocked at the host firewall, and SSH should be reachable only from the management network. Apply the same rules to the database port. Check: a scan from outside the allowed network shows only the proxy port open, and a direct connection to the application port is refused.
Terminate TLS at a hardened proxy
The platform team places a reverse proxy in front of OpenProject and terminates TLS there. Use a certificate from your internal or public certificate authority, disable the protocol versions your policy retires, and enable only the cipher suites your security team approves. Redirect plain HTTP to HTTPS and forward the headers OpenProject needs to build correct links. Confirm the exact directives in the installation documentation for your version. Check: a TLS scan reports only the protocols you allowed, and an HTTP request returns a redirect to the HTTPS address.
Restrict admin and service account access
Platform admins reduce privileged access and separate automation from people. Keep administrator rights with a small number of named accounts, remove any shared login, and create dedicated service accounts for API integrations that hold only the project roles each integration needs. Issue API tokens to those service accounts and record an owner and a rotation schedule for each. Check: an unauthenticated request to the administration pages is refused, and an API call made with a service account returns only the projects that account can see.
Set the authentication policy
Set the authentication policy in the administration settings. Cover password requirements, handling of failed logins, session timeout, and two-factor authentication where your installed version offers it. Single sign-on and LDAP group synchronization are listed as Enterprise features, so confirm with the vendor whether your plan includes them before you design around them. Check: a test account with a weak password is refused, an idle session ends at the configured timeout, and a test user is prompted for the second factor you enabled.
Move attachments to controlled storage
The platform admin moves attachment storage to a location that the web server cannot browse and only the application user can read. Set ownership and file permissions on the storage path, keep it outside any directory the proxy serves, and confirm the storage setting in the documentation for your installed version. Add this path to the backup scope so attachments and database stay in step. Check: a direct request to a stored attachment path through the proxy returns no file, and a listing attempted by another local user is denied.
Restrict PostgreSQL to the application network
The database administrator restricts PostgreSQL to the application network. Create a dedicated role that owns only the OpenProject database, install the extensions the release requires (pg_trgm, btree_gist and unaccent), and allow connections only from the application subnet with TLS enforced. OpenProject officially supports PostgreSQL 16 or later. Check: a login with the OpenProject role from outside the application network fails, and the same role cannot connect to other databases on the server.
Configure logging, backups and patching
The operations team configures logging, backups and patching together, because each depends on the others. Send application, proxy and database logs to a central system with a retention period your policy sets, back up the database and attachment storage together, and schedule patching to follow the vendor's release notes. Record who receives security notices and who approves each patch. Check: a restore of the latest backup into a separate environment completes and shows a known project, and a deliberate failed login appears in the central log.

Access control and secrets handling in an OpenProject security hardening project

Access and secrets controls decide who can change an OpenProject instance and which credentials can reach its data. The five controls below are where many hardening findings in self-hosted deployments start, and they depend on each other: a leaked service token or a readable configuration file can expose the database even when the web interface is locked down. Check each item against your own installation before agreeing the hardening scope.

Separating admin and user roles

Administrator rights reach instance-wide configuration, user management and authentication settings, so they belong to a small, named group. Project leads and team members should hold project-level roles only. The risk is that a phished or careless everyday account can weaken login policy, change authentication settings or export data from every project. Check that no daily working account carries admin rights and that administrative actions can be traced to a named person.

Issuing and revoking API tokens

Integrations such as reporting scripts, Nextcloud links or migration jobs authenticate with API tokens. Each token should belong to a dedicated service account, carry only the project permissions that integration needs, and have a named owner. The risk is a long-lived token copied into a script that keeps working after the person who created it has left. Check the list of active tokens and their owners, and confirm that revoking one breaks only the intended integration.

Keeping database passwords and secrets out of source control

The database password and the application secret used to sign sessions should be supplied at deploy time from a secrets manager or a root-readable environment file, not from configuration files committed to a repository. The risk is that a repository clone, CI log or backup of a deployment directory exposes database access and session integrity together. Check repository history for stray credentials, rotate any value found there, and confirm that file permissions on the host limit reads to the service account and administrators.

Restricting who can change instance-wide settings

Instance-wide settings govern authentication, email delivery, file storage and password and two-factor policy for every user. Limit changes to named administrators and record who made each change in a change log outside the application. The risk is a quiet change that weakens login protection, which may go unnoticed until an incident. Check who holds the rights to change these settings, which changes your installation records, and whether settings are reviewed after each upgrade.

Protecting backup archives with attachments

Backups contain the PostgreSQL database and the attachment files, so they hold the full project history and every uploaded document. Encrypt archives, limit read access to a small operations group, and keep the decryption material separate from the archive. The risk is a copy left on a laptop, an unencrypted object storage bucket or an old external drive that no one remembers. Check the encryption method, the access list, retention, and whether a restore has been tested with the stored secrets.

Protecting attachment storage and PostgreSQL access

Attachments and the database are the two places where a compromise does the most damage in a self-hosted OpenProject instance. Work package attachments are where teams drop contracts, design files, specifications and sometimes exports that contain personal data. The PostgreSQL database holds user accounts, password and session related records, project permissions and the history of every work package change. An attacker who can read either one can usually learn more about the organization than the application screens ever show. Harden these two layers deliberately rather than assuming the application's permission model covers them.

Start with the attachment directory on the host or in the mounted volume. Decide which operating system account owns the files and which account the OpenProject process runs as, then grant that process write access and nothing broader. Other local users, backup agents and administrators who do not run the application should not be able to list or read the directory by default. Check the ownership and mode after each package upgrade or container volume change, because restored or re-created volumes often come back with looser permissions. Record the expected owner and mode in your runbook so the check can be repeated.

Encryption at rest is usually best handled by the storage platform, not by the application. Confirm whether your cloud block storage, network file system or data center array encrypts volumes by default, who holds the keys, and whether key rotation and access to the key service are logged. Ask your platform team whether the same protection applies to database volumes and to backup targets, since an unencrypted copy in a backup bucket undoes the protection on the live disk. Confirm these details with your storage vendor and your own key management policy rather than assuming them.

For PostgreSQL, the goal is that only the OpenProject application servers and the administrators who need them can reach port 5432. Bind the database to a private interface, restrict it with host based access rules and firewall policy, and do not expose it through a public address or a shared jump host that many people can use. Create a dedicated database role for OpenProject with ownership limited to its own database, and avoid using the superuser for the application. Use the PostgreSQL version that OpenProject supports, which is PostgreSQL 16 or later since OpenProject 16.0.0, and confirm that the pg_trgm, btree_gist and unaccent extensions are installed in the target database before the first start.

Restoring from backup must bring back the database and the attachment files as one consistent set. A database restored from Monday while the attachment directory holds Friday's files will show work packages whose attachments are missing or point at the wrong content. Plan backups so that both are captured at the same point, or stop writes briefly during the capture, and test a full restore into a separate environment. Record the backup schedule, retention and encryption in the security baseline, and treat a restore test that fails to produce working attachments as a security incident in its own right, because it means the recovery copy is not trustworthy.

How hardening changes for Docker, packages, Kubernetes and air-gapped installs

Docker is the installation method OpenProject recommends, so hardening work centers on the containers around the application. TLS usually terminates at a reverse proxy or load balancer in front of the OpenProject container, which means certificate issuance and renewal sit with your team, not with the container image. Secrets such as the database password and the application secret key should be supplied through the container runtime or an external secret store, so they stay out of compose files committed to version control. Attachments live in a volume you mount, so host directory ownership and file modes decide who can read stored files. The PostgreSQL instance should sit on a private network that only the OpenProject container can reach.

The operator owns:

The reverse proxy configuration, cipher policy and certificate renewal.
Secret storage, rotation and any environment file kept on the host.
Host permissions on the attachment volume and on backup copies of it.
Network segmentation between the application, the database and other containers on the same host.
Image pinning to a tag your team has tested, and applying patch releases.

Confirm with the current OpenProject Docker documentation which environment variables and volume paths apply to your release before you write hardening rules around them.

What drives OpenProject security hardening effort and cost

This table lists the factors that change how much hardening work an OpenProject installation needs and how each one can be kept manageable. Read each row as a question to answer before scoping, since the answers set the size of the control list. The main takeaway is that a single install method, one checklist and an early inventory of the existing estate reduce effort the most.

Driver	Why it changes effort	How to keep it down
Users and sizing tier	The OpenProject sizing guide suggests 4 cores and 4 GB RAM up to 200 users, 8 and 8 for about 500, and 16 and 16 for about 1,500. Higher tiers need more load and failover checks.	Confirm the tier before scoping and test once at that tier. Reuse the same configuration pattern at every tier.
Number of environments	Test, staging and production each need installation, configuration and hardening verification, so the work multiplies with every environment.	Use one install method and one configuration source for all environments. Run the same checklist in each and record only the differences.
Identity provider integration	SSO (SAML, OIDC, CAS, Kerberos, Okta) and LDAP group synchronization are listed as Enterprise features. Each protocol adds attribute mapping and login testing.	Choose one protocol and define group mapping before the build. Confirm the chosen features are covered by the edition you plan to run.
Attachment data and backup retention	Attachment volume drives storage encryption scope, backup size, retention rules and the time needed for restore tests.	Set retention and file size policy early. Keep attachment storage on a dedicated path and test a restore once per tier.
Integrations and API consumers	Each API token, service account, webhook and file integration needs scope review, rotation rules and access logging.	Limit the number of service accounts and document each token's scope. Apply one token policy across all consumers.
Compliance evidence requirements	Assessors typically ask for configuration records, access reviews and patch logs. DeployOpen prepares this evidence but does not issue audit reports.	Agree the control list in writing first. Map each control to one configuration item and one evidence source before work starts.
State of existing infrastructure	Older operating systems, PostgreSQL versions earlier than 16, or missing extensions (pg_trgm, btree_gist, unaccent) add remediation before hardening can begin.	Inventory hosts, TLS certificates, reverse proxy and database before quoting. Confirm OS and PostgreSQL support with the system requirements.
Quoting basis	Hardening is typically quoted as a fixed scope against a written list of controls, so changes to that list change the quote.	Request the control list, environment count, identity scope and evidence format in writing. Agree changes through a written scope update.

How to test that OpenProject security hardening holds and fails safely

A hardening change only counts once you can show that it still works. For a self-hosted OpenProject, that means checking three layers: the configuration you intended to set, the everyday functions users depend on, and the way the system behaves when a component it relies on goes down. Write the pass condition for each check before you run it, so the result is a yes or no and not a judgment made after the fact.

Start with configuration checks at the edges and in the data path. At the reverse proxy, confirm which TLS protocol versions and cipher suites are offered, that the certificate chain is complete and matches the host name, and that plain HTTP requests redirect to HTTPS. Log in as each role you use (administrator, project manager, regular member, and a user with no project access) and confirm that the administration area is denied to everyone who should not see it. Create an API token and confirm its scope and expiry match your policy. From a host outside the application network, confirm that the PostgreSQL port does not answer. On the application host, confirm that the attachment directory belongs to the service account and that other local users cannot read or write it. Option names and defaults change between releases, so verify each setting against the version you run.

Functional checks confirm that hardening has not broken normal work. Log in with a test account under the password and two-factor policy you actually enforce, and confirm that the policy is applied as written. Upload attachments of several file types and sizes to a work package, download them again, and compare checksums with the originals. The most important functional test is the backup restore. Restore the database dump and the attachment files into a separate environment that is not connected to production. Then confirm that the attachment files and the database describe the same set of work packages. A backup that has never been restored in this way is an assumption, not evidence.

Failure checks show whether the system fails safely. Stop the reverse proxy, then the database, then the identity provider, one at a time, and record what users see and what the application does. The expected result is that access is denied or the service is unavailable, with no fallback that skips authentication and no partial session that grants access. Error pages should be generic. Check both the responses and the application and proxy logs for stack traces, database connection strings, tokens and passwords. If a secret appears anywhere, treat it as a finding and fix it before the next release.

Turn these checks into a written script or checklist with the expected result for each line, the command or screen used, and the person who ran it. A repeatable procedure is what makes re-testing after each patch practical. OpenProject publishes minor releases frequently; for example, 17.7.0 was released on August 5, 2026, and 17.9.2 on October 15, 2026. Each upgrade can change defaults, proxy headers or logging, so rerun the full checklist rather than only the functional tests. Some organizations also want an independent assessment of the deployment. DeployOpen offers security testing of applications, infrastructure and APIs as a separate service. That testing reports findings, but it does not certify the deployment. Certification and audit opinions come from independent auditors and certification bodies.

What to patch, monitor, back up and document after hardening

This table lists the recurring work after OpenProject hardening, with what each activity involves, how to set its cadence and the evidence an assessor will expect. Set frequencies from your own change process and patch policy, since this page does not set them. The main takeaway is that the 2026 releases (17.7.0, 17.8.0, 17.9.0 and 17.9.2) arrived several weeks apart, so the patch cycle needs a named owner.

Activity	What the team does	Cadence	Evidence to keep
Minor release updates	Apply OpenProject minor releases within the patch window, such as 17.7.0, 17.8.0, 17.9.0 and 17.9.2.	Set by your patch policy and change calendar	Change record with version, date and approver
Security fix review	Read each release note for security fixes and settings that change before scheduling the update.	Each release, before the update window	Written triage note per release
PostgreSQL version and extensions	Confirm the database runs PostgreSQL 16 or later and that pg_trgm, btree_gist and unaccent are still installed.	Set by your database maintenance policy	Version output and extension list
Access log and failed login review	Review access logs, failed logins and admin actions against alert thresholds your team agreed in advance.	Set by your monitoring and incident policy	Review record and alert configuration export
Backup restore test	Restore a backup into a separate environment and check that the application, database and attachments work.	Set by your recovery objectives and test plan	Restore test report with date, scope and result
API token and database credential rotation	Rotate API tokens and database credentials, then update every service and integration that uses them.	Set by your credential rotation policy	Rotation log with owner, date and affected services
Admin user and extension review	Review the admin user list and installed extensions, and remove accounts or extensions no longer needed.	Set by your access review schedule	Signed access review record
Hardening baseline document	Record settings, versions, owners and last review date for TLS, admin access, password and 2FA policy, attachment storage and PostgreSQL access.	Update at every change and at each review	Baseline document kept under version control

What buyers and engineers ask before hiring help with OpenProject security hardening

Can the Community edition be hardened as fully as Enterprise?

Partly, because the features that differ are mainly identity features, while most of the security boundary sits outside the application. Single sign-on through SAML, OIDC, CAS, Kerberos or Okta, LDAP group synchronization and custom branding are listed as Enterprise features on the OpenProject pricing page, so a Community install relies on local accounts and must be secured with the password and two-factor settings available in your release. The rest of the work, including TLS termination, reverse proxy configuration, host firewalling, operating system patching, PostgreSQL network access and attachment storage permissions, applies to both editions. Confirm the current feature split on the pricing page before you decide, because editions can change.

How long does OpenProject security hardening take to complete?

The duration depends on how many layers you own and how much of the environment must change, so no single figure applies to every installation. The main drivers are the number of hosts involved (application, reverse proxy, PostgreSQL and file storage), whether the deployment is already live or still being built, how many identity sources and integrations must keep working after changes, and how quickly your change approval process and maintenance windows run. Teams with established Linux and proxy standards usually move faster, while undocumented installs add discovery time. Ask any provider for a written scope with deliverables and timelines before work starts, and confirm whether testing in a non-production environment is included.

What does OpenProject hardening work need from our own team?

It needs named owners, infrastructure access, a test environment and agreed change windows, and missing any one of these is a common cause of delay. Name an application owner for OpenProject configuration, an infrastructure owner for the hosts, network, proxy and database, a security reviewer who approves control decisions, and an identity owner if SSO or LDAP is in scope. The work also requires administrative access to the servers and database through your own change process, a staging copy that matches production in version and configuration, and maintenance windows for restarts and proxy changes. Agree on rollback steps before the first change is made.

Can our internal team harden OpenProject without an outside partner?

Yes, an internal team can do the work alone if it already has solid skills in Linux administration, reverse proxy and TLS configuration, PostgreSQL administration and identity integration for the features it uses. The OpenProject system requirements and installation documentation give the baseline to build from. A partner adds capacity, an outside review of control decisions, experience from other installations and written documentation that can support a compliance assessment. DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own infrastructure, but whether to hand over the work is your decision. Assess honestly where your skills fall short in those four areas before you start.

What should a quote for OpenProject security hardening include?

A quote should list the scope as named controls, the environments it touches, the deliverables and the acceptance checks, all in writing before work starts. Ask that each area be covered explicitly: TLS and reverse proxy settings, administrator and API access, password and two-factor policy, attachment storage permissions, PostgreSQL access controls and required extensions, backup and restore checks, and the patching procedure. Check whether testing, documentation and handover are included, what access the provider needs, who approves changes and what is excluded, such as identity provider work or Kubernetes changes. Also ask what recurs after the engagement, such as patch support or retainer hours, and what would change the price.

How is OpenProject patched after the hardening baseline is in place?

Patching becomes a routine release process, and the hardening baseline must be checked again with each upgrade. OpenProject has shipped several releases recently, including 17.7.0 on August 5, 2026, 17.8.0 on September 2, 2026, 17.9.0 on September 30, 2026 and 17.9.2 on October 15, 2026, so plan for a regular cadence. In each cycle, review the release notes for security fixes, test the update in staging, confirm that your TLS, administrator, storage and PostgreSQL settings still apply, and apply operating system and database patches on the same schedule. OpenProject requires PostgreSQL 16 or later, so confirm your database version stays within that requirement. Decide in advance who approves each update and how rollback copies are kept.

How DeployOpen scopes, hardens, hands over and supports OpenProject

DeployOpen plans, implements, hardens, documents and supports self-hosted OpenProject inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Work starts from a written, fixed scope so that the controls, evidence and handover items are agreed before any changes are made.

How we scope

Review your current or planned OpenProject install method, release and hosting environment before agreeing the hardening scope.
Agree in writing which areas are covered: TLS, admin and API access, password and 2FA policy, attachment storage, PostgreSQL access and patching.
Confirm which controls depend on the Community or Enterprise edition, such as single sign-on, so the scope matches your licence.
Document the owners, change windows and access you need from your team before work begins.

How we build

Apply TLS termination, certificate handling and HTTP security settings to your OpenProject endpoints in a staging environment first.
Tighten administrator accounts, API token use and password and two-factor policies according to the agreed design.
Restrict PostgreSQL network access and roles, and verify the required extensions remain in place after changes.
Configure attachment storage permissions and test each hardening change against the release you run, including patching within the release cycle.

How we hand over

Deliver a written record of each control applied, its configuration and the reason for the setting.
Provide verification steps and test results so your team can repeat the checks after future upgrades.
Document the patching routine, release monitoring and rollback steps for your administrators.
Walk your operations and security staff through the runbook and confirm acceptance against the written scope.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover reviewing new OpenProject releases and applying hardening changes within your change process.
Ask your DeployOpen contact which support tasks are included in a retainer and which are quoted separately.
Re-test hardened controls after major configuration changes, PostgreSQL moves or edition changes.

OpenProject security hardening