Nextcloud and OpenProject integration: what it connects and how it is supported
Project teams often keep their documents in Nextcloud and plan their work in OpenProject, and they want the two linked so that a file lives next to the work it supports. The integration connects Nextcloud files to OpenProject work packages in both directions, creates project folders automatically, and lets users open files from OpenProject. Those three capabilities are the core of what teams ask for, and they are the point to confirm first with your project managers before any build starts.
OpenProject documents this integration in its system admin guide for Nextcloud integrations. The exact mechanism, the app that provides it, and the configuration steps on each side must be confirmed against that guide for the OpenProject and Nextcloud versions you run, because both products release on their own schedules and the integration can change between them. Ask the implementation team to record the versions tested and the settings applied, so that an upgrade on either side starts from a known baseline. DeployOpen implements the integration inside your own infrastructure, so the Nextcloud server, the OpenProject installation, the network path between them, and the credentials they exchange all remain under your control.
OpenProject is licensed under GPL-3.0 and developed by OpenProject GmbH, and its Community edition is free to use. The Community edition includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Do not assume that the Nextcloud integration is included in every edition. Confirm in the current OpenProject pricing and the system admin guide which edition, if any, carries the features you need, because some identity and directory features sit in the Enterprise on-premises tiers. This matters for budget: a Community deployment has no licence fee for the software itself, but the work to install, connect and support it is still a cost you should scope.
The integration depends on the people who will use it. Decide who may create project folders, who may link files to work packages, and who sees a file through OpenProject when they lack access in Nextcloud. Nextcloud sharing permissions and OpenProject project roles are separate systems, so a user who can open a work package may still be unable to open its linked file. Map these roles on paper before configuration, and test them with one pilot project using accounts from each role.
What you need running before you connect Nextcloud and OpenProject
The integration depends on both products running correctly on their own first. These six items cover the platform versions, database, sizing, transport security and service identities that the connection relies on. Confirm each one before you configure the link, because a gap in any of them usually shows up later as a connection error.
Supported Nextcloud major version
Nextcloud publishes a new major version every four months and supports each one for a year, and administrators must upgrade one major version at a time. Nextcloud 35 is the release whose system requirements we reference here. Nextcloud 33 is supported until February 2027 and Nextcloud 34 until June 2027, so pick a version that stays supported through your planned rollout. Confirm the minimum Nextcloud version that the OpenProject integration guide requires before you choose one.
Supported OpenProject install method
Docker is the recommended way to run OpenProject. Packages in .deb and .rpm format are available for 64-bit Linux, with supported packaged installs on Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15. Check that your host operating system appears in the system requirements for the OpenProject release you plan to install. Confirm the minimum OpenProject version that the integration guide requires, and plan upgrades around the method you choose.
PostgreSQL 16 with required extensions
OpenProject officially supports PostgreSQL 16 or later since OpenProject 16.0.0. The database must have the pg_trgm, btree_gist and unaccent extensions available before OpenProject starts. This database belongs to OpenProject and is separate from the Nextcloud database, so its backups and access controls need their own plan. Ask your database administrator who will create the extensions, and confirm the role OpenProject connects with has the privileges its installer needs.
Sizing for your user count
OpenProject's sizing guide suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Count the people who will open work packages and linked files at the same time, then size for growth over the period you plan to support. Nextcloud needs its own capacity, which its system requirements cover separately. Treat the sizing guide as a starting point and confirm it with a load test in your environment.
HTTPS and trusted certificates
Nextcloud and OpenProject exchange requests over HTTPS, so each hostname needs a valid certificate that the other side trusts. Add your internal certificate authority to the trust store used by the Nextcloud PHP runtime and by the OpenProject container or host, and confirm that hostnames match the values you configure. Use temporary workarounds only for testing, and replace them with a correct trust chain before go-live. Check how the integration guide handles certificate validation before you settle on a design.
Service accounts on both sides
Create a dedicated service account in Nextcloud and another in OpenProject, and do not reuse a personal administrator login. Give each account only the rights the integration guide requires, such as access to the folders and projects the integration will touch. Record who owns each account, where its credentials are stored and how they are rotated. Confirm the exact permissions in the guide, since the required scope can change between releases.
How files and work packages reference each other across the two systems
In this integration, the file stays in Nextcloud and the work package stays in OpenProject. The two systems connect through references, so a work package can point to a Nextcloud file and a project can be tied to a Nextcloud folder. Before rollout, decide which system is the working copy for each kind of content. Ownership, sharing links and file version history are managed in Nextcloud. Status, assignees, comments and planning fields are managed in OpenProject. Write this split into your internal guidance so that users know where to look and where to edit.
The first direction is attaching Nextcloud files to work packages. A user selects a file from Nextcloud while working in a work package in OpenProject. Plan for permissions on both sides: the user needs access to the file in Nextcloud and access to the work package in OpenProject. Test this with at least one user who has OpenProject access but no Nextcloud access, and record what that user sees on the work package. The exact display and the behavior for people without file access must be confirmed in the OpenProject Nextcloud integration page for the versions you install. Do not assume the behavior from another tool.
The second direction is creating or opening project folders from OpenProject. Depending on the configuration, a project folder may be created in Nextcloud automatically, or a user may create or open it from OpenProject on demand. Confirm three things in the integration page: which actions trigger folder creation, how folders are named and where they sit in the Nextcloud folder tree, and whether permissions are inherited from OpenProject project membership or must be managed separately in Nextcloud. Naming and inheritance affect who can see sensitive files, so review them with your security and records owners before you open the integration to users.
Document each action as automatic or user-driven in a short runbook. List the action, the system where it happens, whether it is automatic or manual, who holds the rights to perform it and what the user sees afterward. Also plan for changes after the link exists. Renaming, moving or deleting a file or folder in Nextcloud, or changing project membership in OpenProject, may affect existing references. Ask the vendor documentation, and test these cases in a staging environment, to confirm what happens to existing links and whether an administrator needs to repair them.
Configuring the Nextcloud side, then the OpenProject side
This sequence connects Nextcloud and OpenProject in the order the vendor guide expects: Nextcloud first, then OpenProject, then a pilot test in each direction. Each step ends with a check you can run before moving on, so a failed connection surfaces on one pilot project before it reaches the wider portfolio. The result is a working link between project folders and work packages that a small pilot team can use.
Prepare the Nextcloud server and service credentials
The Nextcloud administrator confirms the server is reachable over the HTTPS address OpenProject will call and creates a dedicated service account for the integration. Use a separate account, not a personal login, and give it only the group or folder access the OpenProject guide describes. Generate the app password or token the guide specifies for that account and store it in your secrets manager. This step is done when a test login with the service account succeeds from the network path the OpenProject host uses, and the account can see the parent folder intended for project files.
Confirm the parent folder and sharing settings
Create the top-level folder where OpenProject will place project folders and grant the service account write access to it. Check whether the guide requires any server-side app enablement or sharing setting, and apply it exactly as written. Test write access by having the service account create and then delete a scratch folder through the Nextcloud web interface or a WebDAV client. This step is done when the scratch folder is created and removed without error, and the parent folder shows the service account with write access.
Enable the Nextcloud integration in OpenProject
An OpenProject administrator opens the Nextcloud integration settings in the administration area, enters the server address, and selects the authentication method the OpenProject guide names for this setup. Enter the service account credentials using the field labels the guide uses, and save. Do not reuse an administrator's personal password. This step is done when OpenProject reports the connection as established and the connection test can reach the parent folder. If the status shows an error, check the URL scheme, certificate trust between the two hosts, and the service account's permissions before retrying.
Test folder creation on a pilot project
Create a pilot project in OpenProject with a small set of members and enable the Nextcloud file storage on that project, following the steps in the guide. Save the project and the storage link, then allow OpenProject to create the project folder. Open the Nextcloud parent folder and look for the new project folder using the naming the guide produces. This step is done when the folder appears at the expected path, the pilot members can see it in Nextcloud, and no folder is created for an unrelated project.
Attach a file to a work package and open it
On a work package in the pilot project, attach a file from the linked Nextcloud folder, or upload one through the file link the guide describes. Confirm the file appears on the work package, then select it to open it. This step is done when the file opens in Nextcloud in the browser under the signed-in user's own session, and the file access follows that user's permissions rather than the service account's. Then sign in as a pilot user who has no access to the folder and confirm that the link is refused.
Confirm the reverse direction for pilot users
Repeat the check from the Nextcloud side, following the reverse direction the OpenProject guide documents. Confirm which behaviors apply in your version, such as whether the reverse path creates links, shows work package references or only enables file browsing. Have a pilot user make a change in one system and verify it in the other. This step is done when the change appears in the second system as the guide states, and the team records which behaviors are confirmed, so any rollout beyond the pilot uses only the documented scope.
How projects, folders, users and permissions map between the systems
This table compares each core OpenProject object with its counterpart in Nextcloud, who creates it, and which system enforces access. Read the mapping column first, then check the enforcement column before you finalize permission design. The main takeaway is that identity should come from one directory or SSO source, while role-to-share mapping must be confirmed against the integration guide before anyone relies on it.
| Object | Mapping and direction | Who creates it | Identity and enforcement |
|---|---|---|---|
| Project to folder | OpenProject project to Nextcloud project folder, one folder per project (confirm automatic creation) | Integration on project setup, or a project admin (confirm) | OpenProject enforces project access; Nextcloud enforces folder access separately |
| Work package to files | Work package links to Nextcloud files, flowing from OpenProject to Nextcloud (confirm direction) | Project member in OpenProject | OpenProject controls work package visibility; Nextcloud controls file access |
| Files and attachments | Nextcloud files opened from OpenProject work packages (confirm whether copies are made) | Nextcloud user who uploads or edits the file | Nextcloud file permissions apply when the file is opened; confirm the check at click time |
| Users | Matched across systems by a shared identifier such as username or email (confirm attribute) | Directory or SSO provisioning, usually on first login | Directory or SSO is the source of truth; both apps must resolve the same account |
| Groups | Directory groups synced into Nextcloud through the LDAP app; OpenProject group sync is an Enterprise feature (confirm mapping) | Directory administrator | Membership is decided in the directory; each application applies its own rights |
| Project members and roles | OpenProject roles to Nextcloud share permissions: one-to-one mapping not confirmed, item to confirm | Project admin in OpenProject; Nextcloud admin for share rights | OpenProject enforces roles; Nextcloud enforces share permissions set in its own interface |
| Shares | Nextcloud shares are created in Nextcloud, and the integration links to them (confirm) | Nextcloud user with sharing rights | Nextcloud enforces share expiry and access; OpenProject shows the link only |
| Offboarding | Disabling a user in the directory should remove access in both systems (confirm sync timing) | Directory administrator | Test removal in each system separately, and assign an owner for orphaned folders |
Identity and access: keeping one login and one permission model
Decide where identity and group membership are defined before building anything else. Nextcloud and OpenProject each sign users in and authorize them on their own, so the integration only stays consistent when both read from the same directory or identity provider. On the Nextcloud side, the documented options are the LDAP app, which lets LDAP and Active Directory users appear in Nextcloud and log in with their directory credentials, and the OpenID Connect and SAML user authentication backends. On the OpenProject side, single sign-on through SAML, OIDC, CAS, Kerberos or Okta and LDAP group synchronization are listed among its Enterprise features. Write down which protocol each system will use, which directory holds the user record, and which system creates and removes accounts. Those three answers drive most of the later design work.
Two sources of truth for group membership is the main risk. If Nextcloud groups are maintained by hand while OpenProject roles come from a directory, the two lists drift apart as people join, move and leave. The gap matters most for project folders. A folder created for a project can stay visible in Nextcloud to someone whose OpenProject membership has already been removed, if the Nextcloud share is tied to a group that nothing updates when the project role changes. The same gap appears when a person changes role inside a project: the new role may apply in OpenProject while the old folder access still applies in Nextcloud. Treat every group that gates file access as a derived value, and name the system that owns it.
Confirm one fact before fixing the design: whether the file link between OpenProject and Nextcloud requires OpenProject Enterprise features. The information available for this page does not settle that question. It matters because single sign-on and LDAP group synchronization are Enterprise features, and the answer changes which identity model is available on each side. Ask OpenProject in writing which edition the file link needs, whether it reads group membership or work package permissions at the moment a file is opened, and whether it removes access when a membership ends. Also ask which Nextcloud version and app setup the link has been tested against. Record the answers next to the identity decision so the licensing and build plan rest on confirmed facts.
Test offboarding and role changes before go-live. Pick a test user in the directory, add that user to an OpenProject project and to a linked Nextcloud folder, then confirm that both systems grant access. Remove the user from the project in OpenProject, disable the account in the directory, and check three things: whether the Nextcloud account can still sign in, whether the project folder still appears in the user's file list, and whether an existing share link or sync client still reaches the files. Repeat with a role change, moving the user from a write role to a read-only role, and confirm that uploads are refused. Record how long each change takes to reach each system, and repeat the test after every Nextcloud or OpenProject upgrade. A failed case is a design finding to resolve before launch.
Securing the OpenProject and Nextcloud connection
Connecting Nextcloud and OpenProject widens what a single compromised account or misconfigured folder can reach, because files and project data now meet. The cards below cover the decisions the security team should settle before go-live. For each one, confirm the setting in the Nextcloud and OpenProject documentation for the versions you run.
Certificates both hosts trust
Nextcloud calls OpenProject, and OpenProject calls Nextcloud, so both hosts need HTTPS with certificates the other side trusts. Decide who issues the certificates, whether an internal certificate authority is used, and how the chain is installed on each application server and any reverse proxy. Confirm which certificate settings each product reads, and test that the connection validates before any service account is created. Plan renewal so an expired certificate cannot silently break file links.
Least-privilege Nextcloud service account
The integration needs a Nextcloud account that can create folders and read the files linked to work packages, and nothing more. Decide which groups it belongs to, which folders it can reach, and whether it can share files outside the organization. Keep it separate from any administrator account, and document its scope so reviewers can compare it with what the integration actually needs. Confirm the permission and sharing settings in the Nextcloud administration manual before granting access.
Integration credential storage
The link between the two products relies on credentials, such as an application secret or token, that must not sit in configuration files readable by everyone on the server. Decide where they are stored, such as a secrets manager or root-only environment files, who can read them, and how they are rotated after staff changes. Record each credential's owner and purpose. Confirm which settings in each product accept secrets from environment variables, and how a changed secret takes effect without a full restart.
Who can create project folders
Automatic project folder creation means any user who can trigger it can also create directories in Nextcloud. Decide which OpenProject roles can create or link project folders, whether folder names follow a fixed convention, and which Nextcloud parent location receives them. Restrict the parent folder's permissions so a new project folder cannot be placed where unrelated teams can read it. Test with a user who holds a limited role before rollout, and confirm the permission model in the OpenProject Nextcloud integration guide.
Audit logging on both systems
Each product records different events, so one incident may need evidence from both. Decide where Nextcloud and OpenProject logs are stored, how long they are kept, and who reviews them. Confirm which file access and activity events Nextcloud logs, and which OpenProject journal or audit entries cover work package changes and folder links. Forward logs to a central store, check that actions taken by the service account are identifiable, and test that one sample file access produces an entry on both sides.
Supported releases and upgrade order
Both products need to stay on releases that still receive security fixes. Nextcloud publishes a new major version every four months and supports each for one year. Nextcloud 33 is supported until February 2027, 34 until June 2027 and 35 until September 2027. Upgrade Nextcloud one major version at a time, back up before every upgrade, and disable third-party apps until they are confirmed compatible. Follow OpenProject's release notes in the same cycle, and retest the connection after each change on either side.
Testing the link before users rely on it
Run the integration test plan on a staging copy before anyone is told that project files live in Nextcloud. Write the plan as numbered cases, each with a named tester, a fixed starting state and an expected result, so that a failed case can be reproduced by someone other than the person who ran it. Cover both directions the integration is meant to work in: a project created in OpenProject should produce its folder in Nextcloud, and a file attached in Nextcloud should be reachable from its work package. Keep the staging copy on the same major versions, database engine and sizing tier as production. The OpenProject sizing guide scales requirements with user count, and an undersized test server can hide slow file operations that users will notice on day one.
Start with the access cases, because they carry the most risk. Create a test project in OpenProject and confirm that the matching folder appears in Nextcloud with the expected membership. Attach a file to a work package and open it from OpenProject, confirming that it opens in Nextcloud for the tester. Then sign in as a user with no membership in the test project and try to open the same file by its direct Nextcloud path and through any share link. Every attempt must fail. Repeat the check for a removed member: remove the user from the project in OpenProject, confirm how long the change takes to reach Nextcloud from the product documentation or your own timing, and verify that access is gone after that interval. Record the removal time and the enforcement time, because both will be asked about later.
Next, test the file behavior that users notice first. Upload a large file, sized above what your ordinary users attach, and confirm that it attaches to a work package and opens without timeouts in your reverse proxy or PHP limits. Record the file size and the outcome. Rename the file in Nextcloud and confirm that the work package link still resolves to the file. Then repeat the full case list after an upgrade of either product. Nextcloud does not allow skipping major releases, requires a backup before every upgrade and asks administrators to disable third-party apps until they are confirmed compatible, so the upgrade run should follow that order. The 2026 OpenProject release notes list 17.7.0, 17.8.0 and 17.9.0 in consecutive months, so plan to retest after minor OpenProject upgrades as well as major ones.
For each case, keep four items: the test ID and starting state, the account used, the observed result with a timestamp, and the evidence itself. Evidence should be a screenshot or exported log line that shows the Nextcloud path, the OpenProject work package identifier and the outcome. Confirm which audit or access logs each product writes and how long they are retained, because a denied access case only proves something if the denial is recorded. Sign-off should come from two roles: the platform owner who operates the stack and the business owner of the project data. The security or compliance reviewer should countersign the access cases. Store the signed plan with the change record, and rerun it before any upgrade reaches production.
Why project folders or file links fail, and how to fix them
This table lists the failures teams most often meet when linking Nextcloud files to OpenProject work packages, with the likely cause and the first fix to check. Work through the rows in order, because a certificate or version problem can produce symptoms that look like permission or sync faults. On both hosts, read the Nextcloud and OpenProject logs for the same time window before changing any setting.
| Failure | Likely cause | First fix to check |
|---|---|---|
| Certificate trust errors between hosts | One host does not trust the certificate chain of the other, often a private CA or self-signed certificate | Install the internal CA on both servers and confirm the integration uses the matching HTTPS host name |
| Mismatched or unsupported versions | Nextcloud or OpenProject release falls outside the combination in the integration guide, or the OS or database is unsupported | Compare both release notes and system requirements, then align versions before debugging settings |
| Missing PostgreSQL extensions in OpenProject | The pg_trgm, btree_gist or unaccent extension is not installed, or PostgreSQL is older than version 16 | Install the three extensions in the OpenProject database and confirm the PostgreSQL version meets the requirement |
| Service account lacks rights in Nextcloud | The account used for the connection cannot create folders, share files or read the target group folder | Grant the needed access on the target folder, then retest with one test project before wider rollout |
| Users missing from the directory on one side | An account exists on one host only, because the directory or identity source or its sync scope differs | Confirm both sides read the same directory and sync scope, then compare the user's attributes |
| Folder permissions out of sync with project membership | Membership changed in OpenProject without a matching change to folder access in Nextcloud | Re-run the membership sync or align folder groups with project roles, then test access for a removed member |
| Links break after host name or path change | Stored file and project links still point to the old host name or path | Update the configured URLs on both sides, back up first, then re-save or regenerate affected links |
What does a Nextcloud and OpenProject integration cost and take?
What drives the cost of a Nextcloud and OpenProject integration?
Scope, the number of projects, identity design, hosting and testing drive most of the cost, and any subscriptions you choose add to it. A pilot with one project and one identity source takes far less design and verification work than an organization-wide rollout where every project needs its own folder structure, permission mapping and user testing (illustrative). Identity design is often the largest variable. Whether both systems read users from one LDAP or Active Directory directory, use OpenID Connect or SAML, or keep local accounts changes the build and the test plan. Hosting determines how many servers, certificates and backup targets you maintain. Testing grows with the number of roles and project types. Ask any partner for a quote built from a written scope that lists these items separately, marks which are one-time and which recur, and states who provides each input.
Do we need OpenProject Enterprise for the Nextcloud integration?
It depends on the features you choose, so confirm the requirement in the OpenProject integration guide for your version before you buy. OpenProject lists single sign-on (SAML, OIDC, CAS, Kerberos and Okta), LDAP group synchronization and custom branding as Enterprise features. The Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards, with community support. Per OpenProject's pricing page, on-premises Enterprise is priced per named user per month: Basic at 5.95 euros and Professional at 10.95 euros with a 25-user minimum, and Premium at 15.95 euros with a 100-user minimum. Corporate is quoted on request for 250 or more users. If you also buy Nextcloud Enterprise, Nextcloud's pricing page lists Standard from 71.29 euros per user per year with a 100-user minimum. These are list prices, so check current terms with each vendor.
Can our own team set up Nextcloud and OpenProject integration without a partner?
Yes, if your team can run both systems and follow the vendor guide. Your staff need to operate Nextcloud, including its PHP runtime, a supported database (Nextcloud 35 recommends PostgreSQL 18 or MariaDB 11.8) and a web server. They also need to run OpenProject, whether through Docker, a packaged install or Kubernetes, with PostgreSQL 16 or later and the pg_trgm, btree_gist and unaccent extensions. Someone must configure identity, reverse proxies, TLS and backups on both sides and test each change before production. Identity and permission mapping are the parts where a test environment matters most. A partner can take over any part of this work, or review your own design, under a written scope.
How long does a Nextcloud and OpenProject integration take?
It depends on the scope and the environment, so ask for a written scope before any date is agreed. The main variables are the number of OpenProject projects that get linked folders, how many groups and roles need permission mapping, which identity source both systems use, whether the servers already exist, and how many test cycles your project owners need. Those factors often move the schedule more than the file linking itself. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so the written scope is where the timeline is set. Ask the partner to list the assumptions behind each duration, including which people must be available and when.
What do we need to provide for the integration project?
The work needs decisions and people from your side as much as servers. Identity staff must supply the directory or the OpenID Connect or SAML details, the group structure and the rules for who may create projects. You need a test environment with representative sample data, administrator access to both systems, DNS names and TLS certificates. Project owners test the behavior that matters to them: automatic folder creation, opening files from work packages, and permissions for external participants. Someone must approve folder naming and retention rules before go-live, and someone must own the change window. Ask any partner to name these responsibilities in the written scope, with an owner for each and a point in the plan by which each input is due.
What recurring work follows go-live for Nextcloud and OpenProject?
Upgrades, certificates, monitoring and backup retention continue after go-live, and each needs an owner. Nextcloud publishes a new major version every four months and supports each one for one year through monthly maintenance releases. Nextcloud does not allow skipping major releases, so you upgrade one major version at a time, back up before each upgrade and disable third-party apps until they are confirmed compatible. OpenProject ships releases on its own schedule, and its database requirements change over time, so retest the integration after upgrades on either side. Certificates need renewal, monitoring should cover both services and the connection between them, and backup retention rules need periodic review. Any Enterprise subscriptions you choose also renew on their own terms, so list them as recurring items in the quote.
How does DeployOpen price a Nextcloud and OpenProject integration?
DeployOpen does not publish a price list, and a quote follows from the written scope. The cost components are DeployOpen's planning, implementation, testing and documentation work, plus any subscriptions you choose, which you buy from OpenProject or Nextcloud. The scope should separate one-time work, such as design, build, testing and cutover, from recurring items, such as upgrades, monitoring, support retainers and subscriptions. Ongoing support, upgrades and continuous testing are available as retainers. When you request a quote, ask for the scope items, the assumptions behind them, the responsibilities that fall to your team, which parts are fixed, and the recurring costs listed on their own line. Vendor list prices give you a starting point for your own budget, and they do not determine DeployOpen's fees.
How DeployOpen scopes, delivers and supports the integration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For the Nextcloud and OpenProject link, we agree the scope in writing first, then build and test both sides, and hand the setup over with documentation your team can run.
How we scope
- Inventory the Nextcloud and OpenProject versions, hosting model and user directory before any configuration starts.
- Agree in writing which folder structures, work package links and file-opening behaviors are in scope.
- Confirm which OpenProject edition covers the single sign-on and LDAP group features your design needs.
How we build
- Configure the Nextcloud app and OpenProject connection on a staging environment that mirrors production.
- Test both link directions: automatic project folder creation and opening files from work packages.
- Check permissions so Nextcloud sharing rights and OpenProject roles match your access model.
How we hand over
- Document setup steps for each side, including app settings, network paths and service accounts.
- Record the tests run, the known limits of the link and the settings that must stay in sync during upgrades.
- Walk your administrators through the runbook so they can operate the integration without us.
How we support
- Agree whether upgrade checks for each platform are covered by a fixed-scope change or an ongoing retainer.
- Plan upgrades one major version at a time, with backups taken before each change.
- Retest the integration after each platform upgrade before your users rely on the new version.
