When OpenProject Enterprise cloud fits and when on-premises does
Choose OpenProject Enterprise cloud when you want OpenProject to operate the platform and you are comfortable with its hosting and contractual terms. Choose Enterprise on-premises when your rules require the database, the server, or the file scanning to stay under your own control. The decision is about who runs operations and how much control you need, not about which edition has better features. Community is free and self-run, so it is the baseline for teams that want to host everything themselves without a subscription.
Cloud fits teams that would rather not staff backups, patching and availability. According to OpenProject's Enterprise cloud guide, the cloud edition includes regular backups, updates to the latest release and installation of security patches, all handled by OpenProject. For EU data residency, the OpenProject.eu infrastructure is documented as having no transfer to sub-processors outside the EU, and the Enterprise cloud FAQ states that Scaleway becomes the sole data center provider for the EU shard from March 2026. Confirm the current hosting region, sub-processor list and ISO 27001 scope for your shard with OpenProject before you commit, and get the backup restore and retention terms in writing.
On-premises fits teams that need direct database access, which OpenProject's FAQ points to the Enterprise on-premises edition for. It is also the path if you need ClamAV antivirus scanning, SVN or Git repository integration, or the Corporate plan, all of which OpenProject's pricing page marks as on-premises only. In that case you own upgrades, backups and the patch cycle, and your quote should cover the staff time to run them. Before deciding, list which of these three requirements are hard constraints and which are preferences, because any one of them alone can rule out cloud.
How the two hosting models compare on the facts
This table sets the documented facts for OpenProject Enterprise cloud against the Enterprise on-premises edition, row by row. Where the published facts are silent, the cell says what to confirm with OpenProject before you sign.
| Factor | OpenProject Enterprise cloud | OpenProject Enterprise on-premises |
|---|---|---|
| Where data is hosted | OpenProject.com runs on AWS in Frankfurt, Germany. From March 2026, Scaleway is the sole data center provider for the EU shard. | Your own servers, cloud accounts or data centers. OpenProject does not host the instance. |
| EU sub-processor transfers | OpenProject.eu has no transfer to sub-processors outside the EU, per the Enterprise cloud FAQ. Confirm the full sub-processor list in writing. | Determined by your own hosting and vendor choices. Confirm any external services your install uses. |
| Data center certification | OpenProject states that its AWS and Scaleway data centers are ISO 27001 certified. Ask for the current certificate scope and whether it covers your shard. | Depends on your hosting provider. Ask your provider for its own certification evidence. |
| Backups, updates and patches | OpenProject handles regular backups, updates to the latest release and security patches, per the Enterprise cloud guide. Confirm restore procedures and recovery objectives in writing. | Your team or your DeployOpen scope covers backups, upgrades and patching. Agree these responsibilities in the written scope. |
| Plans on-premises only | Corporate plan, ClamAV antivirus scanning and SVN and Git repositories are not offered on the cloud edition, per the pricing page. | Corporate plan, ClamAV scanning and SVN and Git repositories are available on premises, per the pricing page. |
| Licensing | Enterprise cloud pricing is not covered by the facts supplied. Confirm per-user rates, minimums and billing periods with OpenProject. | Priced per named user per month: Basic 5.95 euros, Professional 10.95 euros (25-user minimum), Premium 15.95 euros (100-user minimum), Corporate on request (250 or more users), per the pricing page. |
| Custom domain | Costs 100 euros per month, per the Enterprise cloud FAQ. Confirm whether this applies to both EU and global shards. | Not covered by the facts supplied. Confirm how branding and domain setup are handled on your install. |
| Trial period | A 14-day trial at start.openproject.com. An instance not upgraded is blocked and deleted automatically, per the pricing page. Confirm data export timing before the trial ends. | Not applicable to the on-premises install. Confirm the trial token and reversion process for self-hosted installs with OpenProject. |
What data location and ISO 27001 mean for your audit file
Hosting location, sub-processors and administrative access decide what an assessor will ask about an OpenProject Enterprise cloud instance. The cards below separate what OpenProject states about its providers from what you must confirm for your own environment and from the evidence DeployOpen can prepare.
Hosting location and the EU shard
OpenProject states that its main cloud infrastructure is hosted at AWS in Frankfurt, Germany, and that Scaleway becomes the sole data center provider for the EU shard from March 2026. Record which shard your tenant sits on, because the data residency statement in your file must match that shard. Ask OpenProject to confirm in writing which region holds your backups and any replicas, since the FAQ answers the question for the infrastructure, not for every copy of your data.
ISO 27001 at the data centers
OpenProject states that both its AWS and Scaleway data centers are ISO 27001 certified. This is a vendor statement about the facilities it uses, not a certificate covering the OpenProject service, your tenant or your own controls. Ask for the current certificate, its scope statement and the date of the most recent surveillance audit, and confirm whether that scope includes the application layer that your users actually reach.
Sub-processors and transfers
The FAQ states that the OpenProject.eu infrastructure has no transfer to sub-processors outside the EU. Map every sub-processor that touches your data, including email delivery, monitoring and backup tooling, and compare that list with your records of processing. Ask OpenProject for its current sub-processor list and how it notifies customers of changes, because a new sub-processor can alter your transfer analysis without any change on your side.
Administrative access to the platform
On cloud, OpenProject handles backups, updates and security patches, which means its operators can reach the systems that hold your project data. Document who at OpenProject can access production, under which approval and logging, and how your own administrators keep control of users, roles and SSO settings. On-premises you hold the root and database access yourself, which changes the access review you have to evidence.
Backups, patching and evidence
The cloud guide states that regular backups, updates to the latest release and security patch installation are handled by OpenProject. Your auditor will still ask for proof: backup schedules, restore test records, patch timing and the release level in use at each date in scope. Request these records from OpenProject as part of onboarding, and check whether they cover the period your assessment samples.
What DeployOpen prepares and what it does not
DeployOpen can plan the evidence pack for a self-hosted OpenProject, including access reviews, configuration records and the mapping of your controls to the systems in scope. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, and OpenProject's own certificates remain OpenProject's. Agree the evidence list in the written scope before work starts.
What OpenProject manages in the cloud edition
OpenProject takes over the platform operations of the Enterprise cloud edition. According to the Enterprise cloud guide, the cloud edition includes regular backups, updates to the latest release, and installation of security patches, all handled by OpenProject. For a CISO or platform lead, that shifts patch cadence and backup execution away from your team, which matters most if you have no spare operators for a self-hosted PostgreSQL and application stack. Note that the managed scope describes what OpenProject does, not how it is evidenced to you. Ask which change records, patch notes or backup logs you can request during an assessment.
Several operational decisions stay with your organization regardless of hosting. User lifecycle is the first: who is provisioned, who is deactivated, and how user counts change under the per-user billing model, which also determines what you pay each period. Project structure, roles, custom fields and workflows remain your configuration work. Integrations, such as identity provider connections for single sign-on, LDAP group synchronization, and the Nextcloud link, need settings that you must define and test against your own directory. Data classification, retention choices and access reviews also stay with you, because OpenProject operates the platform but does not decide what your teams store in it.
Before signing, get written answers on three points: restore timelines after an incident, backup retention periods, and the maintenance windows in which updates and patches are applied. Confirm whether a restore request is a standard or chargeable action, and whether maintenance windows can be scheduled around your change freeze calendar. Your contract or service description should state these terms explicitly, so compare them against your recovery time and recovery point objectives before you rely on the managed scope.
What your team runs in each model
In the Enterprise cloud model, OpenProject runs the application and its infrastructure. The Enterprise cloud guide states that the cloud edition includes regular backups, updates to the latest release and installation of security patches, all handled by OpenProject. Your administrators still own the work that depends on your organization: user lifecycle, role design, project structure, identity provider configuration and the decisions about what data goes into the instance.
- Operated by OpenProject: backups, release updates and security patch installation.
- Still owned by your admins: user provisioning, roles, project templates and workflow settings.
- Hosting location: the OpenProject.com infrastructure is hosted at AWS in Frankfurt, Germany, and the EU shard is served from Scaleway from March 2026.
- Paid add-ons: a custom domain is billed per month, and user counts change in steps of 5.
- Access to the database: cloud customers do not get direct database access, so teams needing that should review the on-premises option.
Before you commit, confirm the backup retention, restore testing and recovery objectives in writing with OpenProject, because those details shape your own continuity plan.
On your own servers, your team installs and runs OpenProject, either Community or Enterprise. The system requirements list Docker-based installation as recommended, with .deb and .rpm packages for 64-bit Linux. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, so check your distribution against that list before you standardize.
- Docker installation: the recommended path, which keeps the application stack in containers you control.
- Package installation: .deb and .rpm packages on the supported distributions listed above.
- Database: PostgreSQL 16 or later, with the pg_trgm, btree_gist and unaccent extensions enabled.
- 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.
- Scaling: Kubernetes with Helm charts for horizontal scaling in larger deployments.
Confirm your user count, growth plan and database hosting model against the sizing guide and the current system requirements page before you allocate hardware.
On-premises, your team owns patching, backups and upgrades. Nothing in the on-premises model is handled by OpenProject unless you have contracted it separately, so the operating calendar is yours to plan. Monthly minor releases, such as the 17.x line, mean that an upgrade process runs regularly rather than occasionally. Plan for test environments, change windows and rollback paths before the first production install.
- Patching: apply security fixes and operating system updates on your schedule.
- Backups: back up the PostgreSQL database and the attachment storage, and test restores on a routine basis.
- Upgrades: track each release, rehearse the upgrade in a non-production copy and document the rollback steps.
- Monitoring: watch application health, database load and disk growth against the sizing guide.
- Access control: manage the server, the database and administrator accounts with your own change process.
Ask your implementation partner or internal platform team to write the operating runbook, and confirm which tasks are covered by any support contract you buy.
Hardware and database choices drive most of the early cost on-premises. The sizing guide gives a starting point by user count, but actual load depends on how many projects, attachments and integrations you run. The PostgreSQL requirement is strict: OpenProject officially supports PostgreSQL 16 or later since version 16.0.0, and the required extensions must be present before the install or upgrade succeeds.
- Small teams: up to 200 users fits the 4 core and 4 GB RAM guidance.
- Mid-size teams: about 500 users matches the 8 core and 8 GB RAM guidance.
- Large teams: about 1,500 users matches the 16 core and 16 GB RAM guidance, which is where Kubernetes is worth evaluating.
- Extensions: pg_trgm, btree_gist and unaccent must be available to the database role that OpenProject uses.
- Database hosting: a managed PostgreSQL service must support these extensions, so verify this before selecting it.
Treat the sizing table as a minimum starting point, and confirm your database version and extension support with your database team before procurement.
The right environment depends on who must hold the data, who must run the operations and how much direct control your team needs. Cloud shifts routine operations to OpenProject, while on-premises keeps every layer under your control and your staff's responsibility. Neither model removes your duty to manage user access and project governance, and both need an agreed owner for every operational task.
- Choose cloud when: your team wants OpenProject to handle backups and patches and hosting in the EU is acceptable.
- Choose on-premises when: data must stay inside your own infrastructure or you need direct database access.
- Plan for either model: role design, SSO configuration and project templates remain your responsibility.
- Check plan limits: some features, including the Corporate plan and ClamAV scanning, are on-premises only.
- Budget the people: on-premises effort recurs through each release cycle, so account for it in staffing.
Before you decide, check the current feature availability on the pricing page and ask OpenProject to confirm the operational commitments in writing.
Which features and plans are on-premises only
Some OpenProject plans and features are only offered on your own servers, while others appear on the Enterprise pricing page without a confirmed cloud equivalent. Use these cards to sort what you need before you pick a deployment model.
Corporate plan
The Corporate plan is listed as on-premises only and is quoted on request for 250 or more users. If your organization is large enough to consider it, a cloud subscription will not give you this tier. Ask OpenProject for the written plan comparison and confirm which Corporate terms apply before you commit to cloud hosting for a large user base.
ClamAV antivirus scanning
ClamAV scanning of uploaded files is marked as on-premises only on the pricing page. Teams that handle file attachments from external parties should decide early whether they need this control. If it is a requirement, you will need to run the scanning inside your own infrastructure, and you should confirm with OpenProject what alternative file-inspection controls exist for cloud instances.
SVN and Git repositories
Subversion and Git repository integration is marked as on-premises only. Engineering teams that link code repositories to work packages should check this early, because moving repository hosting later can require a new integration design. Confirm with OpenProject whether any repository connection is available in the cloud edition before you plan your development workflow around it.
SSO and directory sign-in
The pricing page lists single sign-on through SAML, OpenID Connect, CAS, Kerberos and Okta, along with LDAP group synchronization, as Enterprise features. The facts do not confirm that every one of these options is available on each cloud plan. Check the feature matrix for your chosen plan and confirm how your identity provider connects before you sign a subscription.
Custom branding
Custom branding is an Enterprise feature on the pricing page. Separate from the custom domain fee, it determines how the instance looks to your users. Confirm with OpenProject whether branding options on the cloud plan you select match what your brand team expects, and whether a custom domain and branding are bundled or billed separately.
Direct database access
OpenProject points customers who need direct database access to the Enterprise on-premises edition. Reporting teams, data warehouse loads and custom auditing often depend on this access. If your plan depends on querying the database directly, choose on-premises hosting from the start, since the cloud service does not offer that path.
How to move from a Community install to Enterprise cloud
This sequence takes an existing OpenProject Community installation to OpenProject Enterprise cloud through OpenProject's upload service, with checks at each stage so users, roles and attachments can be confirmed before DNS and user access move.
Confirm the Community version and data scope
Record the OpenProject Community version you run, the projects, work packages, attachments, users and roles in scope, and any plugins or customizations that may not carry over. Confirm with OpenProject which versions and data types its upload service accepts before you commit to a date. Your owner is the OpenProject administrator, with input from the project leads who depend on the data. You know this step is done when you have a written inventory and OpenProject has confirmed in writing that the source version is eligible.
Request the upload service from OpenProject
Ask OpenProject to start the upload service for your instance, using the Enterprise cloud FAQ as the reference for how data is moved to the cloud. Ask them to state the steps, expected downtime, any data limits, and what they need from you, such as a database export or access window. Your owner is the administrator who holds the commercial relationship. You know this step is done when you have OpenProject's written plan and a named contact for the cutover.
Confirm the Enterprise cloud subscription and user count
Choose the Enterprise cloud plan and the number of named users before the import, because users can be added in steps of 5 and reductions take effect at the start of the next subscription period. Ask OpenProject to confirm how users imported from Community are counted against the subscription. Your owner is the finance or procurement contact, working with the administrator. You know this step is done when the subscription matches the user list from step one.
Set the custom domain if you need one
If users must reach OpenProject at your own hostname, order the custom domain option, which OpenProject lists at 100 euros per month in the Enterprise cloud FAQ. Ask OpenProject whether the domain should be set before or after the import, and who manages the certificate. Your owner is the DNS administrator, with OpenProject support. You know this step is done when the hostname resolves to the cloud instance in a test environment and the certificate is valid.
Validate users, roles and attachments after import
Before any user is invited, compare the imported data with your inventory from step one. Check that a sample of users can sign in, that project memberships and roles match the source, that work packages keep their relationships and history, and that attachments open and match their original size and name. Your owner is the administrator, with two or three project leads testing their own projects. You know this step is done when each check is signed off in a short checklist and any gaps have a named fix.
Cut over DNS and move users
Once validation passes, agree the cutover window with OpenProject, switch DNS or the bookmarked address to the cloud instance, and tell users when to sign in there. Confirm the Community instance is set to read only or kept as a rollback copy for an agreed period. Your owner is the administrator and the network team. You know this step is done when users can sign in on the new address, a post-cutover test passes, and the old instance is secured or retired by agreement.
Handle Jira-sourced data with the Jira Migrator limits in mind
If the team arrived in OpenProject from Jira, note that the OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x only, not Jira Cloud, and is in beta with documentation advising use only in test setups. Do not use it as the production path for live data. Ask OpenProject how Jira-origin data should be carried into the Community install before it reaches the upload service. Your owner is the migration lead. You know this step is done when the source of each data set is documented and any Jira data in production has been checked against the Community install.
What drives the cost of each hosting model
The subscription line is the most visible cost, but it is not the whole bill for either hosting model. On-premises Enterprise is priced per named user per month: Basic at 5.95 euros, 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, according to OpenProject's pricing page. Cloud billing works per user as well, with users added in steps of 5 and reductions applied at the start of the next subscription period, as the Enterprise cloud FAQ describes. A custom domain adds 100 euros per month on cloud, and the one-month billing period is offered only for Cloud Basic at 1 euro extra per user. Check which minimum applies to your headcount before you compare per-user rates, because a 25-user or 100-user floor can change the effective cost per seat.
On-premises costs recur in a different place. You pay for the servers or cloud accounts that run OpenProject, the staff who install, patch, back up and monitor it, and the upgrade work that follows each release. OpenProject's system requirements scale hardware with user count, from 4 cores and 4 GB RAM for up to 200 users upward, and the database must meet the PostgreSQL 16 requirement with its extensions. Those infrastructure and staff costs persist for as long as the platform runs. The one-time items are the initial build, identity integration, any data migration and testing. Cloud shifts the operating tasks for backups, updates and security patches to OpenProject, but it does not remove the need for your own identity configuration, user administration or any integrations you own.
The clearest route to a useful number is a written scope. DeployOpen does not publish prices. Most engagements are fixed-scope, and a quote follows from the agreed scope, deliverables and timelines. Ask for the quote to separate one-time implementation work from recurring retainers for upgrades, testing or support, and to state which assumptions drive each line, such as user count, identity provider, number of integrations and data volume. Confirm with OpenProject the current cloud plan, minimum user counts and any custom domain or billing terms before you sign, because cloud terms and reductions follow its own subscription rules.
Questions buyers ask before choosing cloud or on-premises
Does OpenProject Enterprise cloud keep my data in the EU?
It depends on which cloud shard you choose, so confirm the shard before you sign. According to OpenProject's Enterprise cloud FAQ, the OpenProject.com infrastructure is hosted at AWS in Frankfurt, Germany, and Scaleway becomes the sole data center provider for the EU shard from March 2026. The FAQ also states that the OpenProject.eu infrastructure has no transfer to sub-processors outside the EU. OpenProject says both its AWS and Scaleway data centers are ISO 27001 certified. Ask OpenProject in writing which shard your tenant runs on, which sub-processors touch your data, and where backups are stored. Certification statements describe the data centers, not your own compliance position, which your auditor will still need to assess.
What do I lose if I need direct database access?
Cloud gives you the application, not the database server. OpenProject's Enterprise cloud FAQ points customers who need direct database access to the Enterprise on-premises edition. Check this early if your reporting, data warehouse loads or audit tooling read PostgreSQL tables directly. Also check the on-premises-only features listed on OpenProject's pricing page, including the Corporate plan, ClamAV antivirus scanning and SVN and Git repositories. If any of these are on your requirements list, the on-premises edition is the likely path. Confirm the exact access model with OpenProject before you commit to a deployment model.
How much effort does running OpenProject on my own servers take?
The effort is mostly recurring operations, and it grows with user count and your change process. OpenProject's system requirements list Docker as the recommended installation, with .deb and .rpm packages for 64-bit Linux and Kubernetes with Helm charts for horizontal scaling. Its 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. Your team would also own PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, backups, patching across OpenProject's monthly minor releases, and monitoring. In the cloud edition, OpenProject's Enterprise cloud guide states that it handles regular backups, updates to the latest release and security patches. Ask for a written split of duties before you size your own team.
Can I move a Community install to Enterprise cloud?
Yes, OpenProject provides an upload service for moving data from a Community edition installation to Enterprise cloud. Plan for the data to be checked on both sides before you retire the old instance. Your team needs a current export or backup, a named owner who can confirm users, projects, attachments and custom fields after the move, and a decision on how users re-authenticate if you rely on single sign-on. Single sign-on, LDAP group synchronization and custom branding are Enterprise features, so confirm they are enabled on the cloud plan you buy. Ask OpenProject for the upload procedure, supported data scope and any size limits in writing, since the FAQ does not give them in the facts available here.
Does the 14-day cloud trial delete my instance if I do not upgrade?
Yes, an unupgraded trial instance is blocked and then deleted automatically. OpenProject's pricing page states that the cloud trial lasts 14 days at start.openproject.com and that an instance that is not upgraded after the trial is blocked and deleted automatically. Treat the trial as a test environment only, not a place to load production data. If you plan to move to cloud, complete the upgrade before the trial ends or export your data first. Confirm the exact deletion timing and any retention exceptions with OpenProject support, because the pricing page does not give a longer grace period in the facts available here.
Can DeployOpen run either model under a fixed scope?
DeployOpen can plan and implement either model, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen works inside your own infrastructure, so for a self-hosted install it covers planning, installation, integration, hardening, backup design, upgrades and documentation in your cloud account, data center or air-gapped network. For a cloud decision, DeployOpen can plan identity integration, data mapping, the upload from a Community install and the handover checks. DeployOpen does not publish a price list. A quote follows from the written scope, so list your user count, identity provider, data volumes and any on-premises-only features before you request one. Ongoing support and upgrades are available as retainers.
What does OpenProject cost to run, and what drives the price?
Cost depends on the edition, the number of named users and whether you run the software yourself. OpenProject's pricing page lists the Community edition as free with community support. Enterprise on-premises is priced per named user per month, with 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. The Enterprise cloud FAQ states that a custom domain costs 100 euros per month, that users are added in steps of 5, and that reductions take effect at the start of the next subscription period. Your own run costs also include server, database, backup and staff time, which the cloud edition shifts to OpenProject. Ask for the total monthly figure for your user count, plus any one-time setup cost, in one written quote.
How DeployOpen plans and runs self-hosted OpenProject
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For OpenProject, that means weighing the hosting options with you, then delivering the setup, integrations and evidence in writing. Engagements are fixed-scope, so the written scope sets what gets built.
How we scope
- The written scope names the hosting model: OpenProject cloud, Community or on-premises Enterprise.
- Scope lists the users, data sources, custom domain and identity sign-in options in play.
- Fixed-scope agreements set deliverables and timelines in writing before any build work begins.
How we build
- Installation on your infrastructure, whether cloud accounts, data centers or air-gapped networks, per the agreed design.
- Identity sign-in, LDAP group sync and any integrations are configured and tested against your directory.
- Hardening, backup and restore procedures are built in, then tested before go-live, as the scope states.
How we hand over
- Documentation of the deployed architecture, upgrade path and operating runbooks your team keeps.
- Evidence packs for compliance readiness, prepared for your independent assessor, who issues any report.
- Handover acceptance against the written deliverables, so the next owner knows what they run.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades are planned against OpenProject's release notes, since releases ship roughly monthly.
- Quotes follow from the written scope, so ask for line items covering build, handover and retainer.
