OpenProject high availability guide

What OpenProject high availability requires beyond a single server

A team that relies on OpenProject for daily planning and can no longer accept long outages or data loss needs an architecture change, and a larger single server will not meet that goal alone. High availability in this context means running more than one OpenProject application instance, a highly available PostgreSQL database and shared attachment storage on Kubernetes with Helm, supported by backups that the team has restored and tested. Each of these parts needs its own decision, and installing the chart does not finish the job. Plan for this before the first production cutover, because adding shared storage and database replication to a live instance is more disruptive than designing them in from the start.

The database holds the state that matters most. Work package data, project settings, users and permissions all live in PostgreSQL, so the database cannot be an afterthought or a single pod with a volume attached. OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions, so the team must confirm that whichever database service it chooses can install those extensions before it commits. Attachments sit outside the database. A failover or point-in-time restore of the database can leave work packages pointing to files that are missing or out of date. Application failover has a similar gap: the app may stay up while user sessions or attachment uploads fail if the replicas do not share session handling and file storage.

OpenProject supports Kubernetes with Helm charts for horizontal scaling, so running multiple application replicas starts from a supported path. Confirm the details before you commit: the chart version you plan to deploy, the OpenProject release it installs, the values that control replica count, session and attachment storage settings, and whether the chart manages PostgreSQL or expects an external one. Chart defaults and option names can change between versions, so read the documentation for the exact chart version you will run and test the upgrade path on a staging cluster first.

Decide early who owns each layer. The platform team typically covers the cluster and ingress, the database team or cloud team covers PostgreSQL replication and failover, the storage team covers shared attachment storage, and the OpenProject administrator covers release management and configuration. Ask the storage question first: every application replica must be able to reach the same attachment store, so confirm which access modes and backup methods your storage platform supports for that. Also write down the recovery targets the business accepts, meaning how much data loss and how long an outage are tolerable. Those targets drive replication design and backup frequency, so they should be set before vendors or partners are asked to quote.

A backup is only useful after a restore has succeeded. Back up the database and the attachment storage on a schedule that keeps them consistent with each other, or document how any gap between them is handled, because restoring one without the other reproduces the mismatch described above. Run restore tests into a separate environment at a regular interval. Check that work packages open, attachments download and users can log in, and record how long the restore took. Repeat the test after every OpenProject minor upgrade and every PostgreSQL version change, since those events are the most likely to break a restore path that worked before.

Which OpenProject components need redundancy and why

A highly available OpenProject design is only as strong as its weakest tier. Each component below fails differently, so each needs its own redundancy approach, and the failure modes connect them: a database outage stops the application, and a storage gap leaves work packages with broken attachments.

Application pods serving web and API

The pods run the web interface, the REST API and the background workers that the Helm chart deploys with the application image. If a single pod fails, user sessions on that pod are dropped and requests fail until it restarts. Redundancy means running more than one application pod behind a service, with health probes so traffic moves away from unhealthy pods. Confirm in your chart version whether sessions are stored centrally so users are not logged out during a pod replacement.

PostgreSQL holding all project data

PostgreSQL stores projects, work packages, users, groups and permissions, so it is the single component whose loss stops every workflow. Redundancy usually means a primary with one or more synchronized standbys and automated failover, managed either by a database operator or a managed service in your own cloud account. Confirm that the target setup provides PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, because a failover target without them will not run OpenProject correctly.

Attachment storage for uploaded files

Attachments live outside the database, so a database failover does not recover them. If application pods run on several nodes, each pod must see the same attachment files, or users will see missing files depending on which pod serves them. Options include a shared or network-backed volume and object storage, each with different durability and latency. Confirm the storage class and access mode your chart version requires, and test a file upload immediately after a pod restart.

Ingress and TLS termination layer

The ingress controller accepts all user traffic and terminates TLS, so its failure makes OpenProject unreachable even when every pod is healthy. Redundancy means more than one ingress controller replica, a load balancer that spreads traffic across them, and certificate renewal that does not depend on a single node. Confirm how the chart expects the public hostname and certificate to be configured, and verify that a certificate renewal does not interrupt active sessions.

Cache and background processing services

Depending on the chart version, OpenProject may deploy background worker and cache components alongside the web tier. A stopped worker delays jobs such as notifications and exports without an obvious error on the page, while a cache outage can slow every request. Redundancy depends on whether each service supports multiple replicas and shared state. Confirm the exact set of services deployed by your chart version and check each one's replica behavior before sizing.

Node and zone placement

Replicas only protect the service if they do not share the same failure domain. If all application pods, the database primary and the ingress controllers land on one node or one availability zone, a single host failure removes the whole platform. Use anti-affinity or topology spread rules, and confirm that the cloud or data center layout gives each tier a separate node pool. Plan this placement with the infrastructure team, since it determines what a zone outage actually takes down.

Which high availability design fits your team

This table compares the main decisions behind an OpenProject high availability design: database hosting, attachment storage, Kubernetes placement and cluster sharing. Read each row as a choice whose operating cost continues after go-live, and use the last column as the question to put to your platform team. Install method is covered in the Docker and Kubernetes installation topic.

Decision and option	When it fits	Operational cost it adds	Question to ask the platform team
PostgreSQL: operator-run cluster	Team already runs Kubernetes operators and has database operations skills	Operator upgrades, failover drills, storage performance tuning, backup restore tests	Who patches the operator and runs failover tests, and how often?
PostgreSQL: external managed service	Organization standard requires a managed database with vendor-run failover	Service fees, network latency, checks that required extensions are available	Does the service enable pg_trgm, btree_gist and unaccent on PostgreSQL 16 or later?
PostgreSQL: VM-based standby	Small team with an existing VM estate and staff comfortable with replication	Scripted or manual failover, replication monitoring, OS patching on each node	What failover time have we tested, and who promotes the standby?
Attachments: shared network file system (ReadWriteMany)	Multiple OpenProject pods must mount the same attachment volume at once	Storage performance tuning under load, snapshot and backup coverage, file permission checks	Does our storage class support ReadWriteMany, and what latency does it hold under peak use?
Attachments: object storage	Organization already runs S3-compatible storage with versioning and lifecycle policies	Integration setup and testing, access key rotation, possible gateway or egress charges	Is object storage supported for attachments in the version we plan to run, and how is it tested?
Kubernetes placement: single zone	Lower-cost cluster where a zone outage is an accepted downtime risk	Full service loss during a zone outage, recovery runbook upkeep	What is the recovery procedure if the zone fails, and who runs it?
Kubernetes placement: multi-zone	Users must keep access through a single zone failure	Cross-zone data transfer, zone-aware scheduling, more node pools to patch	Do our storage and database replicate across zones, and have we tested a zone loss?
Cluster: dedicated	Regulated workloads need isolation, separate change windows or dedicated quotas	Separate control plane, monitoring and upgrade calendar to maintain	Which upgrade and patch windows apply to this cluster, and who approves them?
Cluster: shared	Platform team runs a mature shared cluster with tenant policies	Noisy-neighbor risk, shared upgrade schedule, namespace and network policy reviews	Which resource limits and disruption budgets protect OpenProject from other tenants?

How to build OpenProject high availability in order

This sequence takes OpenProject from a single instance to a deployment where application pods, the database and attachment storage are each designed to keep the service available if one layer fails. Each step ends with a check, so the team confirms one layer works before building the next. Confirm the exact values for your environment against the OpenProject release notes and system requirements.

Confirm the target release and PostgreSQL requirement
Pick the OpenProject release you will deploy and read its release notes and system requirements before ordering any infrastructure. The requirements page states that OpenProject officially supports PostgreSQL 16 or later since OpenProject 16.0.0, so the database major version follows from the release choice. Record the Helm chart version, image tag and PostgreSQL major version in your change record. This step is done when the platform owner has signed off on one written version set.
Provision a highly available PostgreSQL cluster
Build a PostgreSQL cluster in your own infrastructure with one primary, at least one streaming replica and automatic failover, using the operator or managed service your platform team already runs. Place replicas in separate failure domains where your environment allows it. Ask the database team which connection endpoint OpenProject should use so that clients reach the current primary after promotion without manual edits. Check: stop the primary in a test window, confirm a replica is promoted, and confirm the endpoint resolves to the new primary.
Create the database and enable required extensions
On the primary, create a dedicated database and application role for OpenProject, then enable the pg_trgm, btree_gist and unaccent extensions in that database. Grant the application role only the privileges the installer needs, and keep superuser credentials out of the runtime configuration. Check: after the failover test, connect to the promoted replica and confirm all three extensions appear in the pg_extension catalog. A promoted node that lacks them can fail when OpenProject starts.
Provision shared attachment storage for all pods
Attachments must live on storage that every application pod can read and write, so provision a shared file system or object storage backend that your Kubernetes cluster can mount or reach. Confirm with the OpenProject configuration documentation which attachment storage options your chosen release supports, and confirm access modes and permissions with your storage team. Check: upload a file through one pod, then download it through a different pod after scaling or deleting the first, and confirm the content matches.
Deploy the Helm chart with two or more replicas
Install the OpenProject Helm chart with at least two application replicas, pointing the database settings at the highly available endpoint from the earlier steps and the attachment volume from the storage step. Keep secrets such as the database password and the application secret in your secret manager, and out of values files committed to version control. Check: confirm both pods reach ready status, sign in, delete one pod, and confirm a login made before the restart still works afterward.
Configure ingress and TLS termination
Expose the service through your ingress controller with a certificate issued by your internal or public certificate authority, and set the public hostname that OpenProject uses to build links. Confirm which proxy and HTTPS settings the release expects, and test HTTP to HTTPS redirects. Check: load the hostname from two networks, verify the certificate chain, and confirm that attachment links and notification emails use the https address.
Run and restore-test backup jobs
Schedule database backups and attachment copies or snapshots as separate jobs, with retention set by your recovery requirements. Store copies outside the cluster in a location the application service account cannot delete. Check: restore the latest database backup and the matching attachments into an isolated namespace, start OpenProject against them, and confirm a known project and file are present. Treat a backup as valid only after this restore test passes.

How PostgreSQL failover affects OpenProject sessions and attachments

A PostgreSQL failover changes which node accepts writes, so OpenProject has to keep working through that switch. OpenProject officially supports PostgreSQL 16 or later since version 16.0.0, and it requires the pg_trgm, btree_gist and unaccent extensions. Every node that a failover can promote must have all three extensions installed and must run a supported version. A standby that lacks them can be promoted successfully at the database level and still cause errors when OpenProject runs its queries. Ask your platform team to verify the extensions and the PostgreSQL version on each standby, not only on the primary, and to repeat that check after every PostgreSQL or OpenProject upgrade.

Failover affects in-flight writes first. Transactions that were not committed and confirmed by the replica at the moment of the switch are rolled back or lost, depending on how your platform replicates. Requests that reach the old primary during the switch return errors, and any connection still open to that node stops working. Connection pools make this harder, because they keep stale sockets that look open to the application until a query fails. The application must discard those connections and open new ones against the new primary. Confirm whether a proxy or pooler sits between OpenProject and the database, whether it redirects traffic automatically, and how quickly it detects a dead node.

Users feel a failover as a short disruption in their sessions. Requests in progress may show errors, forms may need to be submitted again, and some users may be asked to sign in again if session data is tied to the failed node. Background jobs that were writing when the switch happened need to resume or retry without duplicating work. Before go-live, run a planned failover in a staging environment that matches production. Record what users see, whether the application reconnects without a restart, and whether background work completes. Decide in advance who communicates with users and what message they receive during the disruption.

Attachments stored outside the database are not protected by database replication. After a failover, the database points to a new primary, but the files that its records reference must still exist on storage that the application can reach. If the file store is not replicated or is out of step with the database, records can point to files that are missing. Plan redundancy for the attachment storage separately, and define how the database and file store are backed up and restored to the same point in time. Ask your partner for a consistency check that finds attachment records without files, and confirm the replication and recovery behavior of your storage platform with its vendor.

How the high availability setup changes by environment

A single-node Kubernetes cluster suits a test environment or a small team that can accept planned downtime. Pod restarts are covered: if the OpenProject container or a supporting pod fails, Kubernetes schedules a replacement. The node itself is the single point of failure, so losing it takes the application and its storage access offline until the node returns or the cluster is rebuilt.

Protects against: container crashes and failed health checks that a restart can clear.
Leaves exposed: node hardware failure, kernel faults, planned node maintenance and any zone or data center outage.
Database placement: PostgreSQL usually runs on a single instance, so a database failure has no second copy to fail over to.
Extra work: restore testing from backups becomes the main recovery path, so the team must rehearse it and record the results.
Storage: attachments usually sit on a single volume that needs its own backup schedule, separate from the database.

Before accepting this model for anything beyond testing, confirm with the team how long an outage the users can tolerate and who performs a restore.

What drives the effort and cost of OpenProject high availability

This table lists the main drivers of effort and cost for a highly available OpenProject deployment on Kubernetes. Each row explains why the driver changes the work, how to keep it under control, and whether the cost is one-time or recurring. The main takeaway is that user count and the number of environments set the infrastructure baseline, while retention, compliance evidence and team skills decide how much work sits around it.

Driver	Why it changes effort or cost	How to keep it down	One-time or recurring
User count	Sizing guide lists 4 cores and 4 GB RAM up to 200 users, 8 and 8 near 500, 16 and 16 near 1,500.	Confirm per-replica requirements with OpenProject before fixing node sizes, and size from active users.	Recurring, as compute and licensing grow with the user base
Attachment volume and growth	Shared attachment storage grows with every upload and must be reachable from all replicas.	Estimate yearly growth, agree a retention rule for old files and review storage class costs early.	Recurring, as storage is kept and backed up
Number of environments	Each environment repeats the cluster, database, storage and backup setup.	Keep test and staging smaller and refresh them from sanitized backups instead of building each by hand.	One-time to build, recurring to run and patch
Identity integration	SSO and LDAP group synchronization are Enterprise features and need identity provider configuration.	Confirm which identity features your edition includes and plan user provisioning before build starts.	One-time setup, with recurring Enterprise licensing per named user
Backup retention and restore time targets	Longer retention raises storage, and faster restore needs tested standby capacity and runbooks.	Write retention and restore targets in writing, then test a full restore on a fixed schedule.	Recurring, through storage and periodic restore tests
Compliance evidence needs	Assessors expect records of backups, restores, changes, patches and access reviews.	Generate evidence from the deployment pipeline and monitoring during the build, not afterward.	One-time to design, recurring to collect each cycle
Team Kubernetes and database skills	Gaps in Kubernetes, Helm or PostgreSQL skills extend build time and increase on-call load.	Assess skills before scoping, then train staff or bring in a partner for the first failover test and upgrade.	One-time for training, recurring for on-call duty
PostgreSQL version and extensions	OpenProject requires PostgreSQL 16 or later with pg_trgm, btree_gist and unaccent extensions, which every replica and failover test must match.	Standardize the database image, confirm extension availability with your managed service or operator, and pin versions.	One-time setup, recurring with each PostgreSQL and release upgrade

How to secure secrets, storage and network paths in a clustered setup

A highly available OpenProject deployment spreads credentials, attachments, backups and traffic across more components than a single server, and each of those paths needs its own control. The cards below cover only the controls that change because of the cluster design. General platform hardening is covered in the security hardening topic.

Keep credentials in the cluster secret store

Database credentials and the OpenProject secret key should live in the cluster's secret store and be referenced by the Helm release, not written into chart values files or committed to version control. With several application replicas, every pod must read the same secret key, so changing it requires a coordinated rollout. Check who can read the secret objects and whether secret access is audited.

Restrict database access by network policy

PostgreSQL should accept connections only from the namespace that runs OpenProject, and ideally only from the application pods' labels. Confirm that the failover endpoint used by the highly available database is covered by the same policy, so a promoted replica does not break connectivity or open a wider path. Test the policy by attempting a connection from a pod in another namespace.

Encrypt attachment storage and backups

Attachments are shared across replicas on storage that the cluster reaches over the network, so encryption at rest must be confirmed for that volume or object store and for every backup copy. Backup copies often outlive the live data and sit in less controlled locations, which makes them a common gap. Ask your storage provider which encryption options apply and who holds the keys.

Separate backup and runtime credentials

The identity that writes backups and the identity that serves users should be different, with different scopes. A backup job needs read access to the database and attachments and write access to the backup target, while the application needs neither the backup target credentials nor the ability to delete backups. Review both sets of credentials on the same schedule and rotate them independently.

Encrypt traffic between ingress and pods

TLS terminates at the ingress by default, but the path from the ingress controller to the OpenProject pods and from pods to the database may cross nodes and namespaces. Decide whether that internal hop must be encrypted based on your data classification and network trust model, then confirm the certificate chain and rotation process. Record the decision so auditors can trace how each hop is protected.

Validate the controls after each change

Secret rotation, network policy edits and storage changes can silently weaken an earlier control in a clustered setup. Build a short checklist that confirms secrets are referenced rather than inlined, policies block cross-namespace database access, backup copies are encrypted and backup credentials cannot reach the runtime. Run it after every release upgrade and before any cutover.

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

Go-live starts the operating cycle, and the signals that matter most are pod readiness, database replication lag, failover events, storage growth and backup success. Alert on OpenProject pods that stay not ready across several probe cycles, and track restart counts per deployment so a crash loop does not hide behind a healthy average. For PostgreSQL, ask your database operator or DBA which replication lag metric it exposes, agree on a threshold with them, and confirm the alert reaches someone who can act on it. Log every failover event with its timestamp, then check that OpenProject reconnected to the new primary without manual intervention. Track volume usage for the database and the shared attachment storage each month, because attachment growth is easy to underestimate until a volume fills.

Backups need two layers. The database layer is either scheduled logical dumps or continuous archiving with base backups and write-ahead log archives, which allows point-in-time recovery. Choose based on the recovery point your business owners accept, and confirm with your PostgreSQL platform how archiving is configured in your cluster. The attachment layer is storage snapshots, and these must be taken at the same point as the database backup. If the two drift apart, a work package can reference an attachment that no longer exists after restore. Agree on the coordination method with your storage and database teams, document the expected gap between the two layers, and alert on every failed backup job so that a silent failure does not surface first during an incident.

OpenProject ships frequent minor releases, so upgrades are a recurring task rather than a one-time project. The release notes list 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. Each upgrade in a cluster needs a rolling-update check before and after the change. Read the release notes for database requirements, confirm that schema migrations run once and do not block the rollout, and verify that old and new pods can coexist during the update. After the rollout, check readiness across all pods, user sessions, login through your identity provider, and access to existing attachments. Confirm with the Helm chart documentation how migrations and rollout ordering are handled in your chart version, and rehearse the upgrade in a non-production environment first.

Write the runbook before go-live and keep it in version control next to the Helm values. It should cover the deployed OpenProject and chart versions, the PostgreSQL topology, storage classes, the backup schedule, the restore and failover steps, and the rollback path for an upgrade. List the on-call contacts for the platform, database, storage and identity teams, along with the escalation order and the hours each person covers. Confirm the coverage with your own team, because on-call arrangements belong to your organization. Review the runbook after each upgrade and after each test restore. Ongoing operations also consume recurring staff time, so ask any implementation partner which parts of monitoring, backup checks and upgrades are included in a retainer and which remain with your team.

How to prove the cluster fails safely before users depend on it

Application pods are the easiest component to lose and the failure users notice first. This test removes one OpenProject application pod, or drains one worker node, while test accounts are actively working. The goal is to see whether the surviving pods keep sessions and file uploads working without data loss.

Expected result: Signed-in test users keep their session or re-authenticate without losing unsaved work. An upload in progress either completes or fails with a clear error the user can retry.
Evidence to record: Timestamps of the pod deletion or node drain, Kubernetes events showing rescheduling, the readiness state of the remaining pods, and checksums of test files uploaded before and after the event.
Session storage: Confirm with your OpenProject release and Helm chart where sessions are held. This decides whether sessions survive a pod restart.
Shared attachment storage: Verify that the attachment volume is mounted on every application pod and that a file uploaded through one pod can be downloaded through another.
Action if it fails: Stop the test, review readiness and liveness probes, pod anti-affinity rules and the storage class, correct the cause, and rerun the test from the start before any user onboarding.

Check that the test ran with the same replica count, storage class and release that production will use.

Questions buyers ask about OpenProject high availability

Can our team build OpenProject high availability without a partner?

Yes, if your team already runs Kubernetes, a highly available PostgreSQL service and tested backups. Your in-house team needs these skills and assets:

Engineers who operate Kubernetes in production and manage Helm releases
A PostgreSQL platform with failover that you already run, on PostgreSQL 16 or later
Backup and restore runbooks that you have tested against a recovery target
Shared attachment storage on a storage class your cluster supports

Confirm the Helm chart and sizing against the OpenProject version you plan to deploy. Read the system requirements and release notes for that version before you start, because the chart values and resource needs can change between releases.

What drives the cost and timeline of an OpenProject high availability build?

The main drivers are user count, the state of your existing platform, and the number of integrations that must work before go-live. OpenProject's sizing guide lists 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. Larger tiers mean more nodes, more database capacity and more load testing.

Cost components:

One-time: design, cluster configuration, database setup, storage, backup and restore testing, and cutover
Recurring: cloud or data center infrastructure, database licensing or hosting, monitoring, and patching

Other drivers include identity integration, the number of environments, and approval cycles. No timeline is given here because it depends on those inputs. Ask for a fixed-scope quote that states the assumptions behind each figure.

What does an OpenProject high availability project need from our side?

Your team must provide access, decisions and approvals before the build can start. Most delays come from these items arriving late:

Cluster access with rights to create namespaces, deployments, secrets, services and ingress
Storage classes for shared attachments and a decision on the storage platform
The PostgreSQL platform choice, database credentials and confirmation that the required extensions can be installed
DNS records, TLS certificates and a load balancer or ingress path
Identity provider settings and network approvals for the cluster, database and storage traffic
Change windows for testing, cutover and rollback, plus one named owner on your side

Agree these responsibilities in writing so each party knows who approves what.

Do we need an OpenProject Enterprise edition for high availability?

Confirm this with OpenProject GmbH before you rely on it. The Enterprise features that OpenProject lists are single sign-on (SAML, OIDC, CAS, Kerberos and Okta), LDAP group synchronization and custom branding. High availability itself is not on that list, so the edition required for a clustered deployment must come from the vendor's current terms.

The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. If your design needs Enterprise identity features, such as SSO or LDAP group sync, price those as part of the project. Ask the vendor for written confirmation of the edition and the per-user terms that apply to your user count.

How do we ask for a fixed-scope quote for OpenProject high availability?

Send a written scope request that lists the facts a partner needs to plan the work. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so a complete request produces a more accurate quote. Include:

User count and expected growth, plus the OpenProject version and edition
The Kubernetes platform, Helm usage and the cluster you will use
The PostgreSQL platform, version and extensions
Storage options for attachments and backup targets
Identity integration and any LDAP group sync needs
Environments, acceptance tests and the restore test you expect
Target dates, change windows and your internal approval steps

Ask the partner to list assumptions and exclusions, and to state what your team must provide.

Which PostgreSQL version and extensions does OpenProject high availability require?

OpenProject officially supports PostgreSQL 16 or later, starting with OpenProject 16.0.0. It also requires the pg_trgm, btree_gist and unaccent extensions. Check these three items before you choose a database service for a clustered deployment.

Confirm that your managed or self-run PostgreSQL platform offers version 16 or later
Confirm that the three extensions can be installed and that your team has the rights to install them
Test a failover and confirm that the extensions and application connections still work afterward
Run a restore into a clean instance and confirm that OpenProject starts against it

Record the results in your design document before the build starts.

How do we confirm the Helm chart and sizing for our OpenProject version?

Compare the Helm chart values and resource requests with the sizing guide for your user count, using the documentation for the exact OpenProject release you plan to run. OpenProject supports Kubernetes deployments with Helm charts for horizontal scaling, but chart values and recommended resources can change between releases.

A practical check has four steps:

Read the release notes and system requirements for your target version
Deploy the chart to a staging cluster with production-like settings
Load test with a user count that matches your expected peak
Rehearse an upgrade and a restore before the production cutover

If any of these steps fails, adjust the sizing or chart values and repeat the test before you go live.

How DeployOpen scopes, builds and hands over OpenProject high availability

DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, and OpenProject high availability follows the same written-scope method. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Confirm the target cluster, cloud account or data center where the Helm-based OpenProject deployment will run
Agree the expected user count and sizing assumptions, using OpenProject's published sizing guidance as the starting reference
Define the PostgreSQL high availability design and confirm PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions
Record in the written scope which backup, restore testing and attachment storage components are included

How we build

Deploy OpenProject on Kubernetes with Helm and configure horizontal scaling of the application pods
Set up a highly available PostgreSQL cluster and verify the required extensions are installed before OpenProject starts
Configure shared attachment storage so every application instance reads and writes the same files
Run failover and restart tests to confirm the platform keeps serving work packages when a node or database member is lost

How we hand over

Document the Helm values, cluster layout, database topology and storage configuration as delivered
Deliver backup schedules, restore runbooks and the results of restore tests run against a copy of the data
Provide operating procedures for scaling, failover, certificate and secret rotation and OpenProject upgrade steps
Walk your platform and database teams through the handover and record open items in the written scope

How we support

Offer ongoing support, upgrades and periodic restore testing as a retainer after handover
Plan OpenProject minor release upgrades within the release cycle, with PostgreSQL version moves scoped separately
Confirm with OpenProject which support terms apply to your edition, since Enterprise support differs from partner support
Review scaling and capacity as user numbers change and adjust the written scope for new components

OpenProject high availability