Which OpenProject install method fits your team
If you are a platform team setting one standard for a self-hosted OpenProject instance, the answer is short: OpenProject's installation documentation recommends Docker Compose for smaller instances and Helm for larger ones. Docker Compose is the recommended isolated setup, and the Helm chart is aimed at Kubernetes deployments that need horizontal scaling. Choose Docker Compose if you run a single host or a small number of hosts and your team is comfortable operating Docker. Choose Helm only if you already run Kubernetes, have people who operate it, and expect enough load to justify the extra moving parts.
DEB and RPM packages make sense when your organization already standardizes on one of the packaged distributions and wants OpenProject managed through the system package manager like other services. The system requirements list Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15 as supported for packaged installs, so confirm your exact release against that list before committing. The single all-in-one container is best treated as a stopgap for evaluation or a short-lived test, not as the production standard, because it bundles components that you will later need to separate, back up and upgrade on their own.
The choice is about upgrades, backups and the skills your team already holds, not features. All install methods run the same OpenProject release line, so the question is who performs each upgrade, how database and attachment backups are taken and restored, and which tooling your on-call engineers can debug at 2 a.m. Before you decide, confirm with OpenProject which upgrade path it documents for each method, and test a restore from a backup on each candidate setup in a non-production environment. Your team's existing container or Kubernetes practice is usually the strongest signal.
Docker Compose, packages, all-in-one container and Helm compared
This table compares the four documented OpenProject install methods and one requirement that applies to all of them. Read each row as a decision input: isolation, supported platforms, scaling, upgrades, backups, skills and typical instance size. The main takeaway is that Docker Compose is the documented default for smaller instances, while Helm is the documented route when you need horizontal scaling on Kubernetes.
| Dimension | Docker Compose | DEB or RPM packages | All-in-one container | Helm chart |
|---|---|---|---|---|
| Isolation model | Recommended isolated setup with its own containers for the application and supporting services | Installed on the host through the system package manager | Single container running the full stack | Runs on a Kubernetes cluster you already operate |
| Supported platforms | Any host that runs Docker, per the installation documentation | 64-bit Linux on limited distributions: Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x, SUSE Linux Enterprise Server 15 | Any host that runs Docker, per the installation documentation | Kubernetes, per the system requirements; confirm your cluster version with OpenProject |
| Scaling | Vertical scaling of one host; the documentation recommends it for smaller instances | Vertical scaling of one host | Vertical scaling of one host; not the documented route for larger instances | Horizontal scaling, which is the documented reason to choose it |
| Upgrade path | Pull the newer image and restart; confirm the exact steps for your version in the release notes | Upgrade through the system package manager on a supported distribution | Replace the container image; confirm the exact steps for your version | Upgrade the chart release; confirm chart values and version pinning before you start |
| Backup approach | Back up the PostgreSQL database and the attachment and configuration volumes together | Back up the PostgreSQL database and the files under the install paths | Back up the external PostgreSQL database and any mounted data volumes | Back up the PostgreSQL database and persistent volumes; confirm snapshot consistency with your storage class |
| Operating skills | Docker and Linux administration, plus PostgreSQL basics | Linux administration and package management on a supported distribution | Container runtime operation with an external PostgreSQL database | Kubernetes operation, Helm releases, persistent storage and ingress |
| Typical instance size | Smaller instances, per the installation documentation | Single-host installs within the sizing guide | Single-host installs within the sizing guide | Larger instances that need horizontal scaling, per the installation documentation |
| PostgreSQL 16 or later with pg_trgm, btree_gist and unaccent extensions | Required; provision the extensions before first start | Required; provision the extensions before first start | Required; provision the extensions on the external database | Required; provision the extensions in the database the chart connects to |
How the OpenProject components fit together under each method
Every OpenProject install method has to place the same three pieces: the OpenProject application, a PostgreSQL database at version 16 or later with the pg_trgm, btree_gist and unaccent extensions, and file storage for attachments. The methods differ in who packages those pieces and where they run. Before you standardize, confirm the exact service layout for your target version in the OpenProject installation documentation, because the set of services and their default ports can change between releases. Treat that check as a step in your design review, not a footnote.
Package installs (DEB and RPM) run the application and its services directly on the host operating system, under the system's own service management. Your team manages PostgreSQL, the web layer and the file path on that host, and the supported list is narrow: Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, per the OpenProject system requirements. Docker Compose and the single all-in-one container run the same kinds of services as containers on one Docker host, with the network and volumes defined in the deployment files. Helm runs them as pods, so the database, application and storage become cluster resources with their own service endpoints and persistent volume claims.
The placement difference changes how you build the network and the reverse proxy. On a package install, the TLS terminating proxy usually sits on the host and points at a local port, and the database listens where you configure it. In Compose or Helm, the proxy must reach a container or service name and you must decide which service is published externally and which stays on an internal network. Confirm which ports each container or service exposes, where attachments are stored in a volume or claim, and whether the database is reachable from outside the stack. Those answers drive your firewall rules, backup targets and disaster recovery steps.
Decision points that push a team toward one method
Five conditions tend to decide the install method for OpenProject: existing Kubernetes, user count, host OS, network restrictions, and team skills. Walk through them in order, because the first condition that applies often settles the rest.
Existing Kubernetes platform
If your organization already runs a supported Kubernetes platform with an operations team, the Helm chart fits the way you deploy other services. Check that your cluster team can own persistent storage, PostgreSQL, ingress and backups before choosing it. If no one already runs Kubernetes, the Helm chart adds a platform you must patch and monitor just for OpenProject, which is usually the wrong trade.
User count and sizing tier
OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. The documentation recommends Docker Compose for smaller instances and Helm for larger ones. Confirm your concurrent load and growth with the vendor before you size hosts, since named user counts are not the same as active sessions.
Host OS on the package list
DEB and RPM packages are supported only on a limited set of distributions. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. If your standard image is outside that list, a packaged install means you maintain the OS support risk yourself, and Docker Compose becomes the more predictable path. Verify the exact supported versions against the current requirements page before you commit.
Air-gapped or restricted networks
Where hosts cannot pull images from public registries, you need a plan for mirroring container images or installing from internal package repositories. Docker Compose and the all-in-one container both depend on image delivery, while packages depend on your internal repository mirror. Ask DeployOpen or the vendor which artifacts must be staged, how updates arrive, and how each release is verified before it enters the restricted network.
In-house container skills
Docker Compose is the recommended isolated setup, so teams comfortable with container runtimes, volumes and environment files can operate it with modest added tooling. Teams without container experience often find packages easier to patch through their normal OS process. Be honest about who will run upgrades: someone must read release notes for each minor version, such as 17.9.0 on September 30, 2026, and apply changes to the stack.
Need for horizontal scaling
Horizontal scaling is the main reason the documentation points to Kubernetes with Helm charts. If you expect to add application replicas across nodes, Helm is the method built for that layout. Compose and packages run on a single host, so growth beyond one machine means redesigning the deployment. Confirm the database and file storage architecture with your team before assuming horizontal scale works end to end.
What upgrades and backups mean for each install method
Docker Compose is the setup OpenProject's installation documentation recommends for smaller instances, so it is the baseline other methods should be measured against. An upgrade means changing the image version the stack pulls, recreating the containers and letting the release apply its database migrations. Because the stack is defined in files you control, the backup scope is clear: the database, the attachment storage and the configuration and secrets.
- Upgrade path: Move between minor releases such as 17.9.0 (September 30, 2026) and 17.9.2 (October 15, 2026) by changing the pinned image tag and recreating the stack.
- Database: Dump PostgreSQL before each upgrade. OpenProject requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, so confirm they are present after a restore.
- Attachments: Back up the volumes holding uploaded files. A database restore without matching attachments leaves broken references.
- Secrets: Keep the environment file and the secret key base in a secrets manager as well as on the host. Confirm the exact variable names in the installation docs.
- Drift risk: Local edits to upstream Compose files and floating image tags make upgrades hard to reproduce. Keep changes in an override file under version control.
Before sign-off, confirm who owns the restore test, when it last ran and that it completed on the target version.
Packaged installs go through the operating system's package manager, which makes OpenProject part of your normal host patching cycle. The documented distributions are limited: Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Upgrades arrive as package updates, so the upgrade path depends on both the OpenProject release and the operating system lifecycle.
- Upgrade path: Package upgrades follow the monthly releases, but unattended OS updates can pull in changes on a different schedule. Pin or hold packages where your change process requires it.
- OS lifecycle: A distribution upgrade may be needed before a newer OpenProject release is supported. Plan the two together.
- Database: Back up PostgreSQL on a schedule that matches the package update window, and confirm the PostgreSQL 16 version and required extensions.
- Attachments and configuration: Back up the data directories and configuration files the package uses. Confirm their locations in the system requirements and installation docs before you write a backup job.
- Drift risk: Hand edits to packaged configuration can be overwritten on upgrade, and manual host changes are rarely captured in a runbook.
The restore test should run on a host built from the same distribution and package versions, so confirm the owner and the recorded result before relying on it.
The single all-in-one container packages the application in one image, which can be quick to start for evaluation. OpenProject's documentation recommends Docker Compose for smaller instances, so the all-in-one image is a different path that needs its own verification. Upgrades replace the container with one built from a newer tag, and the results depend on where the data sits.
- Upgrade path: Replace the container with a newer tag and confirm the migrations complete before users return. Test this on a copy first.
- Database location: Confirm whether PostgreSQL runs inside the container or outside it. A bundled database complicates separate backup and upgrade schedules.
- Persistent storage: Map attachment and data paths to volumes outside the container layer. Without them, removing the container can remove the data.
- Secrets: Pass secret values through your secrets tooling rather than baking them into the image or the run command.
- Drift risk: Teams often start with one container and later need Compose or Helm features. Moving data between methods is a migration project, so confirm the supported path with OpenProject before going live.
Write down which volumes and external services the backup covers, and ask the owner of the restore test to restore into a separate container to prove it works.
The Helm chart is intended for larger Kubernetes deployments, where OpenProject's documentation recommends Helm and horizontal scaling. Here an upgrade changes the chart version and the values files, and the cluster applies the change. Backups cross several layers: the database, the file storage behind the persistent volumes, the values and the Kubernetes secrets.
- Upgrade path: Upgrade the chart and values together, review the rendered changes and keep the Helm release history so you can roll back to a known revision.
- Database: Confirm whether PostgreSQL is managed inside or outside the cluster, and whether its backups meet your recovery needs. Confirm the PostgreSQL 16 requirement and extensions.
- Attachments: Snapshot or back up the persistent volumes, and confirm the storage class supports the snapshot method you choose.
- Secrets: Store Kubernetes secrets with encryption at rest, and back up the values files in version control with secret references instead of plain text.
- Drift risk: Manual
kubectledits that bypass the values files are the most common source of drift. Require every change to pass through the chart.
The platform team usually owns the restore test, and the scope of any retainer support should be written down before go-live.
Questions teams ask before standardizing on an install method
Which OpenProject install method does the documentation recommend?
Docker Compose is the recommended setup for an isolated install, and the documentation recommends it for smaller instances, with Helm charts for larger ones. Packages, a single all-in-one container and Kubernetes are also documented. The sizing guide gives a starting point of 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. For one site with a modest user count, standardizing on Compose keeps the operating model simple. Choose Helm when you already run Kubernetes and need horizontal scaling. Confirm current guidance in the installation documentation, because it changes with releases.
Are OpenProject DEB and RPM packages safe on any Linux distribution?
No. Packaged installs are supported only on a limited set of distributions: Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, according to the system requirements. On any other distribution, you carry the risk of dependency mismatches and undocumented behavior, and you should not assume a supported path exists. Check the list against your exact release before you build. Packages also tie OpenProject upgrades to your operating system patch cycle. Since OpenProject 16.0.0, PostgreSQL 16 or later is required, along with the pg_trgm, btree_gist and unaccent extensions, so confirm your distribution ships a compatible version or plan to manage it yourself.
Do I need the Helm chart for high availability?
Not necessarily. The documentation lists Kubernetes with Helm charts for horizontal scaling, but high availability depends on how you run the database, file storage and ingress. The chart does not make those layers redundant on its own. A single well-managed Compose host with a tested PostgreSQL backup and restore process may meet your recovery target, while a Kubernetes cluster adds value only if every layer around OpenProject is also redundant. Ask OpenProject exactly what availability the chart provides, what it expects from your database and storage, and how failover is tested. Write your recovery time and recovery point targets first, then choose the method that meets them.
How do OpenProject upgrades differ between Compose, packages and Helm?
The upgrade mechanics follow each method's tooling. With Docker Compose, you change the image version, pull the new image and restart the stack. With packages, you update through the system package manager, so OS patching and OpenProject updates share one change window. With Helm, you update the chart and values, then roll out the new release on the cluster. Minor releases arrive roughly monthly, for example 17.7.0 on August 5, 2026, 17.8.0 on September 2 and 17.9.0 on September 30, 2026. Read the release notes before each minor version, test the upgrade on a copy of production data, and confirm that the database migration and PostgreSQL requirements still hold.
What must an OpenProject backup include?
A usable OpenProject backup has three parts: the PostgreSQL database, the uploaded attachments and file storage, and the configuration and secrets needed to start the application again. The database and file storage must come from the same point in time, or restored work packages may point to missing files. Include the PostgreSQL extensions in your restore plan, since the database requires pg_trgm, btree_gist and unaccent. The exact procedure differs by install method, so take it from the installation documentation for your chosen method. Restore the backup to a separate host at least once a quarter, and record how long the restore took, so the recovery target you promised is one you have tested.
How much skill and staff time does each install method need?
The main cost is staff time, and it depends on the skills you already have. Compose requires Docker and Linux administration. Packages require operating system administration plus PostgreSQL management, including the required version and extensions. Helm requires Kubernetes operations, storage, ingress and monitoring. One-time work includes the build, network and identity integration, and backup testing. Recurring work includes monthly minor upgrades, patching and restore tests. Enterprise licensing is separate from the install choice and is charged per named user: the OpenProject pricing page lists Basic at 5.95 euros and Professional at 10.95 euros per user per month with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. Ask any vendor or partner for a quote that itemizes these components.
Is an outside partner worth it for an OpenProject installation?
A partner is worth considering when no internal team owns the install, the database, upgrades and backup testing. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing upgrades and support are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ask for a written scope that names the install method, database ownership, backup tests and upgrade responsibilities.
How to standardize on one method without locking yourself in
This sequence turns the install choice into a documented, tested standard, so each environment has a known method, a repeatable upgrade and backup routine, and a planned path if the instance outgrows it.
Inventory hosts and Kubernetes capacity
The platform or infrastructure team lists every environment that will run OpenProject, including the Linux distributions and versions on the hosts, any existing Kubernetes clusters, and the CPU, memory and storage each can give to the application. Record the expected user count and whether a single host is enough. The step is done when each environment has a one-line entry with its operating system, orchestration option and capacity, so the method choice in a later step rests on facts instead of habit.
Confirm the OpenProject version and PostgreSQL extensions
The engineering lead picks the target release from the OpenProject release notes and confirms it against the system requirements for that release. Check the supported PostgreSQL major version, which OpenProject documents as PostgreSQL 16 or later since 16.0.0, and confirm that the pg_trgm, btree_gist and unaccent extensions can be created in the database your team operates. The step is done when a written note records the chosen release, the database version and the extension check result for each environment.
Pick the install method for each environment
Using the inventory, the team assigns one method per environment: Docker Compose for smaller single-host instances, which OpenProject's installation documentation recommends for smaller deployments, DEB or RPM packages only where the host runs one of the supported distributions, the all-in-one container for evaluation or narrow cases, and the Helm chart for larger Kubernetes deployments. Record the reason for each choice. The step is done when the decision log names one method per environment and states which distribution or cluster it depends on.
Write the upgrade and backup runbook
The operations team writes one runbook per method covering how to take a backup of the database and attachments, how to stop the services, apply the new release using that method's own upgrade steps, run any migration tasks the release notes require, and verify login and core pages afterwards. Keep the runbooks in the same format so that staff can follow any of them. The step is done when every runbook has been reviewed by someone who did not write it and matches the current installation documentation for the release in use.
Test a restore in a separate environment
The team restores the most recent backup into an isolated environment built with the same method and the same PostgreSQL extensions, then starts OpenProject and checks projects, work packages, attachments and user sign-in. Time the restore only for internal planning, since no duration is set here. The step is done when the restored instance matches the source for a defined set of test records and the result, including any gaps, is written into the runbook. A backup that has never been restored is not yet a backup.
Test an upgrade on a copy first
Before the production upgrade, the team applies the target release to the restored copy using the runbook and records every manual step, error and configuration change it needed. The output is a corrected runbook and a go or no-go decision signed by the service owner. Confirm the upgrade path against the current OpenProject documentation for the release, because the steps differ by install method. The step is done when the copy runs the new release and the production change window is booked on that evidence.
Document the switch-over path if the instance outgrows its method
The architecture owner writes the conditions that trigger a move, such as user growth past the sizing guidance, a need for horizontal scaling, or a host that no longer matches a supported distribution. For each trigger, the document names the target method, the data and configuration to carry over, the cutover steps, and the rollback plan. Ask the vendor or DeployOpen to confirm that the chosen path is supported for your release before you commit to it. The step is done when the switch-over plan is approved and stored with the runbooks, so the next method change is a planned project rather than an emergency.
What it costs to switch methods after go-live
Switching install methods after go-live is a migration, not a configuration change. Moving from Docker Compose to DEB or RPM packages, or from a single all-in-one container to the Helm chart, usually means a new host or cluster, a copy of the PostgreSQL database and the attachment files, and a fresh check of every integration that depends on the old address. Plan for a maintenance window, a rollback path that you have tested, and a cutover date agreed with the users who depend on the instance. Confirm with your implementation partner whether they will run the cutover as a fixed-scope piece of work, because that changes who carries the risk if something fails midway.
The data is the portable part. The PostgreSQL database and the attachment storage hold the work packages, projects, users and history, and they can move between methods as long as the target runs a supported PostgreSQL version with the required extensions, such as pg_trgm, btree_gist and unaccent. Check the release line of the source and target before you copy anything, because the two must be on compatible OpenProject versions. What must be rebuilt is everything around the data: the Compose files or package configuration, the Helm values, secrets handling, reverse proxy rules, backup jobs and the automation that deploys and upgrades the stack. None of that carries over automatically, and it is often the larger share of the effort.
Re-validate integrations after the move, not during it. Single sign-on through SAML, OpenID Connect or another Enterprise option depends on the public URL, certificate and redirect settings, so a new host name can break sign-in for every user even when the data copied cleanly. The same applies to LDAP group synchronization and any Nextcloud connection. Ask for the migration steps in writing, including the exact configuration keys that change, the order of database restore and file restore, and the test cases that prove sign-in, email and backups work before the old instance is shut down. Keep the old instance read-only until those checks pass.
How DeployOpen scopes and runs OpenProject deployments
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own infrastructure, including OpenProject. For this decision, we start by confirming which install method fits the user count, the Kubernetes footprint and the upgrade and backup rules your team must follow.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the chosen install method, target environment, and whether Docker Compose, packages or Helm is in use.
- Scope records the supported OS or Kubernetes platform, PostgreSQL version and required extensions, and sizing for the user count.
- Scope also states which OpenProject edition applies and whether SSO, LDAP group sync or other Enterprise features are included.
How we build
- We deploy OpenProject into your cloud account, data center or air-gapped network, using the method agreed in scope.
- Builds include PostgreSQL configuration, the pg_trgm, btree_gist and unaccent extensions, reverse proxy and TLS settings.
- Identity integration, backup jobs and restore tests are configured and checked against the written scope before handover.
- Hardening follows your internal baseline, and security testing can be added to the scope where your policy requires it.
How we hand over
- Handover documentation covers the runbook for the chosen method, including the exact upgrade path between minor releases.
- Backup and restore procedures are documented, with a record of the restore test your team observed.
- Your team receives configuration files, version pins and the list of components that must be upgraded together.
- Compliance evidence, such as configuration records and access controls, is organized for your independent assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover monitoring of new OpenProject releases, such as the 17.x line, and planned upgrades in your change windows.
- Quotes follow from the written scope, so ask for the upgrade cadence, backup verification and restore testing you need included.
- Ask DeployOpen to confirm, in writing, which OpenProject license terms and Enterprise tokens apply to your deployment.
