Self-hosted Miro alternative for air-gapped networks

Can a self-hosted Miro alternative run in an air-gapped network?

Yes, with conditions. A team that cannot send board content to a cloud service can run Nextcloud Whiteboard or Excalidraw on its own servers without internet access, provided it also deploys the collaboration server that live editing needs. Nextcloud Whiteboard is built on Excalidraw and stores boards in Nextcloud, but it relies on a separate websocket server for real-time collaboration, so that component must be installed, configured and reachable inside the closed network. Excalidraw's collaboration layer is the MIT-licensed excalidraw-room server, which the team hosts itself. Plan for both pieces, not just the front end.

Miro's data residency options do not change this picture. Miro offers EU residency on all plans, with Ireland as the primary and Germany as the backup data center, and US, Australian and Japanese residency only on the Enterprise plan. These are regions of Miro's hosted service. Choosing a region keeps data in that jurisdiction, but the boards still live on Miro's infrastructure and depend on its connectivity. A network with no outbound path to that service cannot use Miro at all, regardless of region. Confirm this with Miro's account team against your own network rules before assuming otherwise.

Before committing, confirm three things in your own environment: which components of the whiteboard stack are supported for offline installation, how the team will move Nextcloud and its database to new versions without internet access (Nextcloud does not allow skipping major releases), and how every package and container image will be verified before it crosses the boundary. For closed networks that fall under NERC CIP-013-2, the procurement process must address software integrity and authenticity, so write that check into the update procedure from the start.

What an air-gapped whiteboard must satisfy

An air-gapped whiteboard has to work with no route to a vendor cloud, install and update from media that crosses the boundary once and is checked, and keep live collaboration inside the boundary. Each requirement below changes what happens to board content, to users and to the people who maintain the system.

No calls to a vendor cloud

The whiteboard must run with zero outbound dependencies. Excalidraw's excalidraw.com app is a hosted service, so an air-gapped team runs the Excalidraw front end and its collaboration server on its own hosts instead. Nextcloud Whiteboard stores boards inside the Nextcloud instance, so board content never leaves the organization's servers. Check every feature for hidden calls to external fonts, analytics, image proxies or sharing services, and test with egress blocked before go-live.

Offline installation from vetted media

Installing and updating must work without internet access. Nextcloud Server documents its own release and upgrade path, but the container images, npm packages and collaboration server code all have to be mirrored into the closed network first. Ask who builds the offline bundle, where it is stored and how each artifact is hashed and approved before it is imported.

Collaboration server inside the boundary

Live editing needs a real-time server that the users' browsers can reach. Nextcloud Whiteboard needs its own websocket server alongside Nextcloud, and standalone Excalidraw uses excalidraw-room, which is MIT licensed. Both must run on internal hosts with internal certificates and internal DNS. Confirm that the websocket endpoint, storage and TLS chain resolve without any public name or certificate authority lookup.

Screened software crossing the boundary

Every package, image and patch carried across an isolated network is a supply chain entry point. For regulated energy sites, NERC CIP-013-2 requires procurement processes that address verification of software integrity and authenticity, which is the kind of control that applies to whiteboard updates. Record the source, checksum and signature of each import, scan it, and keep the approval record with the change ticket. Other sectors may set similar expectations, so confirm them with your own assessor.

Board content and user access stay local

Because boards are stored in the local database and file store, backup, retention and deletion are the organization's responsibility. Users should sign in through the internal directory, which Nextcloud supports through its LDAP app and documented OpenID Connect and SAML backends. Confirm who can export boards, where exported files go and how removed users lose access to their boards.

Where Miro's residency options stop short of an air gap

Miro's data residency options answer one question: where customer data is stored. Miro offers EU data residency on all plans, with Ireland as the primary data center and Germany as the backup, while US, Australian and Japanese residency is available only on the Enterprise plan, according to the Miro help center. Those regions are still Miro's hosted cloud. Your users reach boards through Miro's service over the internet, and your organization does not run the platform inside its own network. A residency setting therefore does not make a board usable in a closed network.

Residency also says nothing about whether the network can run without internet access. A workshop can be fully compliant on paper for data location and still fail the moment the network boundary blocks outbound traffic to the vendor. For regulated environments, the questions are different: can the application be installed and operated with no outbound connection, how are updates and license checks handled offline, and who holds the keys to the service. Treat the residency page as a data location statement and write those operational questions separately.

Before you rule Miro in or out for an isolated network, ask Miro in writing whether any offline, self-managed or customer-hosted deployment exists under your contract, and what that would cost to operate. Get the answer tied to your plan and region, because the residency options above depend on the tier. If the answer is no, the practical path is a self-hosted application such as Nextcloud Whiteboard or Excalidraw, where you control installation, updates and the collaboration service. Confirm each of those points with your own security team before planning the rollout.

Nextcloud Whiteboard or Excalidraw: which fits the closed network

Nextcloud Whiteboard is the official whiteboard app for Nextcloud, built on Excalidraw and licensed under AGPL-3.0. Boards are stored inside Nextcloud, so they sit with your files, permissions and existing backups. Live multi-user editing is different: the app needs a separate websocket server running next to Nextcloud, which means one more service to install, configure, certify internally and patch in the closed network.

Board storage: boards live in Nextcloud, so access follows Nextcloud users, groups and shares.
Websocket server: a separate component handles live collaboration and must be deployed and reachable inside the network.
Single-user use: opening and editing a board does not depend on the internet, once the app and its assets are installed.
Excalidraw collaboration server: excalidraw-room is a separate MIT-licensed server, and you run it yourself if you choose the standalone route.
Operations: each extra service adds upgrade, monitoring and backup work.

Confirm with DeployOpen or the Nextcloud Whiteboard documentation exactly which services a live session requires, and test the websocket path between user segments before you commit.

How to deploy the chosen option inside a closed network

This sequence moves a tested Nextcloud Whiteboard or Excalidraw stack across the boundary, installs it on supported components, connects it to your directory and sets an upgrade routine that your team can repeat without internet access.

Build the offline package set on staging
On a connected staging network, your team or DeployOpen collects the Nextcloud Server release, the Nextcloud Whiteboard app, the Excalidraw collaboration server (excalidraw-room), the database, PHP and web server packages, and container images if you use them. Record every version and checksum in a manifest. Confirm the exact component versions against the Nextcloud 35 system requirements and the Whiteboard repository before you pull anything, because the supported database and PHP ranges are what the install depends on. The step is complete when the manifest lists every artifact with a version and hash.
Scan and verify every artifact
Run malware and vulnerability scans on each package and image, and verify signatures or published checksums against the upstream projects. Keep the scan reports with the manifest, since your change records and supply chain controls will ask how each item entered the closed network. Hold back anything that fails verification or has an unresolved critical finding. This matches the supply chain expectation in NERC CIP-013-2 for verifying software integrity and authenticity, if that standard applies to you. The step is complete when each artifact has a passing scan and a verified hash recorded.
Transfer media across the boundary
Move the verified set across the boundary on media your security policy allows, under your own transfer procedure. Copy the manifest with the artifacts, then re-check hashes on the isolated side before anything is installed. Keep a second copy of the full set in case a later upgrade needs a rollback. The step is complete when hashes match on the closed network and the transfer record is signed off by the responsible owner.
Install Nextcloud with a supported stack
Install Nextcloud Server on a supported combination of PHP, database and web server from the system requirements, such as PostgreSQL or MariaDB with PHP and Apache or nginx with php-fpm. Nextcloud All-in-One can bundle its components, but check that its images are in your offline set first. Confirm that the instance loads in a browser from inside the network, that cron runs, and that file storage works. The step is complete when administrators can log in and the server reports no outstanding setup warnings.
Install Whiteboard and its collaboration server
Install the Nextcloud Whiteboard app from the offline package, then deploy the separate websocket collaboration server it needs for live editing, using the Excalidraw room server components in your package set. Point the app at the internal websocket address and confirm that two test users can edit the same board at once. Check that the boards are stored in Nextcloud and that no outbound connection is attempted during the test. The step is complete when live collaboration works between two browsers with internet access blocked.
Connect identity through your directory
Configure the LDAP app for Active Directory or LDAP so users sign in with directory credentials. If you run an OpenID Connect or SAML provider inside the network, configure that backend instead, and confirm the provider's certificates and redirect addresses resolve internally. Test a joiner, a mover and a leaver account, since offboarding must remove board access. The step is complete when a directory user signs in, sees the boards shared with them, and a disabled account is refused.
Set the upgrade routine
Write a runbook that upgrades one major Nextcloud version at a time, because Nextcloud does not allow skipping major releases. Before each upgrade, take a backup of the database and data directory, disable third-party apps, and confirm each app is compatible in the new version. Repeat the monthly maintenance releases from the same offline channel, and schedule a check of the release schedule so you know when your current major version leaves support. The step is complete when a test upgrade in a non-production copy runs from backup to a verified restore.
Add Kubernetes image pulls only if needed
If your team runs Kubernetes, use kubeadm config images list and kubeadm config images pull on the staging side to collect control plane images, then point kubeadm init at your private registry with the image repository flag. Skip this step on a single-server or Docker-based install. The step is complete when the cluster builds with no outbound pulls, or when you record that the step does not apply.

Keeping an offline whiteboard patched without internet access

Patching an air-gapped Nextcloud Whiteboard deployment is mostly a release planning problem. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases that fix known critical bugs and security problems, as described in the Nextcloud maintenance and release schedule. 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 is scheduled for 17 February 2027. Put these dates in your change calendar and confirm them against the schedule before each window, because a version you run today may leave support during a single accreditation cycle.

The most common mistake is falling behind by more than one major version. Nextcloud does not allow skipping major releases, so each jump must be made in sequence, one major version at a time. Back up before every upgrade, and disable third-party apps, including Whiteboard, until their maintainers confirm compatibility with the target release. Read the Nextcloud upgrade manual for the exact order, and budget for a gap in the sequence if an app lags behind the core release.

Bring updates across the boundary through a documented, one-way transfer. Download the release packages and the Whiteboard app on a connected system, verify their checksums and signatures against the publisher's values, and record the hashes in your change ticket. Move the verified artifacts on approved media, then install them first in a staging copy built from a recent backup of the production database and data directory. Run the upgrade, open several existing boards, test live collaboration with the separate websocket server, and check that Whiteboard still loads its Excalidraw assets before you touch production. Keep the staged copy until the next maintenance release is verified.

Questions buyers ask before moving boards off Miro

What does a self-hosted whiteboard rollout cost, and what drives it?

The software itself carries no license fee for Nextcloud Whiteboard or Excalidraw, so the cost is made of infrastructure, staff time, testing and support. Infrastructure covers servers or virtual machines inside the closed network, the Nextcloud server with its database, and the separate collaboration server that live sessions need. Staff time covers installation, access control, backups and upgrades. Testing and support are optional but depend on how many users depend on the boards. Ask any provider for a quote that lists these components separately, and identify which items are one-time (setup, migration) and which recur (hosting, maintenance, patch intake). Nextcloud Enterprise is the main licensed option: the Nextcloud pricing page lists Standard, Premium and Ultimate tiers with a 100-user minimum, starting at 71.29, 104.99 and 204.75 euros per user per year for 100 or more users.

How long does moving from Miro to an air-gapped whiteboard take?

The duration depends on scope: how many boards are kept, whether they are rebuilt or archived, how many users need access, and whether the closed network already has a database, identity service and backup target. A pilot with one team and a small set of boards is a different project from a company-wide rollout with directory integration. No timeline is fixed in advance. Agree a written schedule with the provider before work starts, and ask that it separate the build, the test environment, the cut-over and the training. Because Miro boards cannot be exported as an editable format, plan extra time for rebuilding the boards that matter and archiving the rest.

What does our team need to provide before the work starts?

Most of the inputs are internal decisions and access. Expect to provide the target hosting environment inside the closed network, a supported database such as PostgreSQL or MariaDB, a reverse proxy with TLS certificates, and a directory source if users should sign in with existing credentials. The LDAP app can connect Active Directory or LDAP users, and OpenID Connect and SAML are documented authentication options. You also need a named owner for the boards, a list of teams and their boards to keep, and an approved way to bring software packages and updates across the isolation boundary. Confirm each item against your own environment before the provider plans the build.

Can our own engineers run this without an outside provider?

Yes, if the team has Linux, web server, database and container skills and time for ongoing operations. Nextcloud All-in-One is the official installation method and bundles caching, PostgreSQL, backups and antivirus, which reduces the build effort. Upgrades still need planning: Nextcloud does not allow skipping major releases, so administrators must step through one major version at a time, back up before each upgrade and disable third-party apps until they are confirmed compatible. Teams that lack this capacity often use an outside provider for installation, hardening and upgrade runbooks, or choose Nextcloud Enterprise support for vendor-backed maintenance.

What Miro features do we lose when boards move off-network?

The main losses are Miro's template library, its catalog of third-party integrations, its hosted versioning and its enterprise administration features, such as the audit and SCIM controls described on Miro's plan pages. Excalidraw and Nextcloud Whiteboard cover freehand sketching, shapes, shape libraries, PNG, SVG and clipboard export, and live collaboration in a closed network. Excalidraw saves an open .excalidraw JSON format, which is a practical advantage for keeping drawings editable. Nextcloud Whiteboard needs the separate collaboration server for live sessions, so verify that it runs inside the closed network. Check each Miro feature your teams use against this list before committing.

How do we keep the offline environment updated and patched?

Updates arrive as packages carried across the isolation boundary, so the process needs a documented intake step. Verify the integrity and origin of each package before it enters, as the NERC CIP-013-2 supply chain control expects for vendor software and patches where that standard applies. Nextcloud publishes a major release every four months, and each major version receives monthly maintenance releases for one year, so plan a recurring upgrade window. Confirm the current support dates on the Nextcloud maintenance and release schedule before setting the cadence.

Evidence assessors ask for from a closed-network whiteboard

A closed-network whiteboard is only as credible as the records behind it. The cards below cover the artifacts that show where the boundary sits, how the system was installed, what was carried across it, and how it is kept current and recoverable. DeployOpen prepares this evidence for your assessors, but it does not issue audit reports or attestations.

Architecture diagram with trust boundary

A diagram that shows the Nextcloud Whiteboard or Excalidraw collaboration server, the Nextcloud instance, the database, the identity provider and every path that crosses the air gap. It proves where the boundary sits and which components may talk to each other. Check that the diagram lists the websocket server Nextcloud Whiteboard needs for live collaboration, and that no outbound connection to a public service is drawn or allowed by firewall rules.

Offline installation record

A dated log of the install, with the exact versions of Nextcloud, the whiteboard app, the database, PHP and the web server, and the commands used. It shows the system was built without internet access and that the versions match the vendor's system requirements. Keep the record with the media that carried the installers, so an assessor can trace each component to its source.

Software bill and image verification log

An inventory of every package, container image and library that crossed the boundary, with its checksum or signature check and the result. It supports the supply chain expectations in NERC CIP-013-2 for verifying software integrity and authenticity. Record who approved each transfer, which media was used, and what was rejected, so that a later question about a single component has a documented answer.

Update and patch records

A log of each upgrade or patch applied inside the closed network, with the release used, the backup taken beforehand and the test result. Nextcloud releases a new major version every four months and supports each for one year, and it does not allow skipping major releases, so the log should show a planned sequence. Note any third-party apps that were disabled until confirmed compatible.

Backup and restore test results

Records of scheduled backups of the database, the file store and the whiteboard data, plus evidence that a restore was tested into a separate environment. A backup that has never been restored proves little. Record the restore time, the data checked after restore and any gaps found. Confirm that backup media is also stored inside the boundary or handled under your own media controls.

Access control records from the identity integration

Exports and configuration from the LDAP, Active Directory, OpenID Connect or SAML integration, showing which groups can sign in, which can create or delete boards, and how leavers are removed. These records show that access follows the directory rather than local accounts. Include the list of administrator accounts and the review date, and confirm that multi-factor authentication is enforced at the identity provider.

How DeployOpen deploys a whiteboard inside your network

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including closed networks. For air-gapped whiteboards, we agree the scope in writing first, then build the collaboration stack and its offline update path so each step can be checked by your own team.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
We map which boards, users and integrations must work offline and which Miro features are being given up.
We confirm your network zones, identity source, database choice and the Nextcloud release line you will run.

How we build

We install Nextcloud Whiteboard or Excalidraw with its collaboration server inside your closed network.
We prepare offline package and container bundles, and check each artifact's integrity before it crosses the boundary.
We harden the stack, test live collaboration and restore from backup, and record the results as evidence.

How we hand over

You receive architecture, configuration and runbook documentation written for your administrators.
We document the offline upgrade procedure, including one major version at a time and a backup before every upgrade.
We walk your team through backup, restore, user onboarding and the list of features that work only online.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover monthly maintenance review, offline update rehearsals and re-testing after each release.
Confirm with us in writing which support hours, response commitments and escalation paths the retainer includes.

Self-hosted Miro alternative for air-gapped and on-premises networks