Choosing server-side or end-to-end encryption for self-hosted file sharing
Server-side encryption suits storage you do not fully trust, such as a shared storage array, an external storage backend or a hosting provider whose staff you cannot audit. End-to-end encrypted folders suit data that administrators must not read, because keys live on users' desktop or mobile clients and the server never holds plaintext. In Nextcloud, server-side encryption protects files at rest on local and external storage with keys held on the server, using either a master key or per-user keys with an optional recovery key. End-to-end encryption is performed by the desktop and mobile clients, so only users can decrypt. The decision is therefore made per data set, not per platform: a single Nextcloud instance can hold ordinary team files under server-side encryption and a small set of board or legal folders under end-to-end encryption.
The cost of each choice falls on the same three functions. Server-side encryption keeps full-text search and web editing working because the server can read the content, but it leaves administrators able to access files through the server's keys. End-to-end encrypted folders stop the server from indexing content, so search depends on what the client holds, and web-based office editing is generally not available for those folders, so confirm this against the version you run. Recovery also changes: if a user loses the only copy of a key, the data may be unrecoverable, so the recovery design must be agreed before rollout. Ask your implementation partner to document which folders use which mode, who holds recovery material, and how each mode is tested in your Nextcloud admin manual reference for server-side encryption before users are onboarded.
Which encryption requirements the regulation or constraint actually sets
This table maps the HIPAA transmission and audit provisions and the SEC retention duty to what encryption must achieve and what it must not block, such as admin audit and record recovery. Read each row as an outcome the regulation sets, then check whether your chosen mechanism still lets you prove it.
| Requirement | What it asks for in practice | Where encryption design can break it |
|---|---|---|
| HIPAA 164.312(e)(1), transmission security | Guard against unauthorized access to ePHI sent over a network, using technical measures you choose and document | Encrypting in transit is necessary but does not cover files at rest. Confirm how TLS, sync clients and external share links are configured and documented |
| HIPAA 164.312(b), audit controls | Record and examine activity in systems that contain ePHI | End-to-end encrypted folders can hide file content from the server, so server logs may show only opaque events. Confirm which events remain visible to administrators |
| SEC 17a-4(b)(4), communications retention | Preserve originals of business communications for not less than three years, including inter-office messages | If only users hold decryption keys, an administrator may be unable to export records after a user leaves. Confirm a retention path that works without the departed user |
| Key custody and recovery | The regulation sets outcomes, so you must document who holds keys, how recovery works and who approves it | A recovery key stored beside the data or a single admin holding every key can fail an assessor review. Document custody split, rotation and access logging |
| Admin access to content | No rule in these two provisions requires administrators to be unable to read data | Choosing end-to-end encryption to satisfy a control you have not mapped can remove the admin audit and recovery path. Map each control before choosing |
| Evidence for the assessor | Written design decisions, key procedures and test records showing the controls operate | Undocumented key handling and untested recovery steps are the most common gap. Ask your partner for a recovery test record |
| Scope of the regulated data | Applies to ePHI or retained communications wherever they are stored, including backups and search indexes | Server-side search indexes or previews may store plaintext derivatives. Confirm where derived data is kept and encrypted |
How server-side encryption protects files at rest with a master or per-user key
Server-side encryption in Nextcloud protects files at rest on local and external storage, with the keys held on the server. Its value is narrow but real: if a disk, a backup tape or a storage system that you do not fully trust is removed or copied, the files on it are unreadable without the keys that the Nextcloud instance manages. You choose between a master key, which encrypts every user's files under one server-held key, and per-user keys, which give each account its own key and make it possible to scope a compromise to one user. The Nextcloud admin manual describes both models in its Server-side Encryption section, linked from this page's sources. Before you enable either, confirm which encryption module your Nextcloud version uses, whether the module is still supported for your release line, and how it interacts with the external storage mounts you plan to use.
The recovery key is the decision that most often goes wrong. With per-user keys, an optional recovery key lets an administrator read a user's files after a password reset or an account lockout. Without it, a forgotten password can make that user's encrypted files permanently inaccessible. Decide early who holds the recovery key, where it is stored, and how its use is logged, and test a restore before you rely on it. Document this as part of your key management procedure, because an auditor will ask who can decrypt data and under what conditions.
Server-side encryption does not protect files from anyone who controls the running server. Because the keys live on the server, an administrator with root access, a compromised application process or a person with access to the database can obtain what is needed to read plaintext. Treat it as protection for data at rest against physical and storage-layer loss, not as protection from your own operators. If the requirement is that even administrators cannot read the files, you need end-to-end encrypted folders, which move key control to the user's client, and you should accept the search and web editing limits described in the sibling sections of this page.
What each option breaks in search, web editing and recovery
With server-side encryption under a master key, Nextcloud encrypts files at rest on local and external storage, and the keys stay on the server. The platform can still decrypt content for users, so this model protects data on disks, backups and external storage from parties who hold no server access. It does not hide files from the people who run the platform.
- Full-text search: Indexing runs on the server against decrypted content, so search usually keeps working for users. Confirm how your full-text search setup handles encrypted files before you rely on it.
- Web editing: The office integration, such as ONLYOFFICE Docs or Collabora Online, receives files from the server, so browser editing follows the normal workflow. Test editing on a staging instance with your chosen office server.
- External guests: Public and guest links are served by the server, so expiry dates, passwords and download limits apply as they do without encryption. Confirm the exact share options in your version.
- Admin recovery: Because the server holds the master key, an administrator can open a locked user's files after a password reset. Document who may perform this action and under which approval.
- Version history: Versions are encrypted under the same key model, so restoring a version follows the same path as restoring the current file. Confirm restore behavior after any key rotation.
Confirm with your auditors that server-held keys meet the requirements for each data class, and run a search, an edit and a version restore on a staging instance before rollout.
Server-side encryption with per-user keys gives each account its own key, protected by that user's credentials, with an optional recovery key. The server can read a user's files only while that user's key material is available, which narrows administrator access. The trade-off is that a lost password can leave files unreadable unless a recovery key was set up in advance.
- Full-text search: Indexing needs access to decrypted content, so search results for users who have not logged in may be incomplete. Confirm how your version indexes files whose owner's key is not loaded.
- Web editing: Office editing needs the server to read the file during the session. Expect editing to work for logged-in users, and confirm the behavior for files shared by an owner who is offline.
- External guests: Links created by a user depend on that user's key material. If the owner leaves or is locked out, guest access to those files may fail. Confirm the behavior for your version and plan a reassignment procedure.
- Admin recovery: After a password reset, an administrator may be unable to open the user's files without the recovery key or a documented key recovery step. Store the recovery key under dual control and test the procedure before it is needed.
- Version history: Each version is protected under the owning user's key, so restoring a version for a departed user may require their key material or the recovery key. Confirm this path with your version.
Before deployment, ask your partner to demonstrate a password reset, a recovery key use and a version restore for a test account, and record the results as evidence.
End-to-end encrypted folders are encrypted and decrypted by desktop and mobile clients, so the server stores ciphertext and administrators cannot read the contents. This is the strongest protection against platform administrators, and it carries the largest functional trade-offs. Plan the workflows around those limits before you place sensitive data in these folders.
- Full-text search: The server cannot index the content of end-to-end encrypted folders. Plan for client-side search or file-name search only, and confirm exactly what the client offers in your version.
- Web editing: The office server cannot open ciphertext, so browser editing of files in these folders is generally not available. Confirm this for your version and plan editing through desktop clients with local office applications.
- External guests: Anonymous public links generally cannot deliver plaintext from these folders, so external recipients need another channel or a different folder design. Confirm the supported sharing paths in your version.
- Admin recovery: If a user loses the device keys and the recovery material, the administrator cannot restore the content. Require a documented key recovery process and test it with a test account.
- Version history: Versions are also stored as ciphertext, so restoring a version depends on the client holding the key. Confirm whether restores are possible from the web interface in your version.
Ask your partner to map each sensitive workflow to one of these limits and to document which folders use end-to-end encryption and which use server-side encryption.
Which self-hosted platforms fit each encryption model
Encryption model is a platform decision as much as a configuration choice, because server-side and end-to-end encryption are supported to different degrees by each product. The cards below separate the Nextcloud options that most deployments start with from the alternatives and adjacent tools to check before committing.
Nextcloud server-side encryption
This is the Nextcloud mode that protects files at rest on local and external storage, with keys held on the server under either a master key or per-user keys with an optional recovery key. It fits storage you do not fully trust, such as a hosted volume or object store, because the storage operator cannot read plaintext without server keys. Check who controls the key store, whether the recovery key is held under dual control, and how the master key is backed up. Server-side encryption does not hide files from server administrators.
Nextcloud end-to-end encrypted folders
End-to-end encrypted folders are decrypted only by desktop or mobile clients, so the server and its administrators cannot read the content. This is the model to choose when even administrators must not read data. The trade-offs are real: search, previews and web editing of those folders do not behave like ordinary folders, and key recovery depends on the user or a process you design. Test each workflow your users need before rollout.
Seafile as a comparison candidate
Seafile is released under GPLv2 with an additional permission to link with OpenSSL, and offers file sync and share as an alternative to Nextcloud. Its encryption feature set differs from Nextcloud, including how it handles client-side encryption and library passwords. Do not assume parity. Confirm with the vendor which encryption modes are supported in the edition you plan to run, how keys are recovered, and which search and preview functions still work on encrypted libraries.
AGPL licensing and Enterprise support
Nextcloud Server is licensed under AGPL-3.0, so the community edition carries no license fee but does carry source obligations if you modify and offer the software over a network. Nextcloud GmbH sells Enterprise for organizations that need a maintenance lifecycle and support tiers. Encryption issues often surface during upgrades, so ask whether the support contract covers encryption configuration and key handling in writing.
Office editors and encrypted files
Browser-based editing with ONLYOFFICE Docs or Collabora Online works on server-side encrypted files because the server can decrypt them for the editing session. It does not work for end-to-end encrypted folders, where the server never holds plaintext. Plan for users to download, edit locally and re-upload in those folders. Confirm the editor integration and the exact behavior with your chosen editor before setting encryption policy by folder.
How encryption is rolled out without losing recoverable data
This sequence moves from deciding who must be able to read each data set to a documented key procedure that the team has tested. Each phase produces a record that the next phase depends on, so recovery is designed before any folder is encrypted.
Classify data by who must read it
Inventory the folders, groups and external shares in scope and record, for each one, which people and which administrators must be able to read the content. Include the business owner, the data class and any regulation that names the data. Who does this: the data owner with the compliance lead, using the file server or Nextcloud admin view as the starting inventory. Output: a classification register with one row per folder or group, a named reader list and a named owner. The step is done when every folder in scope has a row and no row is left with an unnamed owner.
Choose the encryption model per folder
For each row in the register, select server-side encryption or end-to-end encryption. Server-side encryption keeps keys on the server and protects data at rest on local and external storage, using a master key or per-user keys with an optional recovery key. End-to-end encryption is performed by desktop or mobile clients, so only users holding the keys can decrypt. Record what each choice breaks, including server-side search, web editing and administrator recovery. Output: a model decision record that the security architect and data owner sign off on before any configuration change is made.
Design key custody and recovery
Define who holds each key or recovery key, where it is stored, how access to it is logged and how a lost user key is handled. Decide whether a recovery key is enabled for server-side encryption and who may use it, and document the consequence for end-to-end folders where a lost key may mean lost data. Confirm these behaviors against the current Nextcloud server-side encryption and end-to-end documentation for the version you run. Output: a key custody record and a recovery procedure that names approvers, storage locations and the audit evidence created on each use.
Pilot with a limited group
Enable the chosen model for a small group of users and folders that reflects real work, including a user who loses a device, a desktop sync client, a mobile client and a web editing session. Test sharing to internal users and to any external recipient, search results, previews, versioning and restore from a backup. Output: a pilot test report listing each test case, the expected result, the observed result and the defect or accepted limitation. Do not widen the scope until every failed case has an owner and a decision.
Test recovery before wider rollout
Run a controlled recovery exercise in which a test user loses access, the recovery path is invoked and the data is restored and verified. Repeat the exercise for an end-to-end folder to confirm that data is unreadable without the client-held keys, which is the intended behavior and must be understood by the business. Output: a signed recovery test record with timestamps, the person who approved each step and the outcome. This record is the evidence that recoverable data is actually recoverable.
Enforce policy in the platform
Translate the register into folder-level or group-level rules so that users cannot move data from an end-to-end folder into a server-side folder by accident, and so that external sharing and web editing follow the restrictions set for each class. Confirm which of these controls the chosen Nextcloud version and app set supports, and mark any gap as a compensating control. Output: a configuration baseline exported from the server and a change log for each rule, reviewed against the register.
Document the key procedure and train administrators
Write the runbook covering key generation, rotation, escrow, emergency access, user offboarding and the retention of audit logs for key use. Train the administrators who will execute it and have them perform one tabletop run from the runbook. Output: an approved key procedure document, a training attendance record and a tabletop result that lists any steps the runbook did not cover. The procedure is complete when the register, the key custody record, the pilot report and the recovery record all point to the same version of the runbook.
Evidence auditors ask for about encryption keys and access
This table lists the evidence an assessor typically asks for when files are encrypted on a self-hosted Nextcloud, which component or team produces each item, and what it proves. Read it as a checklist to agree with your auditor before the assessment, since the required set depends on your framework and scope. DeployOpen prepares and organizes this evidence from your environment, but independent auditors and certification bodies decide whether it is sufficient.
| Evidence item | What it shows | Produced by |
|---|---|---|
| Key custody record | Who holds the master key or recovery key, where it is stored, and who can rotate or retrieve it | Your key custodians, documented in your key management procedure |
| Encryption configuration export | Whether server-side encryption is enabled, which mode is in use (master key or per-user keys), and which storage is covered | Nextcloud occc commands and the server configuration files, exported and dated |
| End-to-end encrypted folder inventory | Which folders use client-side encryption and which users hold access to them | Nextcloud admin reports and client-side encryption settings, reviewed by your administrators |
| Administrator action audit log | Changes to encryption settings, key operations, user role changes and access to shared folders | Nextcloud audit logging, forwarded to your central log platform |
| Access review records | Which accounts and groups can reach sensitive folders, and proof that reviews were completed and corrected | Your identity provider (LDAP, Active Directory, OpenID Connect or SAML) plus signed review records from data owners |
| Recovery test records | That key recovery and file restore work as documented, with dates, scope and results | Your operations team and DeployOpen test runbooks, with tickets for any failed step |
| Data classification register | Which data classes are stored where, and which classes require server-side or end-to-end encryption | Your data owners and compliance team, maintained alongside the file platform inventory |
| Upgrade and patch records | That the Nextcloud version and encryption components were kept within supported releases | Your change records and the Nextcloud maintenance and release schedule, compared against the running version |
Questions buyers ask before choosing encryption for file sharing
What does encryption design cost, and what drives the price up?
The cost is set by the written scope, not by the choice of encryption mode alone. Server-side encryption in Nextcloud is a configuration task on a platform you already run, while end-to-end encrypted folders add client rollout, user training and key handling work. Cost drivers include the number of users and devices needing desktop or mobile clients, how many user groups need different key rules, whether existing storage is mounted through external storage, and how much testing of search, editing and recovery is required. The Nextcloud Enterprise pricing page lists per-user annual rates for Standard, Premium and Ultimate tiers with a 100-user minimum, so the support tier is a separate line item to weigh. Ask for a fixed-scope quote that lists one-time work (design, configuration, testing, documentation) separately from recurring items (support subscription, maintenance, key custody reviews).
How long does a pilot for encrypted file sharing take?
A pilot length depends on the number of user groups, the encryption modes under test, and how many existing systems must be checked. A pilot that only compares server-side encryption with a master key against per-user keys is smaller than one that also validates end-to-end folders across desktop and mobile clients, web editing and recovery procedures. It also depends on whether you can supply a test environment that matches production, test accounts in each group, and a sample of real file types. DeployOpen does not publish a fixed pilot duration, so ask for the timeline in the written scope and confirm which acceptance tests are included before work starts.
What must our organization supply before encryption can be designed?
Three inputs decide most of the design. First, name the key custody owners: who holds the master key, who can approve recovery, and whether a separate team must control key material. Second, complete a data classification that marks which folders hold regulated, confidential or general content, because only some data may need end-to-end protection. Third, define user groups with their access rules, including which groups need web editing, which need external sharing and which are administrators who must not read certain data. Also supply the directory source (for example, LDAP or Active Directory, OpenID Connect or SAML) so identity and key rules match. Confirm these inputs with your security and compliance leads before the scope is written.
Can our internal IT team set up server-side or end-to-end encryption alone?
A capable Nextcloud administrator can enable server-side encryption, but the decision about key custody, recovery and evidence usually needs more than one team. Server-side encryption protects files at rest on local and external storage, with keys held on the server, using a master key or per-user keys with an optional recovery key. End-to-end encryption is performed by desktop or mobile clients, so rollout, client version control and user support become a larger program. Internal teams can usually own day-to-day operations once a design is documented. Ask any partner which parts they will build with you, which they will hand over, and what knowledge transfer and runbooks are included in the fixed scope.
What happens if an encryption key is lost?
The result depends on which encryption mode you chose. With server-side encryption, the keys are stored on the server, so an optional recovery key is the main safeguard for restoring access if a user's per-user key is lost, and the master key must be backed up under controlled custody. With end-to-end encrypted folders, the server cannot decrypt the data, so a lost key or lost device can leave files unreadable unless the user has recovery material. This is the trade-off buyers must accept: stronger protection from administrators also means fewer recovery options. Before go-live, document who can authorize recovery, how keys are backed up, how recovery is tested, and what is logged. Ask for a written recovery runbook as a deliverable.
Do end-to-end encrypted folders work with web editing and search?
Not in the same way as unencrypted folders, so confirm the behavior for each feature you need. Nextcloud documents that end-to-end encryption is performed by desktop or mobile clients, which means the server does not hold keys to read content. Features that depend on the server reading file content, such as server-side full-text search and web-based office editing, may not operate on end-to-end encrypted folders as they do on standard storage. Test these behaviors against the version you plan to run, because Nextcloud 35 was released on 16 September 2026 and features change between major releases. Ask for a test matrix covering search, web editing, sharing and mobile access before you decide which folders get end-to-end protection.
Which Nextcloud version and support tier should we plan around?
Plan around a supported major version and confirm the support tier in writing. Nextcloud publishes a new major version every four months and supports each for one year, with Nextcloud 35 released on 16 September 2026 and end of life in September 2027. Nextcloud does not allow skipping major releases, so upgrades must move one major version at a time with a backup before each step. Enterprise tiers differ in maintenance lifecycle and support hours, which affects how long your encryption configuration stays on a supported release. Ask your partner how upgrades will be scheduled and tested, and whether the encryption settings are retested after each upgrade.
Does encryption choice satisfy compliance evidence requirements on its own?
No. Encryption is one control among several, and the evidence you need depends on your regulator and framework. For example, the HIPAA Security Rule at 45 CFR 164.312(e)(1) requires technical measures to guard against unauthorized access to ePHI sent over an electronic communications network, and 164.312(b) requires audit controls that record and examine activity in systems containing ePHI. Those requirements sit alongside access control, logging and key management, so encryption design should be mapped to each obligation. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Confirm with your assessor which artifacts they will accept.
Questions to ask an implementation partner about encryption design
Start with key custody, because it decides every other answer. Ask the partner exactly where the server-side master key or per-user keys are generated, which key store or hardware module holds them, and whether the same administrator role can read the key material and the data volume. For end-to-end encrypted folders, ask how the client generates the key pair, how the private key is wrapped with the user's credentials, and where the wrapped key is stored. Ask who holds the recovery key for server-side encryption, whether it is escrowed in a separate custody process, and whether the answer changes if the organization's stated requirement is that even administrators must not read data. A partner who cannot answer these with a configuration screen or runbook step is not ready to design the model.
Next, ask what a lost key does to the data. For server-side encryption with a recovery key, the partner should walk through the recovery procedure, who authorizes it, and how it is logged. For end-to-end encrypted folders, ask what happens when a user loses every device and password, whether the data can be recovered at all, and which people in the organization accept that loss as a designed outcome. Ask which search and editing features stop working for each folder class. Confirm the answer in your own environment, because server-side indexing, previews and browser-based editing depend on the Nextcloud version and the Office integration you choose, and the partner should show a test result for each.
Finally, ask how the encryption model is retested. Nextcloud does not allow skipping major releases, so each upgrade is a step through one major version at a time, and the partner should describe the test plan that runs after each step, including encrypted upload, download, sync, search, sharing and key recovery. Ask what evidence is delivered at handover: the key management design, the role matrix for key access, the recovery test record, the upgrade test reports and the audit log samples. Check that the evidence is written for your assessor, and that DeployOpen prepares these artifacts for an independent auditor rather than issuing an attestation. Nextcloud's encryption documentation is a useful reference to bring to this conversation.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted Nextcloud inside your own cloud accounts, data centers or air-gapped networks. For encryption, we start by deciding which parties must be unable to read your files, then build and document the design that matches that answer.
How we scope
- Map which parties (administrators, storage providers, support staff) must be unable to read file contents, and record that decision in writing.
- Inventory which folders need end-to-end encryption and which can use server-side encryption with a master or per-user key.
- Document the search, web editing, sharing and recovery trade-offs for each encryption choice before any configuration begins.
- Agree scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
How we build
- Configure server-side encryption, recovery key handling and key storage on your Nextcloud instance and your chosen storage backends.
- Set up end-to-end encrypted folders on desktop and mobile clients, and test which features behave as expected inside them.
- Test the design with security testing that covers the application, its APIs and the surrounding infrastructure.
- Confirm that audit logging and access controls record the activity your encryption design depends on.
How we hand over
- Deliver a written encryption design that lists which folders use which mode and why, with the known feature limits.
- Document key custody, recovery key procedures and the steps for restoring encrypted data after a failure.
- Provide runbooks for user onboarding, lost-key handling and client configuration so your team can operate the design.
- Prepare control evidence for your compliance assessment. DeployOpen does not issue audit reports or certifications; independent auditors do.
How we support
- Plan upgrades one major Nextcloud version at a time, with a backup before each upgrade and third-party apps checked for compatibility.
- Retest encryption behavior after upgrades, client updates and changes to the storage or identity layer.
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Ask any partner, including DeployOpen, to confirm in writing which encryption features and support tier are in scope.
