Moodle and Nextcloud file integration for institutions that keep files in their own cloud
The supported method is the core Nextcloud repository plugin in Moodle, configured through Moodle's OAuth 2 services, and no third-party connector is needed. This section is for an institution that runs Moodle and keeps course files in a self-hosted Nextcloud, and that wants teachers and students to pick and share those files from inside Moodle. It is written for the team deciding whether to build this integration in-house or hire an implementation partner. Both systems stay in infrastructure the client controls, so the integration design has to respect that boundary from the start.
In plain terms, the integration lets a user open a Nextcloud repository from a Moodle file picker, browse the files they are allowed to see, and attach or link them to course content. It does not replace Moodle's own file storage, and it does not turn Nextcloud into the system of record for course content. Confirm with your Moodle version's documentation exactly which file operations the picker supports, such as whether a file is copied into Moodle or referenced in place, because that choice changes backup scope, storage growth and what happens when a source file is moved or deleted in Nextcloud.
The decisions that carry the most weight sit outside the plugin settings. First, decide which identity source Nextcloud uses for its users. If accounts come from an LDAP or Active Directory directory, the Nextcloud LDAP app lets those users log in with directory credentials, and the same identities must line up with Moodle accounts. Second, decide who owns the OAuth 2 client registration on each side, who rotates its secret and where it is stored. Third, decide which Moodle roles can see the Nextcloud repository, and which Nextcloud folders those users can reach. Write these answers down before any configuration begins.
Both platforms change on their own schedules, and that is the main operational risk. Moodle ships major releases every six months and point releases every two months, while Nextcloud publishes a new major version every four months, supports each for one year, and does not allow skipping major releases during upgrades. Each upgrade on either side can affect the OAuth 2 connection, the repository plugin or the file paths it depends on. Plan a test of the Moodle to Nextcloud connection, with test accounts and a sample course, as a standing step in every upgrade on either side.
When you ask a partner for a quote, the written scope should name the OAuth 2 client setup on both sides, the identity mapping, the role and folder permission matrix, the test plan, the handover documentation and the upgrade test that will follow each release. Ask whether the plugin version and both platform versions are confirmed in the proposal. If your team builds it in-house, check that the same people can administer Moodle, Nextcloud and the directory that feeds them, because a gap in any one of those three areas usually shows up as a login or permission problem for teachers and students.
What must be in place before connecting Moodle to Nextcloud
Both platforms must run supported releases, be served over HTTPS with certificates each side trusts, and have accounts and a network path in place before the repository plugin is configured. The cards below set out what to check on each side, in the order most teams work through them.
Moodle release still in support
Choose a Moodle release with security support for the whole planned life of the integration. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027. Moodle 5.3, released on 5 October 2026, is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. Confirm the exact repository plugin version bundled with your Moodle release in your own environment.
Moodle runtime and document root
Moodle 5.1 requires 64-bit PHP 8.2 or later, and Moodle 5.3 requires 64-bit PHP 8.3 or later, with a supported database such as PostgreSQL 17 for 5.3. From Moodle 5.1, the web server document root must point to the new /public directory inside the Moodle code. If the root points to the main folder, the site may show directory listings or errors.
Nextcloud release and runtime
Nextcloud 35 (Hub 26 Summer) was released on 16 September 2026 and reaches end of life in September 2027. Nextcloud 34 is supported until June 2027 and Nextcloud 33 until February 2027, so choose a major version with enough support window left for your rollout. Nextcloud 35 recommends PHP 8.5, plus MariaDB 11.8 or PostgreSQL 18, and Nextcloud does not allow skipping major releases during upgrades.
HTTPS with certificates both sides trust
Serve both Moodle and Nextcloud over HTTPS, and make sure each server trusts the certificate authority that signed the other's certificate. If your organization uses an internal certificate authority, add its root and intermediate certificates to the trust store used by PHP on the Moodle server, then test the connection from Moodle to Nextcloud. Confirm the trust store path and certificate chain with your operating system and PHP setup.
Administrator accounts with named owners
Decide which Nextcloud administrator and which Moodle administrator will set up and own the integration. The OAuth 2 configuration needs a Nextcloud administrator to create the client that Moodle uses, and a Moodle administrator to configure the service. Use dedicated accounts with a documented owner so access can be reviewed and removed when staff change roles. Confirm the exact steps for your Nextcloud version.
Network path between the servers
The Moodle server must reach Nextcloud over the network, usually through any reverse proxy or load balancer in front of it. Nextcloud also needs to reach the Moodle site for the OAuth 2 return flow, so confirm that the Moodle callback address resolves and is routable from Nextcloud. Review firewall rules, DNS names and any outbound proxy settings on the Moodle server, since a missing route often appears only as a failed connection test.
How Moodle reaches Nextcloud files through OAuth 2
The key idea is that two separate things happen in this integration: Moodle signs a user in, and Moodle reads files from Nextcloud. They use the same protocol family but serve different purposes, and confusing them is the most common source of misconfiguration. In the core setup, Nextcloud is registered as an OAuth 2 client inside Nextcloud itself. Moodle then holds that client's ID and secret through its OAuth 2 services configuration, which is where the two systems are told how to trust each other. Before you touch either side, confirm the exact registration steps, redirect URI requirements and service configuration screens in the Nextcloud repository plugin documentation for your Moodle version, because these screens have changed across releases.
Logging a user into Moodle and granting Moodle access to their files are not the same action. Authentication answers the question of who the person is. The repository plugin then needs an access token so that it can call Nextcloud on that person's behalf when they open the file picker in a course, an assignment or a forum post. Your Moodle authentication method (manual accounts, LDAP, SAML 2.0 through a plugin, or another method) does not change this flow. A teacher can sign in to Moodle through one identity provider and still be connected to Nextcloud through the OAuth 2 link, provided their accounts line up. Plan the two concerns separately so that a failure in one does not get mistaken for a failure in the other.
When a user opens the file picker, the repository plugin lists and retrieves files using the access granted for that user. This means the Nextcloud identity behind each Moodle account decides which files appear. Nextcloud's sharing rules, folder permissions, group membership and any external storage mounts apply exactly as they do when the user opens Nextcloud directly. Moodle does not create a separate permission model for these files. Consequently, a student who should see only their own folder will see only that folder, and a teacher who has access to a shared course folder in Nextcloud will see that folder in Moodle. Before rollout, test with several representative accounts, including one from each role, and compare what appears in Moodle with what appears in Nextcloud.
There are practical decisions that follow from this design. First, decide how Moodle accounts are matched to Nextcloud accounts. If usernames or email addresses differ between the two systems, the link will not resolve to the right person, and a user may see no files or the wrong ones. Second, decide who administers the OAuth 2 client registration and who owns its secret, and record where the secret is stored and how it is rotated. Third, plan for expired or revoked tokens, since users who have not signed in recently or whose Nextcloud accounts have been disabled will lose access to files until the link is re-established. Ask your implementation partner or your own team to document each of these decisions before go-live.
Some points need to be confirmed rather than assumed. Check the minimum Moodle version and the Nextcloud version the repository plugin supports, and check whether the plugin requires a specific OAuth 2 scope or redirect configuration. Confirm how the plugin handles users who have never connected their Nextcloud account, and what message they see in the file picker. Also confirm whether shared files are returned as copies or as links when a user inserts them into course content, because that choice affects who can later edit or revoke access. Keep your test results alongside the version numbers you tested, so that a later Moodle or Nextcloud upgrade can be checked against a known baseline.
Configuring the Nextcloud repository in Moodle, step by step
This sequence connects a self-hosted Nextcloud to Moodle so that teachers and students can pick files from Nextcloud and attach them to course activities. Each step closes with an observable check, so a fault shows up at the step that caused it. Run the sequence on a test copy of both systems before changing production, and record the versions and redirect address you used.
Confirm versions and HTTPS on both systems
The Moodle administrator and the Nextcloud administrator each check their own system. Confirm that the Moodle release is in its support window and that the server meets its PHP and database requirements. For Moodle 5.1 and later, confirm that the web server document root points to the public directory. Confirm that the Nextcloud release is supported and that its recommended PHP, database and web server versions are in place. Both sites must load over HTTPS with a valid certificate. Done when both sites load without certificate warnings and the administration overview shows no outstanding version or security warnings.
Get the redirect address from Moodle
In Moodle, open the OAuth 2 services page under site administration and start a new service using the Nextcloud type. Moodle displays the redirect address that Nextcloud must accept for the token exchange. Copy it exactly, including the scheme and host, because a single character difference will cause the exchange to fail later. Keep this page open, since you will return to it in the next steps. Done when you have the redirect address written down and it begins with your Moodle site's HTTPS address. Confirm the exact path with the Moodle page in your version rather than copying it from documentation.
Create the OAuth 2 client in Nextcloud
In Nextcloud, open the administration settings and find the OAuth 2.0 client section under security. Add a client, name it clearly for Moodle, and paste the redirect address you copied from Moodle. Nextcloud then generates a client identifier and a client secret. Store the secret in your secrets vault or a restricted document, since the Moodle service needs it in the next step and anyone holding it can request tokens. Done when the client appears in the list with its identifier visible and the redirect address matches the one Moodle shows.
Create the OAuth 2 service in Moodle
Return to the Moodle OAuth 2 service form and enter the client identifier and client secret from Nextcloud. Set the service endpoints using the addresses of your Nextcloud instance, following the form labels for the Nextcloud type. Save the service and confirm it is enabled. Moodle then shows a connection status for the service. Done when saving completes without errors and the service is listed as enabled. To verify the token exchange, sign in to Nextcloud from Moodle with an administrator account and confirm that Nextcloud returns you to Moodle with the connection marked as established.
Enable and configure the Nextcloud repository
In Moodle, open the repository management page and enable the Nextcloud repository plugin. Then add a Nextcloud repository instance and set its options, including the display name, the Nextcloud server address, the OAuth 2 service you created, and any folder or file-type restrictions your policy requires. Save the instance and check that it appears in the list of enabled repositories. Done when the instance is saved and visible in the repository list, and an administrator account can open the file picker in a course and see the Nextcloud entry.
Decide which users and roles see the repository
Decide which roles may use the Nextcloud repository and in which contexts, such as the course level or only specific activities. Moodle controls repository visibility through repository capabilities and role assignments, so review the capabilities for the teacher and student roles and the context at which each applies. Record the decision as a short matrix that names each role and whether it can browse, upload or link Nextcloud files. Done when the matrix is approved by the people who own the policy and a test account in each role confirms the expected visibility in the file picker.
Test with teacher and student accounts
Sign in with a teacher test account, open a course activity that accepts files, and open the file picker. Complete the Nextcloud sign-in if prompted, then confirm the folder tree loads and attach a file from Nextcloud. Save the activity and check that the file appears as a link. Repeat with a student test account, confirming that the student can browse the permitted folders, attach a file to an assignment submission, and cannot see folders outside the matrix. Done when both accounts attach a file to a course activity and the results match the matrix. Record any failure with the step where it occurred.
Which identities, files and permissions map between Moodle and Nextcloud
This table lists each identity, file and permission element the Nextcloud repository relies on, what it must match or allow, and what to confirm in your environment. Read it before the OAuth 2 service and repository settings are finalized, because mismatches here usually surface as missing files or failed logins after rollout.
| Element | What the integration depends on | What to confirm before rollout |
|---|---|---|
| Username | Moodle links to a Nextcloud account through OAuth 2, so the username does not have to match by default. Confirm whether your setup relies on matching usernames. | Whether usernames are identical in both systems, and what happens for accounts with different or renamed usernames. |
| Email address | Email is used for account identification and notifications in Moodle. Confirm whether Nextcloud matches on email during OAuth 2 linking or only uses it for display. | Whether each Moodle email matches a Nextcloud email, and who owns the process for fixing duplicates. |
| Authentication method | Moodle sign-in (manual, LDAP, OAuth 2, SAML2 or other) is separate from the OAuth 2 link to Nextcloud. Users may need to authorize Nextcloud even when their Moodle login is already federated. | Which Moodle auth plugin each user group uses, and whether a shared identity provider signs users into both systems. |
| Account missing or mismatched | If a Moodle user has no linked or matching Nextcloud account, the repository cannot list that user's files. The user sees an authorization prompt or an empty repository, depending on configuration. | Expected behavior for unlinked users in your Moodle version, and the support message students and teachers will receive. |
| File scope | The repository exposes files that the linked Nextcloud account can access, including its own files and any shared with it. Group folders and shared spaces depend on Nextcloud configuration. | Which folders are visible through the repository, and whether group folders or external storage appear for your users. |
| Sharing permissions | Files selected from Nextcloud carry Nextcloud sharing permissions (read, edit, share, delete). Confirm whether Moodle stores a reference to the file or a copy, because that decides whether later permission changes take effect. | Whether referenced files follow later Nextcloud permission changes, and how revoked access is handled in existing courses. |
| Moodle roles and capabilities | Visibility of the repository is controlled by Moodle capabilities and by the repository instance settings. Teachers and students may need different access, set through role assignments in the course or system context. | The exact repository capability names in your Moodle version, and which roles see the repository in course and user contexts. |
| Nextcloud server version and OAuth 2 settings | The OAuth 2 service in Moodle must point to the Nextcloud instance and its OAuth 2 app configuration. Mismatched URLs or redirect settings block token exchange. | The Nextcloud version you run, the OAuth 2 client settings, and the Moodle and Nextcloud URLs used by users and by the server. |
Securing the Moodle to Nextcloud connection
The Moodle to Nextcloud repository connects two systems through an OAuth 2 client, so the security of the integration depends on settings in both platforms and on how users are identified. The cards below cover the transport, credential, access, sharing, plugin and monitoring decisions that determine whether course files stay protected.
HTTPS between all parties
Require HTTPS on the Moodle site, the Nextcloud server and every user-facing address, and confirm that the OAuth 2 redirect and callback URLs use https. Check that the Nextcloud server URL configured in Moodle matches the certificate name exactly, and that no internal hop falls back to plain HTTP. Ask your team to test redirects after any reverse proxy or load balancer change.
OAuth 2 client secret handling
The client secret that Moodle stores for the Nextcloud OAuth 2 service is a credential that grants access to the connection. Limit the Moodle capabilities that can view or change the service configuration to a small administrator group, and record who holds them. Rotate the secret when staff with access leave, and confirm where Moodle stores it in your database backups.
Repository access by role
The Nextcloud repository can be made available to specific roles rather than to every user. Decide which roles need to pick files from Nextcloud, such as teachers and selected students, and restrict the repository to those roles. Test with an account from each role to confirm the file picker appears only where it should.
Share defaults for course files
Review the default sharing settings in Nextcloud for the folders and users that hold course material. Decide whether public link shares, link expiry and password requirements apply to course files, and whether resharing is allowed. Document the settings so that teachers know what a link they create from Moodle can expose.
Third-party app review
Each third-party Nextcloud app runs inside the server with access to user files. Keep an inventory of enabled apps, record the reason for each, and review updates before applying them, because Nextcloud advises disabling third-party apps during upgrades until they are confirmed compatible. Remove apps that no course workflow needs.
Identity source for both platforms
Nextcloud documents LDAP and Active Directory integration, and OpenID Connect and SAML user authentication backends, as options for how users sign in. Confirm how your chosen identity source supplies accounts and attributes to both Moodle and Nextcloud, so that a disabled account is removed from both. Check that usernames match across the two platforms.
Logging and token failure monitoring
Enable logging for OAuth 2 token requests and failures on the Moodle side, and collect Nextcloud access logs centrally. Set alerts for repeated token errors, unexpected client secret changes and file access from unusual sources. Confirm with your security team who reviews these alerts and how long logs are retained.
Common Moodle to Nextcloud failures, their causes and fixes
This table lists the failures teams meet most often when connecting Moodle to Nextcloud, with the likely cause, the check to run and the fix direction for each. Work down the rows in order during setup, because the document root and OAuth 2 checks come before file-level problems. Most failures trace back to a mismatched URL, a permission on the Nextcloud side or a skipped upgrade step, so check those first.
| Failure | Likely cause | Check to run | Fix direction |
|---|---|---|---|
| Repository missing from the file picker | The Nextcloud repository plugin is disabled or no Nextcloud instance has been created in Moodle. | Confirm the plugin is enabled in repository management and the instance appears with the expected name. | Enable the plugin, create the instance, then test the picker from a course and from a user profile. |
| OAuth 2 redirect fails or returns an error | The redirect URI in the Nextcloud OAuth client differs from the callback Moodle sends, often in scheme, host or port. | Compare the redirect URI on both sides character by character, including https and any port number. | Correct the URI on the Nextcloud side and the Moodle OAuth 2 service, then retest in a clean browser session. |
| Empty or partial folder tree | The signed-in user cannot read the folders, or the root path configured in the repository is wrong. | Sign in to Nextcloud as the same user and browse the same path in the web interface. | Correct folder permissions or the configured root path, then confirm the account used by the integration has access. |
| Files upload but sharing links break | Generated links use a host or protocol that differs from the address users open, due to trusted domain or public URL settings. | Open a generated link in a private window and check the host and protocol in the address bar. | Set the Nextcloud trusted domain and public URL to the address users actually use, then regenerate affected links. |
| Certificate errors between servers | Moodle does not trust the certificate chain presented by Nextcloud, often an internal authority or a missing intermediate certificate. | Test the HTTPS connection from the Moodle web server and confirm the full certificate chain is served. | Install the internal root certificate or complete the intermediate chain on the Moodle host, then restart PHP and the web server. |
| Broken pages during setup on Moodle 5.1 | The web server document root still points to the main Moodle folder instead of the new /public directory. | Check the document root in the web server configuration and load the site root for directory listings or errors. | Point the document root to the public directory, reload the web server, then test the repository again. |
| Integration stops after an upgrade | A Moodle or Nextcloud upgrade changed the plugin version, OAuth 2 settings or Nextcloud apps, or a major step was skipped. | Compare the repository plugin version and OAuth 2 service settings before and after, and review Nextcloud app compatibility. | Restore matching plugin versions, re-verify the OAuth 2 service, and upgrade Nextcloud one major version at a time after a backup. |
Keeping the integration working through Moodle and Nextcloud upgrades
The Moodle and Nextcloud integration depends on two release schedules that run independently, so a change on either side can break it without warning. Moodle ships major releases in April and October and minor point releases in February, April, June, August, October and December. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases. Treat every upgrade of Moodle or Nextcloud, including minor and maintenance releases, as a trigger to retest the file picker, the OAuth 2 token path and the sharing path before the change reaches teachers and students.
Moodle's support windows should set your upgrade cadence. Moodle 4.5 is a long-term support release with security support until 4 October 2027. Moodle 5.1 has general support until 5 October 2026 and security support until 19 April 2027, and Moodle 5.2 has security support until 4 October 2027. Moodle 5.3, released on 5 October 2026, is the next long-term support release, with general support until 4 October 2027 and security support until 1 October 2029. Confirm these dates on the Moodle releases page before you choose a target. Check the PHP and database minimums in the release notes, and note that from Moodle 5.1 the web server document root must point to the /public directory. Confirm that the Nextcloud repository plugin supports your chosen Moodle version.
Nextcloud is stricter about sequence. Major versions cannot be skipped, so an installation on an older major must step through each intermediate version, one at a time. Take a backup before every upgrade, covering the database, the data directory and the configuration, and confirm that a restore has been tested. Nextcloud's guidance is to disable third-party apps until each is confirmed compatible with the new version. Apps that affect OAuth 2 clients, sharing or user authentication should stay disabled until you have checked them on the test instance. Nextcloud 33 is supported until February 2027 and 34 until June 2027. Nextcloud 35 was released on 16 September 2026 and reaches end of life in September 2027, and Nextcloud 36 is scheduled for 17 February 2027. A single upgrade plan may therefore cover several steps.
Keep a test instance of both systems, built from a recent copy of the production configuration and registered as a separate OAuth 2 client, so that upgrades are rehearsed before they reach users. Run the same retest checklist after each change. For the file picker, confirm that a teacher and a student can open the Nextcloud repository from a course, browse only the folders they are allowed to see, and attach a file to an activity in the expected form. For OAuth 2, confirm that the connection is established, that tokens refresh after expiry, and that a revoked connection shows a clear prompt to reconnect. For sharing, create internal and link shares, check permissions for a student account, and confirm that shares expire or are revoked as configured. Record the results for each Moodle and Nextcloud version pair so the next upgrade starts from evidence.
Questions buyers ask before connecting Moodle to Nextcloud
How much does it cost to connect Moodle to Nextcloud?
The cost depends on the written scope, so no single figure applies to every institution. DeployOpen does not publish a price list, and a quote follows from the agreed scope. The main cost components are planning the file scope, configuring the Nextcloud repository plugin and Moodle's OAuth 2 services, testing against a non-production copy of both platforms, and handing documentation to your staff. Costs rise with the number of Moodle sites and Nextcloud instances involved, the number of user groups and folder rules, any custom work beyond the core plugin, and the testing your security or compliance team requires. Ask for a quote that lists each deliverable, separates one-time work from recurring items such as maintenance, upgrades and support, and states what your team must supply. Ongoing support and upgrades are available as retainers.
How long does a Moodle and Nextcloud integration take?
The duration depends mainly on how quickly decisions and access are settled before the build starts. No fixed timeline applies to every institution, and DeployOpen confirms the timeline in the written scope before work begins. The biggest drivers are the file scope decision (who may pick and share files, and from which folders), whether users sign in to Nextcloud through an existing directory, how many Moodle sites connect, and whether a non-production Moodle and Nextcloud pair is available for testing. Delays most often come from waiting on approvals, certificate issuance and firewall changes. Ask for a schedule with milestones tied to each of those inputs, so you can see which decisions the timeline depends on.
Does connecting Moodle to Nextcloud require Nextcloud Enterprise?
No. The integration does not require Nextcloud Enterprise, because the core Nextcloud repository plugin is configured through Moodle's OAuth 2 services on your Nextcloud server. Enterprise is a separate paid offering from Nextcloud GmbH, aimed at enterprise, public sector and education users. Nextcloud's published list prices start at 71.29 euros per user per year for the Standard tier, 104.99 euros for Premium and 204.75 euros for the third tier, for 100 or more users, with a 100-user minimum and lower rates from 200 users. Standard includes one year of maintenance. Premium adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support. The third tier adds support up to 24/7 with response times down to one hour. Choose a tier based on support and lifecycle needs, and confirm current prices with Nextcloud.
What does our institution need to provide before the integration starts?
Your institution must provide administrator accounts on both Moodle and Nextcloud, plus a service path for the OAuth 2 client, so the integration does not depend on one person's login. Network access must allow Moodle servers to reach Nextcloud over HTTPS, and users must reach both platforms from their browsers. Each side needs a valid TLS certificate that the other server trusts, which often means confirming your internal certificate authority. A non-production Moodle and Nextcloud pair is needed for testing. Finally, name the decision makers for file scope: who may pick files, which folders or groups are included, and who approves sharing rules. Confirm each item with your own identity, network and security teams before the schedule is fixed.
Can our own team connect Moodle to Nextcloud without outside help?
Yes, a team with administrator experience in both platforms can configure the core plugin and the OAuth 2 service, provided it has the time and a test environment. The configuration work covers creating the OAuth 2 service in Nextcloud, registering it in Moodle, enabling the repository for the right roles and testing the picker and sharing behavior for each role. Skill gaps usually sit in TLS, reverse proxy headers and web server settings. The larger ongoing effort is upgrades. Nextcloud does not allow skipping major releases, so administrators upgrade one major version at a time, back up before each upgrade and disable third-party apps until they are confirmed compatible. Moodle ships major releases every six months. Outside help is most useful when deadlines are tight or when documented handover to your staff is required.
What breaks when Moodle or Nextcloud is upgraded?
The most common breaks come from version mismatches, outdated third-party apps and web server settings, and each platform's upgrade rules shape the work. Nextcloud publishes a major version every four months and supports each for one year, so your upgrade path must move through each major release in turn. Moodle 5.1 requires 64-bit PHP 8.2 or later and changes the web server document root to the /public directory, and Moodle 5.3 requires PHP 8.3 or later and sites must already run Moodle 4.4 or later. After either platform changes, recheck the OAuth 2 service, the redirect addresses, the repository plugin settings and the certificate chain. Schedule upgrades so both sides are tested together in the non-production pair before production changes.
What should we test after the Moodle and Nextcloud connection goes live?
Test each role separately, because teachers and students need different access to the file picker and sharing options. Confirm that a teacher can pick a file from an approved folder, that a student sees only what the teacher shares, and that files attached to a course remain available after the user's Nextcloud session ends. Check token refresh after the access period expires, the behavior when a Nextcloud user is disabled, and what happens when Nextcloud is unreachable from Moodle. Test with large files and with a mobile browser, and review the logs on both platforms for failed authorization attempts. If users sign in through an LDAP or Active Directory connection to Nextcloud, test that account changes in the directory reach both platforms. Record the results so the next upgrade test can repeat them.
How DeployOpen scopes, delivers and supports the Moodle and Nextcloud integration
DeployOpen scopes the Moodle and Nextcloud file integration as a fixed-scope engagement, with the scope agreed in writing before work starts. We configure Moodle's core Nextcloud repository plugin through Moodle's OAuth 2 services, test it on your own Moodle and Nextcloud versions, and document the result for your administrators. Ongoing support and upgrade checks can run as a retainer.
How we scope
- The written scope names your Moodle and Nextcloud versions, hosting locations and the users who will share files.
- Scope confirms which Moodle file pickers, course areas and roles can reach Nextcloud folders.
- Engagements are fixed-scope, and ongoing support can be added later as a retainer.
How we build
- Configure the OAuth 2 connection between Nextcloud and Moodle's OAuth 2 services, with redirect addresses checked.
- Enable the core Nextcloud repository plugin and test picking and sharing files in a staging course.
- Test permissions for teachers, students and course roles, including what happens when access is revoked.
How we hand over
- Deliver a configuration record covering OAuth 2 settings, plugin version and Nextcloud connection details.
- Document test results, known limits and the exact steps to repeat the setup after a Moodle upgrade.
- Walk administrators through the configuration and the upgrade checks they must repeat for each release.
How we support
- Plan Nextcloud upgrades one major version at a time, with a backup taken before every step.
- Re-test the repository connection after each Moodle release and after changes to Nextcloud apps or identity settings.
- Support can run as a retainer covering upgrades, connection checks and fixes between releases.
