OpenProject for the public sector

The first decision is whether OpenProject runs as its own service on infrastructure your team operates, or arrives as the project component of openDesk, the Kubernetes-based digital workplace suite that ZenDiS GmbH develops for public administration. Both paths use the same GPL-3.0 licensed project software, but the operating model differs. Standalone, your team chooses the install method (Docker is the recommended option, with Helm charts for Kubernetes and .deb or .rpm packages for supported 64-bit Linux distributions), the database, the release timing and the identity integration. Inside openDesk, the suite's Helmfile and Helm deployment makes many of those choices for you. It requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later.

The upgrade model is the main reason to decide early. openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, so you cannot hold OpenProject on an older minor while you test a change. In-place upgrades between major versions are not guaranteed, and skipping several minor versions may require intermediate steps. Standalone, you set the release line and the timing, and you can follow OpenProject's own release notes for each 17.x patch. Inside openDesk, your change calendar, test environment and rollback plan must follow ZenDiS's schedule. Before committing, ask ZenDiS for the supported upgrade path from your current openDesk version to the next major, and whether any OpenProject database migrations in those releases need manual steps.

The database and service requirements differ between the two paths, and this is where teams most often find a conflict. openDesk's production guidance expects external services including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Standalone OpenProject officially supports PostgreSQL 16 or later and requires the pg_trgm, btree_gist and unaccent extensions. Confirm with ZenDiS which PostgreSQL version and extensions the bundled OpenProject component uses, and whether your platform team can run that version alongside the other openDesk databases. For sizing, OpenProject's guide suggests 4 cores and 4 GB of 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. Inside openDesk, ask ZenDiS how those figures map to the pods and resource limits in the suite, since the 12-core evaluation minimum applies to the whole suite and is not a production sizing.

The Enterprise layer changes both cost and support. ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed 2nd and 3rd level support and patches. The openDesk Enterprise documentation lists OpenProject Enterprise add-ons among the Enterprise-only features. Standalone, OpenProject Enterprise on-premises is licensed per named user per month: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, Premium at 15.95 euros with a 100-user minimum, and Corporate on request for 250 or more users. Those Enterprise features include SAML, OIDC, CAS, Kerberos and Okta single sign-on, LDAP group synchronization and custom branding. Ask ZenDiS exactly which OpenProject add-ons are covered by an openDesk Enterprise subscription, which would still need a separate OpenProject license, and how single sign-on is wired in the suite.

Before choosing, take three checks. Your platform team should confirm it already runs or can run Kubernetes at v1.33 or later with Helmfile, cert-manager, an ingress controller and production-grade PostgreSQL, Redis, SMTP and object storage, and that it can accept a monthly minor-version cadence. Your security and compliance leads should confirm who approves the suite's release calendar and how patches are tested. Your procurement lead should request a written statement from ZenDiS on the supported versions, the upgrade path, the Enterprise scope and the support terms, and should compare that with a standalone OpenProject quote built from the user counts and feature list you need. The latest openDesk release at research time was v1.19.1, published on 2026-10-06, so ask which release line your deployment would start on.

The section's core point is that OpenProject sits inside a wider agency estate, and three decisions shape that fit before any installation begins: how users sign in, where files and attachments live, and which database holds the project record. Agencies that settle these early avoid rework when the directory, the file platform or the hosting model changes later. Identity. OpenProject can be connected to the agency's identity provider through single sign-on, and the Enterprise plan lists SAML, OIDC, CAS, Kerberos and Okta among its supported options, with LDAP group synchronization also included. Confirm with your identity team which SSO protocols the agency's provider actually supports, whether the provider is on premises or hosted, and whether it can issue the claims or attributes OpenProject needs. Equally important, agree who owns group mappings: the team that manages the directory, the project management office, or the OpenProject administrators. Unowned mappings are the usual source of users who can sign in but cannot see the projects they need.

The file storage path is a separate decision. OpenProject's Nextcloud integration, available in the Community edition, links Nextcloud files and folders to work packages and can manage project folders automatically. Single sign-on through an OpenID Connect provider for that integration is an Enterprise add-on, so the identity design and the licensing conversation should happen together. Decide which system is the source of truth for documents, whether attachments stay in OpenProject, and who is responsible for permissions on linked folders. Where the agency already runs Nextcloud under its own controls, confirm the integration's behavior against the release you plan to deploy rather than relying on general descriptions. Data and logs. Project records, work packages, comments, attachments and audit information are held by the OpenProject application and its PostgreSQL database, while attachments and logs sit on the storage and log destinations you configure on the host. Map each location to a backup scope, a retention rule and a residency statement. Ask your implementation team to document where each category lands in your environment.

The database requirement is firm. OpenProject officially supports PostgreSQL 16 or later since OpenProject 16.0.0, and requires the pg_trgm, btree_gist and unaccent extensions. Confirm that your database platform can install these extensions, that your database team accepts them under local policy, and that backups and restores are tested with them enabled. Hardware should follow the supplied sizing guide: 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. Use these tiers as a starting point, then validate against your expected concurrency and attachment volume with the vendor or your partner before procurement.

Public bodies that run OpenProject on their own infrastructure still need to map where personal data can be reached from outside the EEA, because GDPR Chapter V applies to remote access as well as to storage. The EDPB's Guidelines 05/2021 (version 2.0) treat remote access from a third country as a transfer, even when the person only views data on a screen during a support or administration session. Article 44 requires every transfer, including onward transfers, to meet Chapter V conditions, and infringements of Articles 44 to 49 can attract fines of up to EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). The access map is therefore a compliance input from the start, not a hosting detail to settle later.

The Data Privacy Framework is the first condition to check, but it is not a settled basis for a long-term deployment. Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List. The General Court upheld the decision in September 2025, and an appeal is pending as Case C-703/25 P. Confirm whether each US-linked vendor is listed today, and plan a fallback using standard contractual clauses under Commission Implementing Decision (EU) 2021/914. Schrems II (Case C-311/18) invalidated Privacy Shield but held that standard contractual clauses remained valid, provided the exporter assesses the destination. EDPB Recommendations 01/2020 state that where a provider needs data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned.

The legal reach of a provider's home jurisdiction matters even when data stays in an EU data center. The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever it is located. GDPR Article 48 limits recognition of a third-country court or administrative order requiring disclosure to cases based on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. The EDPB's Example 12 says using an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be, so the exposure should be assessed before engagement. Article 32 of the EU Data Act (Regulation (EU) 2023/2854) requires data processing service providers to take technical, organizational and legal measures against third-country governmental access to non-personal data held in the Union, and it has applied since 12 September 2025. It complements the GDPR analysis and does not replace it.

Before engaging any processor, map every person and system that can reach the OpenProject instance. Include DeployOpen engineers, your own administrators, the staff of your cloud or data center operator, Kubernetes and database operators, backup and monitoring providers, SMTP relays, log shipping services and any OpenProject GmbH support channel you use. For each one, record the legal entity, parent company, country of incorporation, the location from which access happens, the access method (remote session, VPN, bastion or ticket attachment), the data classes involved and the transfer mechanism relied on. Confirm whether a screen-sharing session counts as access under your assessment. Document the transfer impact assessment and obtain sign-off before the contract is signed, and write the access restrictions into the processor agreement. Where you plan to use openDesk, its bundled components each have their own vendors, so the same mapping applies to the whole suite.