OpenProject Nextcloud integration

Linking OpenProject work packages to Nextcloud files and folders takes a deliberate choice of authentication model and folder ownership. This page covers the decisions, build sequence, effort drivers and checks for a self-hosted setup.

On this page

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.

DecisionOptionFits whenOperational cost
Sign-in methodOAuth connection with user-level tokensCommunity edition is enough and each person can connect their own Nextcloud accountEach user connects separately, so onboarding and offboarding must include revoking or checking that user's connection
Sign-in methodOpenID Connect single sign-on (Enterprise add-on)You already run a central identity provider and want one login for both platformsRequires an Enterprise plan priced per named user, plus identity provider setup and matching user accounts across both systems
Project foldersAutomatically managed project foldersTeams want a Nextcloud folder created for each project without manual stepsUnused or archived projects leave folders behind, so a clean-up and naming policy is needed to limit clutter
Project foldersManually linked foldersYou have an established Nextcloud structure and a small number of projects to linkMoved or renamed folders break links, and someone must maintain each link, which adds admin time and support requests
Access identityOne shared service accountYou need a single, predictable connection for automation or a small pilotActions are attributed to one identity, and that account can reach more files than any single user, so permission drift is harder to spot
Access identityPer-user accessUsers must see only the files their own Nextcloud rights allow, and audit trails must name peoplePermissions 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

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.

DriverWhy it changes effort or costHow to keep it down
Number of projects and foldersEach 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 mapEvery 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 scopeLogin 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 permissionsFolders 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 environmentsTest 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 accessIf 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 filesLinking 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-liveWho 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.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.