Keep Your Office PCs. Centralize Their Storage.
Your office PCs keep running Windows or Linux on their own processor, memory and graphics card. Their system disks move into distributed storage that Nodekeeper manages: one shared base image, a separate writable disk for each PC, and recovery points you can roll back to.
You don't have to turn every desk into a remote-desktop seat first. Network-boot supported PCs, keep each user's changes separate, and manage capacity and recovery from one panel.
- x86_64 PCs, BIOS or UEFI
- Windows 10 / 11 · Debian 13 · Ubuntu 24.04
- PCs boot from storage at their own site
- Included in Business
Six office problems, and what changes
Each card states the benefit first and then the one condition that matters most. The full list of tested systems and limits is in the support matrix.
Allocate capacity from one pool
Disks are thin-provisioned in a central distributed storage pool and counted against a quota, so space is used as data is written. The pool grows by adding disks or hosts to the cluster, not by replacing the drive in every PC.
Good to know: choose each PC's disk size when you create it. Resizing an existing cloud PC disk is not a documented workflow yet. Windows extends C: to the full disk on first boot.
Share one base image, keep changes separate
A template version is stored once as a read-only snapshot. Each PC gets its own copy-on-write clone, so only that PC's own changes take extra space, and no two PCs write to the same disk.
Good to know: existing PCs stay on the template version they were created from. Publishing a new version does not upgrade them.
Roll back to a recovery point
Take snapshots by hand or on an hourly or daily schedule with a retention count, then roll a PC's disk back to one of them instead of rebuilding the PC.
Good to know: rollback needs the PC switched off and a 2FA confirmation.
Move the system disk off the desk
The system disk is not inside the PC. It lives in a replicated distributed storage pool that keeps copies on different disks, so a failed desktop drive no longer takes the system with it.
Good to know: this is not a backup, and work that was not yet written to disk is lost if a PC fails.
Manage several offices from one panel
Manage several offices from one panel over the NK mesh; each office boots its PCs from its own site.
Good to know: booting PCs from storage in another office, across a WAN, is not supported.
Keep local computing
PCs keep running the operating system and applications themselves. Only the disk is central, so the desktops you already have stay useful and nothing has to be streamed to the screen.
Good to know: Secure Boot must be off. Each Windows network card model needs a one-time warm-up before it can boot from the network.
How an office PC boots, and where its disk lives
Linux and Windows take different paths to the same storage. The diagram shows the deployment as Nodekeeper builds it. Nothing in it is a placeholder for a component the product does not have.
The boot, step by step
- The PC starts from the network (PXE) or from boot media (a USB stick or an ISO). Either way it loads an iPXE build signed by Nodekeeper.
- iPXE loads Nodekeeper's signed boot system, which shows a login screen: the user's cloud PC password, plus a one-time code if 2FA is on. The password is checked with SRP-6a, so the password itself is never sent.
- Linux PCs then map their own block disk straight from distributed storage and start.
- Windows PCs boot over iSCSI. A dedicated NK site node (VM or physical) serves iSCSI boot for Windows; Linux PCs map their block disk from distributed storage directly. Each session gets its own CHAP credentials.
- From then on the PC's own CPU, memory and graphics run everything. Only disk reads and writes go over the network.
Who does what
| Part | Its job | What it is not |
|---|---|---|
| PXE or boot media | Starts the PC and loads signed iPXE. | Not a storage protocol. Nothing runs from it after boot. |
| NK boot login | Checks the user before any disk is handed out. | Not a plain-text password prompt. |
| Site node | Serves the boot files and, for Windows, the system disk over iSCSI. | Not the retired iSCSI gateway built into the storage software. Today there is one per site, without automatic failover. |
| iSCSI | Block access to the Windows system disk. | Not encrypted: keep it on an isolated storage network. |
| Distributed block storage | Holds the template versions and every PC's own disk. | Not shared for writing: one writable disk per PC. |
| Distributed file storage | Cloud PC system disks are block devices on distributed storage; distributed file storage holds website storage and members' 'My storage'. | Windows PCs do not mount distributed file storage. |
Capacity: 100 PCs with 2 TB each
An office has 100 PCs. Some people need little more than the system and a few documents, others need a lot of working space. Giving every PC a 2 TB drive doesn't let unused space flow to the people who need it. With Nodekeeper, PC disks come out of central storage, are allocated as needed and grow with the cluster. Here, 2 TB means disk storage, not memory.
Four numbers that must not be mixed up
- Local disks today: 100 × 2 TB = 200 TB, mostly empty, and none of it can be shared.
- Allocated size: what each PC sees as its disk. Allocating 2 TB does not write 2 TB.
- Data actually stored: the shared base image, plus each PC's own new or changed data, plus whatever snapshots keep.
- Raw capacity to buy: the stored data times the redundancy (replicas), plus metadata and room for rebuilds.
All PCs use the same base image: base image B = 100 GB each PC's own data Δ = 100 GB number of PCs N = 100 Data today, no snapshot history yet: D = B + N × Δ = 100 + 100 × 100 = 10,100 GB = 10.1 TB Stored with three replicas: 10.1 × 3 = 30.3 TB Keeping normal use at 75 % of raw capacity (example only): 30.3 ÷ 0.75 = 40.4 TB
Not included: snapshot history, disk and pool metadata, extra template versions, allocation granularity, uneven data placement and operating headroom. The 75 % is an example, not a universal safety threshold for distributed storage: real headroom depends on failure domains and how fast you need to recover. The 200 TB of local disks had no redundancy at all, so this is not a "same reliability for less" comparison.
Keep in mind
- A bigger allocated disk does not create physical space. Watch the quotas, keep enough free space in the cluster and expand it by adding disks or hosts in time.
- A PC's own data is not only the files people save on purpose. Updates, caches and the page file count as well, so every clone grows with use.
- Snapshots keep old data and therefore take space. Their space counts against the owner's quota.
- Deleting files inside a PC does not necessarily free space in distributed storage right away.
- A new template version does not upgrade the PCs that were cloned from an older one.
- Erasure coding stores data at a theoretical factor of (k+m)/k, for example 1.5 for 4+2. Nodekeeper offers 2+1, 2+2, 4+2 and 8+3 profiles for data in distributed storage, but PC system disks are placed in replicated pools, as in the example.
- Nodekeeper has been tested with a handful of PCs, not with 100 at once. Size a real deployment with your own pilot.
Keep Scheduled Recovery Points. Recover to a Known State.
Snapshots are fast to create. We do not publish timings yet, and creating a recovery point is a different step from getting a PC back into use, which includes a restart.
What you get
- Manual snapshots, or a schedule (hourly or daily) with a retention count. Scheduled snapshots stay off until you switch them on.
- Roll a PC's disk back to a snapshot, or keep the current disk and save a snapshot as a new disk.
- Before every rollback Nodekeeper takes a snapshot of the current state automatically, so you can return to it. A snapshot is also taken automatically before a reinstall.
- Snapshots also cover block volumes in members' "My storage", file storage subvolumes and the disks of HA virtual machines.
What to expect
- Snapshots are crash-consistent: the disk is captured as if the power had been cut at that moment. No Windows VSS or guest agent is involved, so an application that was writing may need its own recovery.
- Rollback needs the PC switched off (or its session ended) and a 2FA confirmation.
- Rolling back discards everything written after that snapshot.
A recovery, as you would demonstrate it
- Create a recovery point.
- Make a deliberate test change on the PC.
- Shut the PC down.
- Roll back to the recovery point and confirm with 2FA.
- Boot the PC and check that the change is gone.
Replicas, snapshots and backups solve different problems
- Replicas protect against a failed disk in the cluster. They copy bad data just as faithfully as good data.
- Snapshots undo a bad update or a mistake on one PC. They live in the same cluster.
- Backups protect against losing the cluster itself. Nodekeeper's backup module covers websites, databases and the NK configuration. A backup of cloud PC disks to storage outside the cluster is not available yet.
What happens when something fails
Moving data off a single desktop drive reduces how much depends on one disk. How available the office is still depends on each part of the chain. This is how each one behaves today.
| What fails | What you can rely on | What not to expect |
|---|---|---|
| The PC's own drive | The system disk is not on it, so the PC network-boots as before. | Files that were only ever on the local drive are not protected. |
| The PC itself (mainboard, power supply) | The user logs in on another compatible PC. After the password (and code) are entered again, Nodekeeper moves the cloud PC there and cuts off the old machine. | Unsaved work on the old machine is lost. This is a new login on other hardware, not a transparent failover. A Windows PC needs a network card model that has been warmed up. |
| One disk in the distributed storage cluster | Data stays available from the remaining replicas, provided the pool's replica count and failure domains were planned for it. | Windows PCs can stop with a blue screen when a storage disk drops out, and then need a restart. |
| The site node | Linux PCs that are already running keep working: they talk to distributed storage directly. | Windows PCs lose their system disk until the site node is back or replaced, and no PC can start in the meantime. There is no automatic failover for the site node yet. |
| The network or a switch | Data already written to distributed storage stays where it is. | There is no offline mode. PCs that run from a network disk stop working, and Windows PCs stop with a blue screen. |
| A mistake, malware or ransomware | Roll the affected PC back to a snapshot from before the problem. Rollback needs 2FA. | Snapshots are in the same cluster and are not a backup. Replicas copy damaged data too. |
Connect Offices. Manage Storage and Recovery Together.
Being able to reach another office is not the same as running PCs from it. These four things are kept apart:
Management
One Nodekeeper panel for several offices, connected through the NK mesh, an encrypted network between NK nodes.
Boot and disk traffic
Stays inside each office: PCs boot from the site node and distributed storage cluster at their own site.
Where the copies are
In the distributed storage cluster of that site, laid out by its pools and failure domains.
Running from another office
Not supported for office PCs: booting from storage across a WAN is not a supported topology.
The mesh does not filter traffic between its members. If offices must be kept apart from each other, plan that separation yourself.
Support matrix
What has been tested, what is required and what is not available yet. First available in the November 2026 release, in Business and Enterprise builds.
| Terminals | x86_64 physical PCs. Virtual machines can be terminals too (tested with KVM VMs). ARM boards and Android devices are not available yet. |
|---|---|
| Boot | PXE, or boot media (USB stick or ISO). BIOS and UEFI. Secure Boot must be off, because the iPXE build is not signed by Microsoft. |
| Windows | Windows 10 and 11 (tested builds 26100 and 26300), BIOS and UEFI. Nodekeeper builds the template from your own licensed Windows ISO; Nodekeeper does not distribute Windows images. Each network card model and slot layout needs a one-time warm-up, or a matching entry in the network card library, so an unknown model is not zero-touch. Graphics drivers are yours to install. Windows Server is not supported as a template. |
| Linux | Debian 13 and Ubuntu 24.04 templates. Templates built offline from an ISO: Debian 13 only. Nodekeeper ships the kernel; booting your own kernel is not supported yet. |
| Data path at runtime | Linux: block device on distributed storage, mapped directly. Windows: iSCSI to the site node, which reads and writes the block device on distributed storage. CHAP credentials per session. iSCSI traffic is not encrypted, so it belongs on an isolated storage network. |
| Identity and separation | A cloud PC password per user (SRP-6a) plus an optional one-time code. One writable disk per PC; template versions are read-only. A cloud PC runs on one PC at a time; moving it to another PC needs the password again and cuts off the old machine. |
| Capacity | Thin-provisioned disks with a quota per owner. The pool grows by adding disks or hosts. Resizing an existing cloud PC disk is not a documented workflow yet. |
| Snapshots | Manual or scheduled (hourly or daily) with retention; off by default. Crash-consistent. Rollback with the PC off and 2FA; automatic snapshot before each rollback. |
| Availability | See what happens when something fails. The site node that serves Windows has no automatic failover yet. |
| Several offices | Managed together over the NK mesh. Each office boots from its own site. |
| Scale tested | A handful of PCs: an AMD desktop (Windows with BIOS and with UEFI, and Debian), an office PC connected through a USB network adapter, and KVM virtual machines as Windows UEFI terminals. No test with many PCs booting at once, and no 100-PC test. |
| Performance | No figures published. The only measurements so far come from a small lab cluster that was itself the bottleneck. |
| Licences | See plan and licensing. Windows and application licences are yours. |
Questions
Is this a virtual desktop?
No. Office PCs network-boot and run the system and applications on their own hardware. Only the system disk is central. Running desktops as virtual machines is a separate path, described on the cloud PC overview.
Do I need to buy thin clients?
Not necessarily. Existing x86_64 PCs work if they can boot from the network or from a USB stick, run with Secure Boot off and, for Windows, have a network card model that has been warmed up. Test a sample of your models first.
If 100 PCs each get a 2 TB disk, do I need 200 TB of storage?
No. Allocated size is not stored data. Plan from the base image, each PC's own writes, snapshot history, replicas and headroom, as in the capacity example. Storage can still fill up if PCs write more than planned, which is why quotas and free space need watching.
Do several people share one writable Windows disk?
No. They share a read-only template version. Every PC has its own writable clone, and a cloud PC runs on one PC at a time.
Are distributed file storage and iSCSI the same thing?
No. Distributed file storage is a file system. iSCSI gives Windows block access to its system disk through the site node. PC system disks are block-device images on distributed storage; distributed file storage is used for website storage and members' "My storage".
Can the PCs work without the network?
No. A PC that runs from a network disk needs the network and the storage while it runs. There is no offline mode.
Can snapshots replace backups?
No. Snapshots live in the same cluster as the disks. Use them to undo changes, and keep separate backups for the data you cannot lose.
Do you provide the PCs, servers, storage or Windows licences?
No. Nodekeeper is self-hosted management software. The PCs, servers, disks, network and the operating system and application licences are yours.
How are licences counted?
Nodekeeper is licensed per node, meaning each machine that runs Nodekeeper. Office PCs that network-boot do not run Nodekeeper. How site nodes and distributed storage hosts are counted in an office deployment is something to confirm with us before you buy.
Plan and licensing
The whole office workflow is in Business, with nothing to add: network boot, the site node with iSCSI for Windows, distributed storage deployment and management, templates and clones, quotas, snapshots and rollback, and the NK mesh between offices.
Per node means per machine that runs Nodekeeper. Ask us how site nodes and distributed storage hosts are counted for your office before buying.
Pro manages virtual machines but contains no cloud PC or distributed storage features, so it cannot run this workflow.
EnterpriseFor contract terms and larger deployments, contact sales.