n8n and Nextcloud integration

Settle the license and edition before you design the Nextcloud workflow, because both affect what you can build and what you pay. n8n is source-available under the Sustainable Use License, which allows use or modification for your own internal business purposes, along with non-commercial and personal use. A company that self-hosts n8n to move files, folders and shares between Nextcloud and its internal systems appears to fit that wording. The license is still a legal text, so ask your legal team to confirm in writing that the planned use is internal. Ask them specifically about any case where the same instance serves a subsidiary, a client, a partner or a customer-facing product, since those cases may fall outside the terms.

Next, check the code paths your design depends on. Files with .ee in their name or directory are not covered by the Sustainable Use License and require a valid n8n Enterprise License. Before you build, list every node, feature and custom change the workflow needs, then confirm with n8n whether any of them sit in .ee files in the version you plan to deploy. Repeat that check at each upgrade, because the set of enterprise-only files can change between releases. Record the result in the design document so that a future engineer does not add an enterprise-only feature without a license decision.

The Community edition is free to self-host, so a team can build and test the Nextcloud workflow without a plan purchase. Identity is where that choice tends to change. According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. If staff must sign in to n8n with corporate identity, or if the audit trail must leave the instance through log streaming, confirm the plan before design begins. The Business plan is listed at 667 euros per month billed annually and is currently self-hosted only. Treat that figure as a reference point, confirm current terms with n8n, and budget separately for hosting, the database and the staff who run the instance, since those costs are not part of the n8n subscription.

High availability is the last factor to settle. n8n's multi-main setup, which runs several main instances, is restricted to Enterprise self-hosted deployments. If the Nextcloud workflow must keep running when one main instance fails, that requirement points toward an Enterprise quote, while a team that accepts a short interruption may be able to plan around the Business or Community edition. Write the decision as a short record: the license reading from legal, the list of enterprise-only files checked, the identity method, the logging requirement and the availability target. Ask n8n for written confirmation of the plan features you rely on, and ask for the same confirmation again before each renewal.

In n8n queue mode, the main instance receives triggers and webhooks, then passes executions through Redis to a pool of workers that read and write workflow data in PostgreSQL. For a Nextcloud workflow, the trigger may fire on the main instance while the file move or share change runs on a worker. Every process that executes a Nextcloud step needs access to the same stored credential, so the architecture determines where that credential is used. Before you size the deployment, map which processes touch PostgreSQL, which touch Redis and which connect to Nextcloud. Confirm with your platform team who operates both shared services, because a Redis or database outage stops Nextcloud automation on every node at once.

The main instance's encryption key must be shared with all worker and webhook processor nodes, so each one can decrypt the Nextcloud credential stored in the database. A worker holding a different key cannot decrypt that credential. The failure then shows up during a Nextcloud step as an authentication or connection error, and teams often start by checking Nextcloud, its app passwords, network routes and certificates. Add a check to your runbook: after any node is built, cloned or redeployed, run one read-only Nextcloud operation from that node and confirm it succeeds. Store the key in your secrets manager and inject the same value into every n8n process, with the value recorded in change control so a mismatch can be traced quickly.

Multi-main high availability runs several main instances and is restricted to Enterprise self-hosted deployments. It is not available in the Community edition or on n8n Cloud. For most teams automating Nextcloud document workflows, a single-main design with a worker pool is the baseline. Resilience then depends on the platform beneath n8n, including how PostgreSQL and Redis are made highly available and how the main instance is restored from backup. If the business needs main-instance failover, confirm in writing with n8n which license and deployment options apply before the architecture is approved, since the license terms also determine whether specific .ee files may be used. Ask for this confirmation early, because it changes the budget and the procurement path.

Rotating the encryption key is a coordinated change across all nodes, not a routine configuration edit. Plan a maintenance window in which the main instance and every worker and webhook processor move to the new key together, then test each Nextcloud credential afterward. Before the window, back up the database, list the workflows that use Nextcloud credentials and note which other integrations store credentials in n8n, so they are included in the test scope. Ask your n8n contact how existing stored credentials are handled when the key changes and what rollback path is supported. A rotation that is not rehearsed in a non-production environment with the same node layout is the most likely source of the credential errors described above.

Every n8n workflow that reads, moves, or shares files in Nextcloud should pass a test run against a staging Nextcloud instance or a dedicated test folder before it gets access to production shares. A separate instance is the stronger option because it also lets you test upgrades, but many teams start with a test folder inside a non-production share. Either way, create a dedicated service account for the workflow with only the permissions it needs, and confirm with your Nextcloud administrator that the account cannot reach folders outside the test scope. Use sample files that contain no regulated or confidential data.

Run the tests in a fixed order. Start with read tests, such as listing a folder, downloading a file, and reading metadata, because they change nothing. Next, run copy and move tests on sample files, then check that the destination contents and file names match what the workflow expects. Share-creation tests come after that, and they should cover expiry dates and password settings as well as the basic link. Finally, run error-path tests: a file deleted before the workflow reaches it, a file locked by another user, and a user account denied access to the folder. Record the expected result for each step before you run it, so that a pass means something.

Each test run should produce an execution record that someone can trace later. n8n counts an execution as one run of a whole workflow, so a failed run shows which step failed and with what input, provided execution data is saved. Decide how long execution history is kept, who can view it, and where failures are reported, such as an error workflow that posts to an operations channel. Log streaming to an external system is included only in n8n's Business and Enterprise plans, so if your audit trail depends on it, confirm your plan and your retention settings before go-live rather than assuming the Community edition covers it.

Any workflow that moves or deletes files needs a rollback plan before it runs in production. Document how each moved or deleted file would be restored, who can do it, and which backup or Nextcloud recovery mechanism applies. Confirm with your administrator whether deleted files and file versions are retained in your configuration and for how long. Then rehearse the rollback in the test environment, including a restore from backup, so the team knows the steps work under pressure.

The test environment also serves upgrades. Nextcloud publishes a new major version every four months, and each major version is supported for one year. Nextcloud 35 was released on 16 September 2026, and Nextcloud 36 is scheduled for 17 February 2027. Nextcloud does not allow skipping major releases, requires a backup before every upgrade, and recommends disabling third-party apps until they are confirmed compatible. After each major change, rerun the full test sequence against the upgraded staging instance before the production upgrade, and schedule the same check for n8n upgrades.