Why file sharing in air-gapped networks is a different build
In an air-gapped network, files cannot leave the environment and the platform cannot reach update servers, so the build is driven by how software, certificates, malware signatures and upgrades get in, not by which features the platform offers. For this use case, Nextcloud and Seafile are the realistic self-hosted options. Both can run without a route to the internet, but each needs a deliberate offline delivery process: every server package, app, container image, database driver and signature file is downloaded on a connected staging system, verified, transferred on approved media and installed inside the boundary. Nothing updates itself, so the team owns the calendar for every patch.
Licensing and edition choice matter earlier than most teams expect. Some air-gapped capabilities sit in paid tiers rather than the community code. The pricing pages for Mattermost, Rocket.Chat and Element show the pattern: Mattermost lists air-gapped deployment under Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Element separates a free AGPL Community edition from a Sovereign edition built for air-gapped deployments. For file sharing, ask each vendor in writing whether offline installation, offline app updates and any support for disconnected operation are included in the edition you plan to run. Nextcloud sells Enterprise alongside its community version, and its pricing page lists tiers with a 100-user minimum, so the answer to that question shapes the budget as much as the architecture.
Plan the operating model before the first install. The team should decide who performs staging, who signs off on each transferred package, how certificates from the internal authority reach clients, and how antivirus signatures are refreshed on a schedule the security team can evidence. Confirm with your vendor and your own change board which artifacts they will supply for offline use and in what format, because an upgrade path that depends on an unlisted download can stall the whole program. Treat the offline process as a product in its own right, with a written runbook and a test environment that mirrors production.
Which requirements shape an air-gapped file sharing build
This table maps each regulatory or control requirement to what it means for an air-gapped Nextcloud or Seafile build. Read each row as a question to confirm with your compliance lead: which rules apply depends on your data, and no regulation names a specific product.
| Requirement | What it asks for | What it means for the build | What to confirm |
|---|---|---|---|
| NERC CIP-013-2 software integrity | Procurement processes that verify software integrity and authenticity for vendor software and patches | Mirror packages into an offline repository only after checking signatures and hashes, keep a record of each import, and reject anything unverified at the boundary | Whether your utility is in scope, and which verification steps your supply chain policy already defines |
| Offline repositories and update media | Controlled, traceable delivery of application, server and container updates across the gap | Stage Nextcloud releases, PHP and database packages, and third-party apps on approved media, with a change record for each transfer | Whether app store access is blocked, and who approves each transfer batch |
| HIPAA 164.312(e)(1) transmission security | Technical measures that guard against unauthorized access to ePHI sent over an electronic network | Enforce TLS on internal hosts, use the internal certificate authority for every service, and disable external sharing and federation so ePHI does not leave the enclave | Whether ePHI is stored at all, and whether your risk analysis accepts the internal certificate chain |
| HIPAA 164.312(b) audit controls | Mechanisms that record and examine activity in systems holding ePHI | Send Nextcloud audit events to a log store inside the enclave, protect log integrity, and review access reports on a defined schedule | Retention period for audit logs and who reviews them |
| SEC 17a-4(b)(4) record retention | Preservation of business communications for not less than three years for broker-dealers | Configure retention and versioning for files that are business records, keep trash and version settings aligned with the policy, and store backups in the enclave for the same period | Whether shared files are records under your program, and whether your SEC or FINRA obligations require non-rewritable storage |
| Antivirus signature updates offline | Malware protection that still works without internet access to vendor update servers | Import antivirus signature files through the same verified transfer path, record their versions, and confirm the scanner reports the signature age | How often signatures must be refreshed under your standard, and who signs off on each import |
| Internal certificate authority | Trusted certificates for every internal endpoint, including sync clients and mobile apps | Distribute the internal root certificate through managed devices, plan renewal and revocation, and test client behavior with the private chain | Whether devices outside the enclave need access and how they will trust the root |
| Backup and restore within the enclave | Recoverable copies of data that stay inside the controlled boundary | Keep backup targets and keys inside the isolated network, test restores on a schedule, and include the database and configuration in each backup | Restore time and recovery point targets set by your business continuity plan |
How to install and update Nextcloud with no internet connection
The core of an offline Nextcloud deployment is a controlled delivery chain: release archives are downloaded and verified on a connected staging network, transferred across the gap through an approved media or diode process, and installed from local copies only. Verification should cover the checksums and signatures published with each release, recorded in a transfer log that the security team can audit. Confirm with Nextcloud, for your exact version, which release artifacts, checksums and signature files are published and how to validate them. Plan the install so that the server never needs to reach the public internet for updater checks, and disable any update check that calls out, including the built-in updater and the app store, in config.php so the admin interface does not attempt outbound connections. Confirm the exact configuration keys for your release in the Nextcloud upgrade manual.
App updates and third-party apps need the same discipline as the core. Every app package, including the apps you rely on for directory login or antivirus, must be downloaded, hash-checked and reviewed on the staging side, then carried across as a complete bundle with its dependencies. Third-party apps should stay disabled until they are confirmed compatible with the target major version, which matches Nextcloud's upgrade guidance. Keep an inventory of each app, its version and its source so that a later upgrade can be tested against the same list.
Containerized deployments add a second layer. Nextcloud All-in-One and Kubernetes pull images from registries on first start and on updates, so they need a private registry with mirrored images. Kubernetes shows the pattern: kubeadm config images list and kubeadm config images pull fetch control plane images in advance, and kubeadm init --image-repository points the install at a private registry. The same idea applies to the Nextcloud images, Redis, the database and the ClamAV image. Confirm with the vendor which image tags and digests correspond to your release, and which additional images the bundle pulls at runtime.
Internal certificates, antivirus signatures and federation in the enclave
An air-gapped enclave cannot rely on public certificate authorities or online revocation checks, so every TLS connection between clients, the Nextcloud server and the database has to chain to a CA the organization runs itself. The design question is less about issuing certificates and more about who holds the root key, how intermediate certificates are issued and renewed, and how the trust store reaches every sync client, server and database node without internet access. Confirm these points before the build starts, because a missing trust anchor usually shows up only when a client refuses to connect.
- Trust store distribution: Ask how the internal root certificate is installed on the server, the database hosts, managed endpoints and the desktop and mobile sync clients, and how a new root is rolled out.
- Server and database TLS: Check the certificate paths for the web server and the database connection settings, including whether PostgreSQL or MariaDB verifies the server certificate rather than accepting any certificate.
- Renewal and revocation: Ask how certificates are renewed before expiry, how revocation is handled without online OCSP or CRL endpoints, and who is alerted when a certificate is close to expiring.
- Key custody: Confirm where the CA private key is stored, who can sign with it, and whether signing happens on an offline host with logged access.
Ask the partner to demonstrate a full chain validation from a client machine with no internet route, and to show the renewal runbook applied to one certificate.
Antivirus scanning of uploads only works when the signature database is current, and an offline enclave gets no automatic definition updates. Nextcloud All-in-One bundles ClamAV, which is a practical reference point for the design, but the same logic applies to any scanner: definitions must be fetched on a connected system, verified, transferred across the boundary and loaded on a schedule that the organization documents. A scanner that runs on stale definitions gives a false sense of coverage, so the refresh cadence and the age check are as important as the scanner itself.
- Definition source and transfer: Ask how signature files are downloaded outside the enclave, what checksum or signature verification is applied, and which removable media or transfer path carries them in.
- Refresh cadence: Ask for the documented interval between definition updates and the alert that fires when the database age exceeds that interval.
- Scanner integration: Check that uploads are scanned before they become visible to other users and that infected files are quarantined or blocked according to the policy.
- Scanner version control: Confirm how the scanner engine itself is updated, since engine and definition versions must stay compatible.
- Evidence of operation: Ask which logs show each scan, each definition load and each rejected file, and how long those logs are kept.
Ask the partner to show the definition age report and a test file being blocked after the definitions were loaded through the transfer path.
Federation and public share links are the two features most likely to send data outside the enclave, even when the network is isolated. Federated sharing lets one server exchange shares with another, and public links can be opened by anyone who holds the URL. In an air-gapped deployment both should be disabled or restricted to internal targets, and the configuration should be checked rather than assumed from the network design. The controls below should be verified on the running system, not only in the build document.
- Federation settings: Confirm that outbound and inbound federated sharing are disabled in the server configuration and that no remote server list is populated.
- Public link policy: Check whether public link creation is disabled for all groups or limited, and whether link passwords and expiry are enforced where links remain.
- Outbound connectivity checks: Ask the partner to show the firewall or network policy that blocks outbound connections from the application and sync hosts, and how blocked attempts are logged.
- Apps and integrations: Review any app that calls an external service, such as a connector, mail provider or update check, and confirm each is disabled or pointed at an internal endpoint.
- Configuration baseline: Ask for a versioned baseline of these settings, with a periodic comparison against the running configuration.
Ask the partner to demonstrate an attempted public link creation and an attempted federated share, and to show the log entries and the firewall rule that stop the outbound call.
How to carry Nextcloud upgrades across the gap one major version at a time
Nextcloud does not allow skipping major releases, so an air-gapped enclave cannot jump from an old version to the current one in a single step. Every move is a sequence: stage the next major release on the transfer side, verify it, back up the enclave, run the upgrade, confirm the instance is healthy, and only then start the next step. Nextcloud's upgrade documentation also asks administrators to disable third-party apps until each one is confirmed compatible with the target version, so the app inventory for every hop needs its own check. Plan the number of hops before the first transfer, because each hop adds a verification and change window.
The release schedule sets the pace. 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, Nextcloud 33 until February 2027, and Nextcloud 36 (Hub 27 Winter) is scheduled for 17 February 2027. An enclave that receives media on a fixed cycle will fall behind quickly, so the sync-to-enclave schedule should be set against these end-of-support dates, with a decision on which major version the enclave will run at each transfer. Confirm with the vendor and your own change board how long the window between a release and an enclave upgrade must be, and whether an interim version is needed to stay supported.
Support tier decides how much of this burden you carry. Nextcloud's pricing page describes Standard as including one year of maintenance, while Premium adds a maintenance lifecycle of five or more years. Ask for the maintenance lifecycle in writing for the exact version you plan to run, and check whether security patches for air-gapped installs arrive as offline packages that your team must verify before carrying across. The Nextcloud pricing page is the starting point for comparing tiers, and the quote should state who performs each hop, who tests apps, and who owns rollback.
Which open-source platforms fit an air-gapped file sharing build
An air-gapped file sharing build depends on three things: a server platform that can be installed and upgraded from media you carry across the boundary, an office editing layer that must move through the same process, and a license and support model that fits your change control. The cards below cover the server options and the editing layer, with the air-gapped questions to settle before choosing an edition.
Nextcloud Server community edition
Nextcloud Server is licensed under AGPL-3.0, which costs nothing to download but leaves the operating burden with your team or your implementation partner. Offline, every release, app update and security fix must be packaged, checked against the software integrity requirements in your supplier process, and imported through your own repository. Confirm which installation method your partner will use, whether the update process is scripted for offline use, and how third-party apps are vetted before they are carried across the gap, since the upgrade documentation asks you to disable them until they are confirmed compatible.
Nextcloud Enterprise subscription
Nextcloud GmbH sells Nextcloud Enterprise alongside the community version, aimed at enterprise, public sector and education users. The supplied pricing facts list Standard, Premium and Ultimate tiers with a 100-user minimum, and the tiers differ in maintenance lifecycle, support hours and response times. For an air-gapped build, the question is whether the subscription includes offline update packages and support that works without a connection to Nextcloud's systems, and whether the maintenance lifecycle outlasts the major versions you plan to run. Ask for the tier comparison in writing before you assume it covers your air-gapped support model.
Seafile server
Seafile is released under GPLv2 with an additional permission to link with OpenSSL, and offers a simpler sync and share model than Nextcloud. It suits smaller footprints where file sync, libraries and sharing are the main requirement and the workplace does not need a broad app ecosystem. Before choosing it for an isolated network, confirm how the edition you select packages server and client updates for offline installation, how it integrates with your directory and certificate authority, and whether its feature set covers the office editing, audit and retention needs in your requirements list.
ONLYOFFICE Docs for offline editing
ONLYOFFICE Docs is a browser-based office suite compatible with Office Open XML formats, licensed under AGPL-3.0. In an air-gapped network it runs as a separate document server that the file sharing platform calls, so its container images, fonts and connector components must be carried across the boundary with the same care as the server itself. Confirm the exact connector version that matches your file sharing release, how the document server reaches the storage platform without internet access, and whether fonts and spell-check dictionaries are bundled offline.
How an air-gapped file sharing rollout is phased
The sequence moves a Nextcloud deployment from classified scope to a tested, offline-capable platform with a handed-over runbook, and each phase produces a document or test result the security and compliance teams can review. The order matters because the transfer procedure, certificate authority and update path decide how every later phase can be carried out.
Classify data and map the regulation
Define which data the enclave will hold, who may access it, and which regulations or contractual obligations apply, such as records retention, ePHI or CUI rules. The client's security and compliance leads sign off the scope, the data classification scheme and the list of controls each requirement maps to. The phase closes when the signed scope document names the users, data types, retention rules and the evidence each control needs.
Design the staging zone and transfer procedure
Design the one-way path by which software packages, container images, app bundles, antivirus signatures and operating system patches enter the enclave. Specify the staging host, the scanning and hashing steps, the approval record for each transfer, and who may move media across the boundary. The phase closes with a written transfer procedure and a test transfer that shows a package can be checked, approved and logged before it reaches the production network.
Build the base platform offline
Install the Nextcloud server, its database, web server, PHP runtime and caching services from offline media, and configure an internal certificate authority and a private container or package registry if the chosen deployment method uses one. The engineering team records every version and checksum in the bill of materials. The phase closes when the instance starts, serves HTTPS with certificates chained to the internal authority, and loads its components with no outbound network calls.
Integrate directory and single sign-on
Connect the platform to the enclave's directory using Nextcloud's LDAP or Active Directory integration, or to an OpenID Connect or SAML identity provider if the client runs one inside the enclave. Confirm that the identity provider or directory is reachable without internet access and that group membership drives access rules. The phase closes when test accounts from each group log in with directory credentials and receive only the permissions assigned to their group.
Set up antivirus and signature updates
Install the antivirus engine used for uploads and load its signature database from an offline update package that passed the transfer procedure. Document the cadence the client will use to bring new signatures across the boundary and who approves each import. The phase closes when a known test file is detected on upload, the signature version in use is recorded, and the update log shows how the last package was verified.
Disable federation and external sharing, then test
Turn off server-to-server federation, public link sharing where policy forbids it, and any app that calls an external service. Confirm the setting for each affected path and try each one from a test account to show that it is blocked. The security team reviews the results and signs a test record listing each disabled feature, the method used to verify it and the date of the test. The phase closes when no outbound or external sharing path succeeds in the tests.
Prove backup and restore inside the enclave
Configure backups of the data directory and database to storage inside the enclave, then restore the instance to a separate host. Compare file counts, checksums and a sample of user permissions against the source. The phase closes with a restore report that records the time taken, the items recovered and any gaps, so the client knows the recovery process works before production use.
Run the first offline upgrade on the one-major-version path
Take a backup, disable third-party apps that have not been confirmed compatible, and carry the next supported major release across the boundary through the staging procedure. Nextcloud does not allow skipping major releases, so each upgrade is a separate run with its own approval and test. The phase closes when the upgrade completes in a copy of the environment, the apps are re-enabled one at a time after checks, and the change record is filed.
Hand over the operations runbook
Deliver the runbook covering transfer and approval steps, certificate renewal, antivirus updates, backup and restore, upgrade sequence, access reviews and the evidence to keep for each. The client's operators run one routine task with the runbook while the partner observes. The phase closes when the client signs the handover acceptance and the evidence register is in place for the next assessment.
Evidence auditors and regulators ask for in an air-gapped deployment
This table lists the evidence items an assessor is likely to request for an air-gapped file sharing platform, what each item shows, and which component generates it. Use it to design logging, change control and package transfer records before go-live rather than reconstructing them later. DeployOpen prepares this evidence, while independent auditors and certification bodies decide whether it meets the applicable requirement.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| File access audit log | Who opened, downloaded, shared or deleted each file, with timestamps, for systems holding ePHI (HIPAA 164.312(b)) | Nextcloud audit logging app, forwarded to a local SIEM or log store inside the enclave |
| Transmission security configuration | TLS settings and internal CA chain used for all client and server connections (HIPAA 164.312(e)(1)) | Web server and Nextcloud config export, plus internal CA certificate inventory |
| Package transfer log | Each offline installer, app or signature file that crossed the boundary, with source, date and approver | Transfer register kept by the operations team, linked to the media ID |
| Hash and signature verification records | Checksums or signatures checked for every package before import, supporting software integrity review (NERC CIP-013-2 style) | Verification script output and signed record stored with the transfer log |
| Upgrade change records | Evidence that each upgrade moved one major version at a time, with a pre-upgrade backup and compatibility check of disabled third-party apps | Change tickets, Nextcloud upgrade output and backup job reports |
| Backup and restore test results | Proof that a backup existed before each upgrade and that restores were tested, not only scheduled | Backup tool job logs and restore test reports from the backup platform |
| Retention settings for records | Retention periods applied to communications or records where the three-year rule under SEC 17a-4(b)(4) applies, confirmed with counsel | Retention policy configuration and retention rule export from the platform |
| Federation disabled configuration export | Settings showing external federation and outbound sharing to other servers are turned off | Nextcloud configuration export (config.php and federation app status) captured after each change |
What do buyers ask before running file sharing with no internet access?
How much more effort does an air-gapped build add compared with a connected one?
An air-gapped build adds work at every point where a connected install would simply download something, so the extra effort sits in packaging, transfer and verification rather than in the application itself. Each container image, PHP and database dependency, Nextcloud app and antivirus signature set has to be collected on a connected staging network, checked, moved across the boundary and loaded into internal repositories. The effort also repeats with every maintenance release, not once at install. Ask any partner to break its estimate into the initial build and the recurring update cycle, and to show which steps are manual and which are scripted. The size of the gap depends on how many components your chosen deployment method pulls at runtime, so confirm that list in the written scope before agreeing a timeline.
What actually drives the cost of an air-gapped file sharing platform?
Cost is driven by four components: the transfer process, the internal registry or mirror, the support edition and the upgrade cadence. The transfer process covers how media or a data diode moves artifacts, and how each package is scanned and signed before it crosses. The registry or mirror is the internal store for container images, package repositories and antivirus signatures, which needs its own hosting and patching. The support edition decides who provides security fixes and offline assistance, and some vendors reserve air-gapped features for paid tiers. Nextcloud Enterprise, for example, is sold per user per year with a 100-user minimum, according to the vendor's pricing page. The upgrade cadence adds recurring work because Nextcloud releases a new major version every four months. Request each of these as a separate line in the quote.
Can our team run an air-gapped file sharing platform without a partner?
Your team can run it without a partner if it already operates Linux servers, a PHP and database stack, directory integration and a formal change process, and has staff to repeat the transfer workflow every cycle. The skills gap usually appears in three places: rebuilding the offline bundle after each release, validating third-party apps and keeping an internal certificate authority and antivirus signature feed current. Nextcloud requires you to upgrade one major version at a time, back up before every upgrade and disable third-party apps until they are confirmed compatible, so the upgrade runbook has to be followed exactly. Assess your staff against those tasks, and consider a fixed-scope engagement for the first build with a written handover, so the internal team owns the recurring cycle.
How long does it take to plan the first upgrade cycle across the gap?
Planning the first upgrade cycle depends on which major version you start from and how far behind the current release you are, because Nextcloud forbids skipping major releases. Nextcloud 35 (Hub 26 Summer) was released on 16 September 2026 with end of life in September 2027, Nextcloud 34 is supported until June 2027 and Nextcloud 33 until February 2027. Nextcloud 36 (Hub 27 Winter) is scheduled for 17 February 2027. A deployment on Nextcloud 33 therefore faces a 36 upgrade window that is short relative to the release calendar, so plan the route through 34 and 35 before the 33 support date. Confirm the sequence, the staging capacity and the approval dates with your partner and your change board in the written scope.
What does the work need from our organization before it can start?
The work needs four inputs from your side before a build can start. Network zones must be defined, including which segment hosts the platform, which hosts the staging network and how transfer media or a diode crosses between them. Your change process must approve each release bundle, because every upgrade is a controlled change in an isolated environment. Directory access is required so LDAP or Active Directory accounts can be tested, and Nextcloud documents LDAP, OpenID Connect and SAML backends you can choose between. Data owners must confirm retention rules, encryption requirements and who may hold restore rights. Ask your partner to list these inputs with named owners and due dates in the statement of work.
Do support editions include offline updates for air-gapped deployments?
Support editions vary, and you should confirm the offline update terms in writing rather than assume them. Nextcloud sells Enterprise in Standard, Premium and Ultimate tiers, and according to its pricing page Standard includes one year of maintenance, while Premium adds a lifecycle of five or more years and clustered instance support. Other vendors reserve air-gapped deployment for paid editions: Mattermost lists it in Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Element offers a Sovereign edition for air-gapped use. Ask the vendor whether security releases are delivered as offline bundles, how long they remain available, and whether your partner can package them for your transfer process.
What should an air-gapped build verify before accepting a package?
Each package should be checked for integrity and provenance before it crosses the boundary, and the record of those checks should be kept. The control logic comes from NERC CIP-013-2, which expects supply chain processes to address verification of software integrity and authenticity for vendor software and patches, and it is a useful model even outside the energy sector. In practice, this means verifying published checksums and signatures, scanning images and packages, and logging who approved each transfer. Antivirus signature updates follow the same path, so the signature source and its timestamp should be part of the record. Ask your partner to show this workflow as a documented procedure with evidence output.
Which parts of the air-gapped design should we confirm in the written scope?
The written scope should state the deployment method, the list of components pulled from outside, the offline update procedure, and the handling of external federation and sharing. Confirm how the internal certificate authority is issued and rotated, how antivirus signatures reach the platform, and how external federation is disabled and tested. Confirm the backup target and restore test, since an air-gapped system still needs recoverable copies. Also confirm which Nextcloud components are installed in the first phase and which are deferred, because third-party apps must be disabled until they are confirmed compatible. A specific list of these items gives you a basis for comparing partner quotes.
What to ask an implementation partner for an air-gapped build
Start with the transfer process, because it is where an air-gapped build most often fails. Ask the partner to describe, step by step, how every package, container image, Nextcloud release and app archive is produced on the connected side, moved across the boundary and verified on the enclave side. Ask which checksums or signatures they verify before import, where those values are recorded, and who signs off each transfer. Ask how third-party apps are handled: whether they are pulled only from sources you approve, whether each one is reviewed for compatibility with the target Nextcloud major version, and how an app update is held back when a review fails. Ask how antivirus signature updates for ClamAV are delivered, how often, and what the enclave does when a signature set is older than your policy allows. These answers should map to the software integrity expectations in NERC CIP-013-2 if you operate in that sector, and to your own change control if you do not.
Next, ask for the upgrade path written against the published calendar. Nextcloud does not allow skipping major releases, so ask the partner to show, for your target version, each intermediate major version in order, the date each one reaches end of life, and the window in which the enclave can complete the step. Ask how they plan around the support calendar in the Nextcloud maintenance and release schedule, which versions they will run during a transition, and what they do when a monthly maintenance release lands during a gap that cannot be closed quickly. Ask for evidence of the assessor pack: the configuration baseline, the transfer log, the upgrade records, the backup records and the support tier that covers each one. Confirm in writing which support tier includes offline patch delivery, response times, and who answers when a critical fix must cross the gap, because the Nextcloud Standard, Premium and Ultimate tiers differ on maintenance lifecycle and support hours.
Finally, ask the partner to demonstrate a restore inside the enclave before you accept the build. Specify the test: restore the most recent full backup to a separate instance with no network route to the connected side, bring up the database and the data directory, confirm that users can log in through your directory, and confirm that a sample of files matches their recorded checksums. Ask them to record elapsed time and any manual steps, and to hand over the runbook that a staff member, not the partner, could follow. Ask whether the restore includes the encryption keys and the configuration, and how those are stored apart from the backup. Confirm the restore target you need in your own recovery objectives before the test, since the partner cannot know your tolerance for data loss or downtime.
How DeployOpen scopes and supports air-gapped file sharing
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For file sharing, that means agreeing the scope in writing first, building the offline install and update path, and handing over the runbooks and evidence the operations team needs to run the platform across the gap.
How we scope
- Written scope lists the Nextcloud or Seafile version, user counts, storage targets and the networks that hold the platform
- Inventory of every offline dependency: container images, PHP packages, apps, office editing and antivirus signatures
- Agreed upgrade path that moves one major version at a time, with the release calendar mapped to the client's change windows
How we build
- Offline installation from a verified transfer bundle, with an internal certificate authority and internal update channels
- Antivirus signature updates and external federation disabled as configured controls, tested before go-live
- Staging environment that rehearses each major upgrade, including backup, restore and third-party app compatibility checks
How we hand over
- Runbooks for offline bundle import, integrity checks on each package and rollback during a failed upgrade
- Configuration records and control mapping that the client's assessors can review alongside their own evidence
- Operator training for administrators on the transfer procedure, backup restore and access review tasks
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build
- Support covers the monthly maintenance cadence and the planned major upgrades within the agreed scope
- Security testing of the deployed platform and its update path can be added to the retainer as the environment changes
