Why teams connect OpenProject Nextcloud integration to their file storage
Teams that plan work in OpenProject often keep their actual documents in Nextcloud, so a person looking for a specification, a signed contract or the latest drawing has to search two tools and guess which one holds the current version. The OpenProject Nextcloud integration addresses this by linking Nextcloud files and folders to work packages, so the people working on a task can open its documents from the task itself. It can also create and manage project folders automatically, so a new project does not start with someone manually building a folder tree in Nextcloud. The integration is part of the OpenProject Community edition. Single sign-on through an OpenID Connect provider for the integration is an Enterprise add-on, so confirm which login method your organization needs before you plan the rollout.
The integration looks simple on a diagram and becomes harder in practice because two systems each hold their own state. OpenProject decides who can see a work package, and Nextcloud decides who can open a file or folder. Those two permission models do not merge by themselves. A person can have edit rights on a work package in OpenProject while having no access to the linked Nextcloud folder, or the reverse. Folder structure is a second source of divergence: if someone renames or moves a project folder in Nextcloud, the link from the work package may point to something that no longer exists. Identities are the third point. Users in OpenProject and Nextcloud are separate accounts unless the login path and account mapping are set up to match them, and accounts that are deactivated in one system can remain active in the other.
Drift between the two systems is the usual failure, and it tends to appear gradually rather than as a single outage. A project is archived in OpenProject but its folder stays open in Nextcloud. A contractor leaves, is removed from OpenProject, and still reaches the documents through a Nextcloud share. Permissions get changed in one tool during an urgent request and never reflected in the other. Because the problem grows quietly, the reader should plan for periodic checks rather than assuming the first configuration will stay correct. Before go-live, decide which system is the authority for each permission type, who owns the folder naming convention, and how removals are handled on both sides.
Which OpenProject and Nextcloud components the integration touches
The OpenProject Nextcloud integration touches configuration on both systems, and five components carry most of the setup work. Some sit entirely in one product, while others need an administrator on each side to agree on values before anything works. Read the owner for each item first so the right people review it before go-live.
Storage configuration
This is the record in OpenProject that points to your Nextcloud server and tells OpenProject how to reach it. It holds the server address, the connection method and the identity OpenProject uses when it calls Nextcloud. Owner: the OpenProject administrator creates it, and the Nextcloud administrator supplies the server address and confirms the service identity. Check that the address resolves and is reachable from the OpenProject host, not only from user browsers, and confirm which Nextcloud versions your OpenProject release supports.
Nextcloud app or OAuth client settings
These settings establish trust between the two systems. Depending on how your link is built, Nextcloud needs an app or an OAuth client registered for OpenProject, with a client ID, a client secret and allowed redirect addresses. Owner: the Nextcloud administrator creates and maintains this registration, and the OpenProject administrator enters the matching values. Redirect addresses must match the public OpenProject URL, including protocol and path, or users will see authorization errors after sign-in. Record who holds the secret and when it expires. Single sign-through OpenID Connect is an OpenProject Enterprise add-on, so confirm your edition first.
Automatically managed project folders
This setting lets OpenProject create and manage a Nextcloud folder for each project. Before you enable it, decide the parent location in Nextcloud, the account that creates the folders, and how storage quotas will apply. Owner: the OpenProject administrator turns the setting on and maps projects to folders, and the Nextcloud administrator approves the parent path, permissions and quota. Ask the vendor how renaming or archiving a project affects the folder path, and test that behavior in a staging instance before users depend on it.
User and group mapping
Mapping connects each OpenProject account to the matching Nextcloud account, so file access resolves to the right person. Project roles in OpenProject do not automatically set file permissions in Nextcloud, so the two permission models must be checked against each other. Owner: both administrators share this item, since identifiers, group names and sharing rules must agree. Group synchronization from LDAP is listed as an OpenProject Enterprise feature, so confirm whether you need it. Test with accounts from each role before rollout.
File link display on work packages
This controls how Nextcloud files and folders appear on OpenProject work packages. Users attach links to documents or folders, and the work package shows them to anyone who can view it. Owner: the OpenProject administrator configures how links are displayed, and the Nextcloud administrator confirms the access rules users will hit when they open a link. Check what a user without Nextcloud access sees on the work package, whether file details load live from Nextcloud, and how the display behaves across your current OpenProject release.
Which authentication and folder model to choose for OpenProject Nextcloud integration
This table compares the three decisions that shape an OpenProject and Nextcloud integration: how users sign in, how project folders are created, and whose permissions the connection uses. Read each row against your identity setup, your Nextcloud folder structure and your review capacity. The main takeaway is that automation and shared accounts reduce admin work but widen what a single identity can reach, so they need tighter review.
| Decision | Option | Fits when | Operational cost |
|---|---|---|---|
| Sign-in method | OAuth connection with user-level tokens | Community edition is enough and each person can connect their own Nextcloud account | Each user connects separately, so onboarding and offboarding must include revoking or checking that user's connection |
| Sign-in method | OpenID Connect single sign-on (Enterprise add-on) | You already run a central identity provider and want one login for both platforms | Requires an Enterprise plan priced per named user, plus identity provider setup and matching user accounts across both systems |
| Project folders | Automatically managed project folders | Teams want a Nextcloud folder created for each project without manual steps | Unused or archived projects leave folders behind, so a clean-up and naming policy is needed to limit clutter |
| Project folders | Manually linked folders | You have an established Nextcloud structure and a small number of projects to link | Moved or renamed folders break links, and someone must maintain each link, which adds admin time and support requests |
| Access identity | One shared service account | You need a single, predictable connection for automation or a small pilot | Actions are attributed to one identity, and that account can reach more files than any single user, so permission drift is harder to spot |
| Access identity | Per-user access | Users must see only the files their own Nextcloud rights allow, and audit trails must name people | Permissions follow each person, so role changes must be reflected in Nextcloud, and users without rights generate support load |
How to set up the OpenProject Nextcloud integration step by step
This sequence connects OpenProject to Nextcloud so work packages can link to project files, with project folders created and permissioned automatically. Each step ends with a check you can run before moving on. Confirm exact menu paths and settings against the current integration documentation before you start.
Confirm edition, versions and authentication method
The platform owner records the OpenProject version and edition, the Nextcloud version, and the hosting address of each system. The Nextcloud integration is available in the Community edition, but single sign-on through an OpenID Connect provider is an Enterprise add-on, so decide now whether users will sign in through OIDC or through separate credentials. Confirm the requirements for both versions in the current integration documentation. Done when the versions, edition, hostnames and chosen authentication method are written down and approved by the people who own each system.
Prepare the Nextcloud app and OAuth client
A Nextcloud administrator installs the OpenProject integration app and creates an OAuth client for OpenProject. The redirect address registered in Nextcloud must match the address OpenProject uses, including the protocol and any path, or the connection will fail. Store the client ID and secret in your secrets manager, not in a ticket. Check that the app is enabled and that the client appears in the Nextcloud security settings with the expected redirect address.
Create the service account and project folder group
Create a dedicated Nextcloud service account that OpenProject uses to create and manage project folders, and give it rights only to the parent folder designated for projects. Create a group that will hold the project folder permissions, so access can be granted by group membership rather than user by user. Confirm the account's permissions against the integration documentation. Check that the service account can log in, can create a test folder under the parent location, and that the group exists with no members yet.
Configure the storage connection in OpenProject
An OpenProject administrator adds Nextcloud as a file storage in the administration area and enters the Nextcloud host, the OAuth client details and the service account settings. Run the connection test that the interface offers before saving the storage as active. If you use OIDC sign-in, confirm the Enterprise license and the identity provider configuration at this point. Done when the connection test succeeds and the storage shows as connected in the administration view.
Enable automatic project folder management
In the storage settings, enable automatic project folder management and set the parent folder, the folder naming pattern and the permission behavior that the documentation describes for your version. Decide whether folders are created when a project is created or when storage is first linked to it, and confirm that choice against the current documentation. Check it by creating a test project in OpenProject. The expected result is a folder in Nextcloud with the agreed name, under the parent folder, with permissions that match the project membership.
Map users between OpenProject and Nextcloud
Each person who needs project files must have a Nextcloud account that corresponds to their OpenProject account, either through OIDC sign-in or through matching user identifiers, depending on your chosen method. Make a list of OpenProject users without a matching Nextcloud account and decide how each will be handled. Group membership on the Nextcloud side should follow project membership in OpenProject. Check with two or three test users that each one can see the folder for projects they belong to and cannot see folders for projects they do not belong to.
Test one project end to end
Use a pilot project with a few members to test the full path. Upload or select a file in the project folder in Nextcloud, link it to a work package in OpenProject, and open it from the work package as a project member. Then repeat the open attempt as a user outside the project to confirm access is denied. Check that the link appears on the work package, the file opens for members, and the outsider receives no access. Record any failures and resolve them before you roll the integration out to other projects.
How to test that OpenProject Nextcloud links and folders work and fail safely
Test the integration by proving two things: authorized people can reach linked files and folders, and everyone else receives a clear access error with no file contents. Before testing, set up at least three accounts: a project member who has a Nextcloud account, a user who is not a member of the project, and a project member who has no Nextcloud access. Run each test step as each account, and write the expected result in a shared test record before the run. Base expectations on the documentation for the OpenProject release you run, and confirm any behavior you cannot find there with your vendor or in a pilot environment. A test that only checks the happy path does not show that the integration fails safely.
Start with link tests. As the member, attach a Nextcloud file to a work package and open it from there. Repeat the link and open steps as the non-member and as the user without Nextcloud access. Both should see an error that states access is unavailable, with no preview, thumbnail or file name shown on the page. Next, rename a project and move it under a different parent, then confirm the managed project folder follows the change and that existing work package links still resolve. Finally, remove the member from the project, allow the change to take effect, and check that the folder is no longer reachable in Nextcloud, both through the Files interface and through a direct link copied earlier. Repeat the removal test with a browser session that was already open, since cached sessions are a common place for leftover access to appear.
Token and client tests check the authentication path. Sign in with a test account through the OAuth or OpenID Connect flow, then let the access token expire or force a refresh. Confirm that OpenProject either refreshes the token or asks the user to sign in again, and that no file contents appear during that failure. Next, revoke the OAuth client in Nextcloud, or change its secret in a test environment, and confirm that new requests fail and that the failures are recorded on both sides. Restore the original configuration afterward and confirm that links work again. Do not assume token lifetimes from another installation. Ask your team to read the token lifetime settings for the OpenProject and Nextcloud versions you deploy, record the values in the test record, and repeat the expiry test after every upgrade.
Logs confirm the result. On the OpenProject side, review the application log and the web server access log for failed attempts from your test accounts, noting the time, user, work package and response. On the Nextcloud side, check the server log in the data directory and any security or audit log your installation has enabled, looking for denied share access and failed OAuth requests. A safe failure shows refusal entries on both sides and no successful file read by a removed or non-member account after access was withdrawn. To confirm fail closed, match each denial to a test step, then check that no successful request from that account appears after its access was removed. Keep log extracts with the test record. If a test fails, reproduce it in a copy of the environment before changing production, so the evidence stays intact.
How the integration changes across Docker, package and Kubernetes installs
The Docker-based install is the method OpenProject recommends, so it is the reference point for this integration. The OpenProject container must reach the Nextcloud server over the network, and browsers must reach OpenProject at one public address. Both systems have to agree on those addresses, and the container's own network setup usually determines whether the connection works.
- Network path: Confirm that the OpenProject container can resolve and reach the Nextcloud hostname, and that Nextcloud can reach the OpenProject host through any reverse proxy in front of each.
- TLS trust: If Nextcloud uses an internal certificate authority, add that CA to the trust store inside the OpenProject container, and check whether an image upgrade resets it.
- Redirect URLs: The callback URL registered in Nextcloud for OAuth or OIDC must match the public OpenProject scheme, host and port exactly.
- Configuration: Host names and integration settings are usually passed through environment variables in your compose file or run configuration. Keep these in version control and confirm the variable names against the documentation for the image tag you run.
Check every setting against the exact image tag in use, because variable names and trust paths can change between releases.
Packaged installs run OpenProject directly on a 64-bit Linux host, with services managed by the operating system. The packages support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15. Network, trust and configuration all live on the host, so changes made to the server apply to every service that runs there.
- Network path: The web server on the host receives requests from users and from Nextcloud, so host firewall rules and any load balancer must allow traffic in both directions on the ports you use.
- TLS trust: Add the internal CA to the operating system trust store, then restart the OpenProject services and confirm that the application accepts the Nextcloud certificate.
- Redirect URLs: The OAuth or OIDC redirect URL in Nextcloud must use the host name that the package is configured to serve. If that host name changes, update Nextcloud at the same time.
- Configuration: Settings are stored in the installer-managed configuration and in web server files on the host. Confirm which files the package reconfiguration step overwrites before you edit them by hand.
Test the trust path with the same connection the application makes, and record the operating system version, because support depends on the listed distributions and versions.
The Helm chart supports horizontal scaling, which means several OpenProject pods run behind an ingress controller and share external services. Traffic from users enters through the ingress, while traffic to Nextcloud leaves through the cluster network. Each replica must follow the same trust and URL settings, so the configuration is shared through chart values, secrets and the ingress definition.
- Network path: Check cluster DNS, egress rules and any network policies that restrict outbound connections from the OpenProject namespace to the Nextcloud endpoint.
- TLS trust: Browser certificates on the ingress and the internal CA used by the application are separate. Mount the internal CA through a secret or config map into every replica.
- Redirect URLs: The external hostname in the ingress and the chart values must match the OAuth or OIDC redirect URL registered in Nextcloud.
- Configuration: Keep chart values and secret references in Git, and avoid storing credentials in plain values files. Confirm the value keys for your chart version in the release documentation.
Ask your platform team to confirm the chart version, ingress class and secret names before you test, because each one affects where the trust and redirect settings must be applied.
Securing the OpenProject Nextcloud connection and its credentials
The OpenProject and Nextcloud link carries authentication, file access and project structure between two systems, so a weak point in either one exposes the other. The cards below cover the trust, credential, permission and logging decisions specific to this connection. General OpenProject hardening is covered in the separate security hardening topic.
TLS and certificate trust
Serve both OpenProject and Nextcloud over HTTPS and confirm that OpenProject validates the Nextcloud certificate chain, including any internal certificate authority. Disabling certificate verification to get the connection working is a common shortcut that leaves OAuth tokens and file metadata open to interception. Check the chain from the OpenProject server itself, since a certificate that works in a browser may not be trusted by the application container or service account environment.
OAuth client secret storage
The OAuth client secret registered in Nextcloud for OpenProject is a credential that grants the integration its trust relationship. Store it in the secrets mechanism your platform team already uses, not in configuration files checked into version control or in shared documentation. Confirm who can read it, when it was last rotated, and what changes in both systems when it is rotated so the rotation is planned rather than discovered during an outage.
Least-privilege service account
Create a dedicated Nextcloud account for the integration rather than reusing an administrator or a personal account. Grant it only the group membership and folder access needed to create and manage project folders for the projects in scope. Review the account's permissions after each change to the integration, and record who approved them, because a broad service account turns a single credential leak into access to unrelated Nextcloud content.
Groups allowed to create managed folders
The integration can create project folders automatically, so decide which Nextcloud groups may trigger that creation and limit the rest. Map each permitted group to the OpenProject projects it serves, and confirm that a user who can create a folder cannot also widen access to it. Review the group list when staff change roles, since group membership in Nextcloud drives who can take actions through the connection.
Shared link review
Files linked to work packages can be shared from Nextcloud through public links, and those links remain valid outside OpenProject's permission model. Audit existing share links on managed project folders, check their expiry and password settings, and disable public links where the project does not need external access. Repeat the review on a schedule, because a link created for a vendor during one phase can stay active long after the phase ends.
Audit logging on both sides
Enable logging in OpenProject for changes to integration settings and for file link events, and enable Nextcloud's audit or activity logging for the service account, folder creation and share changes. Forward both logs to the same place your security team monitors, and confirm retention matches your policy. Without logs from both systems, it is hard to tell whether a folder change came from a user, the integration, or a compromised credential.
What drives effort and cost in an OpenProject Nextcloud integration
This table lists the factors that change how much design, configuration and testing an OpenProject and Nextcloud integration needs, and how each one can be kept down. Read each row as a question to answer before scoping, since the first rollout is usually easiest to control by narrowing the number of projects and users in scope. The main takeaway is that folder standards and group-based access reduce effort more than any single technical setting.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of projects and folders | Each OpenProject project that gets an automatically managed Nextcloud folder needs its folder path, naming and permissions checked, and more projects mean more testing and more exceptions to handle. | Start with a pilot set of projects, and standardize folder templates so most projects follow one structure. |
| Number of users and groups to map | Every user and group needs a matching Nextcloud account or group membership, and mismatched names or duplicate identities create manual cleanup work. | Map access through groups rather than individual users, and clean up the directory before the integration is switched on. |
| Identity source and SSO scope | Login through an OpenID Connect provider for the Nextcloud integration is an Enterprise add-on, so the choice of identity source and whether SSO is in scope changes the edition, the configuration and the test plan. | Confirm the edition and identity provider early, and keep the first rollout on a single authentication method. |
| Existing Nextcloud folder structure and permissions | Folders that already exist, with their own sharing rules, must be reconciled with the folders OpenProject manages, and conflicting permissions take the most time to resolve. | Inventory current folders and sharing before design, and agree which legacy folders stay outside the integration. |
| Number of environments | Test and production environments each need their own OpenProject and Nextcloud configuration, connection settings and sample data, so each added environment repeats part of the setup and verification. | Build the configuration once as documented steps, and promote it between environments rather than configuring each one by hand. |
| Compliance and audit requirements for file access | If file access must be logged, reviewed or evidenced for an assessor, the team needs to show who can reach which folder and prove that permissions were tested, which adds design and evidence work. | Agree the access rules and evidence list in writing before build, and limit the audited scope to the projects that actually hold regulated files. |
| Volume of existing work packages linked to files | Linking many existing work packages to files, or attaching files in bulk, adds reconciliation and checking effort, especially where names or paths changed over time. | Link files for new work only in the first phase, and handle historical links as a separate, smaller task. |
| Support model after go-live | Who answers user questions about missing folders or access errors, and how fast fixes must happen, changes the ongoing effort for internal admins or an external support provider. | Document common access errors and their fixes before go-live, and confirm who owns each type of issue. |
What to monitor, back up and document after the Nextcloud link goes live
The operating team owns the link from the first day it goes live, and the most useful habit is checking it from both ends. The connection has two sides: the OpenProject storage configuration and the Nextcloud app that receives its requests. Monitor the health of each side so a problem on one does not stay hidden. On the OpenProject side, check the storage connection status and any failed authentication or token refresh events in the application logs. On the Nextcloud side, review the application log for failed requests from the OpenProject host and watch for expired or revoked access tokens. Ask your implementer which error messages each version writes, then set alerts on repeated failures so a stale token is found before users report missing files. Record these checks in the runbook so a second operator can run them.
Folder permissions drift as people and projects change, so review them on a schedule and at every offboarding event. When a user leaves the organization or is removed from a project, confirm that removing their OpenProject membership also removes their access to the linked Nextcloud project folder. Test this with a dedicated test account before go-live, then check it again after the first real departure, because sync timing and group-based shares can behave differently from direct shares. For archived projects, decide whether the automatically managed folder stays readable, becomes read-only for the former project team, or moves to an archive location. Write that decision down as a standing rule that applies to every archived project, so the outcome does not depend on who handles the request.
Both products follow their own release cycles, and the link can break when one side moves ahead of the other. OpenProject publishes frequent minor releases: 17.7.0 arrived 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. Set a fixed review point for each release, check the Nextcloud versions that the new OpenProject release supports in its documentation, and confirm that the PostgreSQL version still meets the OpenProject requirement of version 16 or later. Treat every upgrade on either side as a change that needs a re-test of the integration. A short pass should create a link, open a linked file, change a folder permission and remove a test user. Keep the previous package or container image available until that pass succeeds.
Back up the OpenProject and Nextcloud data together, because the link depends on both. Work package links refer to file paths and identifiers stored in the OpenProject database and resolved against the Nextcloud file store. If one system is restored from a different point in time than the other, links can point to files that were moved, renamed or never created. Take backups of the OpenProject PostgreSQL database and attachment storage, and of the Nextcloud database and data directory, in the same backup window. Confirm with your team how that window will be aligned and how it will be verified. Test a restore into a separate environment, open several linked files there, and record the schedule and retention periods in the runbook.
Write down the configuration that a future operator cannot easily infer from the products. Record the authentication model in use, whether OAuth or OpenID Connect, and confirm the edition it requires, since OpenID Connect single sign-on is an Enterprise add-on. Note where client identifiers and secrets are stored and who is responsible for rotating them. List each service account, the Nextcloud permissions it holds and the person who owns its credential. Keep the redirect URLs for every environment, including staging and any recovery site, because a changed hostname can stop authentication from completing. Finally, document the folder naming rules used for automatically managed project folders, including how project names are converted and what happens when a project is renamed. Store this record with the change log so each upgrade and re-test can be traced.
What buyers ask before hiring help for the OpenProject Nextcloud integration
What drives the cost of an OpenProject Nextcloud integration project?
The cost follows the written scope, so the main drivers are how many projects and folder rules are involved, whether OIDC single sign-on is included, and how much testing and documentation you want. A partner is paid for planning, configuration, integration work, testing, handover and any ongoing support you add as a retainer. Your internal costs also count, including admin hours from both teams and the infrastructure for the OpenProject and Nextcloud servers, which recurs. If you choose Enterprise, licensing is a recurring per-user cost, and the OpenProject pricing page lists the current tiers. Ask every quote to separate one-time work from recurring items, name the Nextcloud and OpenProject versions it targets, list the identity provider and the number of projects to automate, and state who performs each test.
How long does the Nextcloud integration take to set up?
Duration depends on the same drivers as cost: the number of projects and folder rules, whether single sign-on is in scope, the current state of your Nextcloud and OpenProject installs, and how many test rounds your team needs. No single timeline fits every environment, so ask for a timeline in the written scope and check it against those drivers. A useful scope lists phases such as an environment check, configuration in a test instance, a pilot project, user acceptance testing and production cutover, with an owner and exit criteria for each. Find out when your change windows fall, because a Nextcloud update or an OpenProject upgrade in the same period can move dates. Ask which items depend on your own decisions, such as group mapping, so delays show up early.
What does the client need to provide for the integration work?
Plan to provide Nextcloud administrator access, decisions about identity, and a test project set before work starts. Admin access lets the engineer configure the integration, check group and folder settings and read logs. Identity decisions cover whether users sign in through OpenID Connect, which provider issues the tokens, which claims map to roles, and whether accounts are created in OpenProject automatically or invited manually. The test project set is a group of representative OpenProject projects with typical folder structures and test users in each role, so you can see how automatic folders behave before production. Name an owner who approves changes and an operator who runs the system after handover, and record these items in the scope with dates so access requests and decisions are not delayed.
Can an internal team set up the OpenProject Nextcloud integration alone?
Yes, if your team has administrator skills on both OpenProject and Nextcloud and enough time to test. The integration relies on standard server administration: configuring the link in Nextcloud, pointing it at your OpenProject server, managing automatic project folders and checking permissions. Your team needs to understand how Nextcloud groups and file permissions interact with OpenProject roles, because mismatches there are where confusion usually appears. A partner adds value where internal teams have less recent experience: reviewing the design before the build, running the test project set, documenting the procedure for your operators, and handling the identity configuration if you also want OIDC single sign-on. Compare the internal effort, including time for testing and later upgrades, with the partner's written scope before you decide.
Does OIDC single sign-on for the Nextcloud integration need an Enterprise license?
Yes. OpenProject lists OpenID Connect single sign-on for the Nextcloud integration as an Enterprise add-on, while the Nextcloud link itself is available in the Community edition. Enterprise on-premises is licensed per named user per month, with tiers and minimums listed on the OpenProject pricing page, so check the current plan and your user count before you budget. Confirm with OpenProject which Enterprise plan includes the add-on for your environment. Without the add-on, confirm how users authenticate to each system and who manages those accounts. In any quote, ask for the license as a separate line item so it is clear what you buy from OpenProject and what you buy from the implementer.
What happens to file links if a project is renamed or a user leaves?
Confirm this in your own test environment before go-live, because the outcome depends on how the integration stores its references and which OpenProject and Nextcloud versions you run. Check the OpenProject Nextcloud integration documentation, and ask your implementer to show you the behavior in the test project set. For a renamed project, check whether file links on work packages stay attached, whether automatically managed folders are renamed or left in place, and whether the folder path changes. For a user who leaves, check whether the account is deactivated or deleted, whether linked files keep their owner, and whether that person's access to project folders is removed. Write these checks into the test set with expected results, run a rename and a deactivation, record the outcome, and agree a procedure for handling orphaned folders.
Which versions and database settings should the integration be tested against?
Test against the exact OpenProject and Nextcloud versions you plan to run, and confirm the installation method first. OpenProject officially supports PostgreSQL 16 or later since OpenProject 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions, so verify them in the target database before integration work begins. Packaged installs support Ubuntu 22.04, Debian 12, CentOS or RHEL 9.x and SUSE Linux Enterprise Server 15, and Docker is the recommended method. OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users and 8 cores and 8 GB for about 500 users, which covers the OpenProject server alone. Check the release notes for your target version, since OpenProject 17.9.0 was released on September 30, 2026 and 17.9.2 on October 15, 2026, and repeat the test set after each upgrade.
How DeployOpen scopes, builds and hands over the Nextcloud integration
DeployOpen treats the OpenProject and Nextcloud connection as a defined piece of work inside your own infrastructure, agreed in writing before build starts. The steps below show what is scoped, how the link is built and tested, what your team receives, and how ongoing support can be arranged.
How we scope
- Written scope lists which Nextcloud folders and files link to which OpenProject work packages and projects.
- Scope records whether project folders are created automatically and which naming and permission rules apply.
- Scope states whether OpenID Connect single sign-on is included, since it is an Enterprise add-on for this integration.
How we build
- Build starts with a test OpenProject and Nextcloud pair in a non-production environment inside your infrastructure.
- We configure the Nextcloud integration, confirm file linking on sample work packages, and check automatic folder creation.
- Authentication is tested end to end with the identity approach agreed in scope, including access for users without rights to a folder.
How we hand over
- Handover includes written configuration documentation covering the OpenProject and Nextcloud settings used and why.
- Your team receives a test record showing which linking, folder and permission cases were checked and their results.
- Operators are shown how to add projects, review folder permissions and troubleshoot a broken file link.
How we support
- Fixed-scope engagements end at the agreed handover unless a separate written scope extends the work.
- Ongoing support, upgrades and testing of the integration after each OpenProject or Nextcloud release can be arranged as a retainer.
- Ask any partner to confirm in writing how release changes to either product will be tested before they reach production.

