[Back to blog](https://zcp.zsoftly.ca/blog)
 [Engineering](https://zcp.zsoftly.ca/blog/category/engineering)

# Why Use Private Desktops?

A business case for private employee desktops: controlled backend access from everyday employee devices.

Adjartey Odopey

September 23, 2026

· Updated October 14, 2026

8 min read

Share

![Private desktops: why we built them. ZCP cover with a KDE desktop connected to NFS shared storage and a network icon.](https://zcp.zsoftly.ca/images/blog/2026/why-we-built-private-employee-desktops.webp)

Conversations about employee desktops usually start with the laptop fleet. The business question is where controlled work happens. A private desktop can keep access to backend systems in a managed workspace while employees use familiar devices for meetings, email, and routine work.

We measured the tradeoffs by building an alternative: a private network, shared company file storage, and individual Ubuntu desktops. This series covers the business case, the cost, and the limits we found.

This is part 1 of a 3-part series. This post covers what we built, why, and who it fits. [Part 2 has the full cost breakdown against Windows 365](https://zcp.zsoftly.ca/blog/what-private-employee-desktops-cost), and [part 3 covers what we learned testing it](https://zcp.zsoftly.ca/blog/what-we-learned-testing-private-employee-desktops).

## The business case

A private, employee-only desktop is an option for teams that need controlled access to business systems without replacing every employee device. It fits work that does not need dedicated graphics performance or Windows-only applications. It also requires a video-call workaround, network testing, and shared-drive policy. This is an Ubuntu desktop. We tested a browser and a terminal session, not a specific list of business applications.

The case is not a lower monthly bill. A per-seat Cloud PC subscription beats our raw compute cost most of the time. Part 2 provides the full comparison. The business case is control over sizing, desktop software, access design, and cost visibility. Microsoft raised Business Standard pricing 12% in July 2026. This deployment uses Ubuntu, Headscale, and NFS for the employee workspace. The underlying platform is Apache CloudStack with a licensed management layer, so the full stack is not open source. The software running on the employee desktop is open source. These tradeoffs apply across team sizes and storage tiers.

Shared infrastructure for a whole team runs about $54 a month. Each employee desktop adds $62 to $128 a month depending on sizing, and the cost per employee drops as the team grows.

For decision-makers, these are useful starting points:

| Business need | Best starting point |
| --- | --- |
| Centralize sensitive data and source code instead of letting it live on laptops | Private network, shared storage, employee desktops |
| Distributed team without a flat, office-bound VPN | Mesh-secured private access for every employee |
| Avoid per-seat OS and productivity licensing costs | Open-source desktop, pay for infrastructure only |
| Already standardized on a Cloud PC subscription and its productivity suite | Not a swap, evaluate on data control, not price |
| GPU-heavy workloads (CAD, ML training, video editing) | Needs different sizing than tested here |

## What we built

Four parts work together: a private employee network, a secure access gateway, shared company storage, and one desktop per employee. The desktop and file-storage services are not exposed to the public internet by default. They also run without per-seat software licenses. Each VM has a public IP for administrator setup and recovery, restricted to one address. The secure access gateway is the exception. It keeps a second public port open because every employee device must reach the mesh coordination endpoint to join.

We ship this deployment pipeline through our own tutorials. We built it and tore it down repeatedly until every step held up.

## A practical split between everyday work and controlled access

One anonymous client workflow illustrates the model. Employees used Chromebooks or Chromeboxes for video meetings and ordinary business work. When they needed to reach backend systems with specific compliance requirements, they opened a KDE desktop running in the cloud. The everyday device stayed useful for communication, while the controlled workspace concentrated access to the systems that needed tighter handling.

In another common case, employees worked from desktops inside a client’s network because the client required backend systems to be reached through approved network paths. A remote desktop can support that policy, but the employee’s BYOD endpoint still sits outside the client network. Network location alone does not establish compliance or make a device trusted.

## BYOD with a managed workspace

Under a BYOD design, employees keep their own devices while IT manages the VM, including its patches, access rules, and permitted network connections. Central identity can reduce separate accounts and give IT one place to enforce authentication policy. The business must configure and integrate these controls for its workflow. The tutorial does not provide those integrations by default.

This pattern does not make an organization compliant by itself. The result depends on configured and tested controls around identity, MFA, access policies, file transfer, clipboard and drive redirection, logging, backups, retention, and offboarding. A managed VM gives a team a place to apply and review those controls instead of treating every employee laptop as the backend access point. Controls such as download restrictions or data-loss prevention need their own scope, configuration, and testing. They are not supplied by this tutorial by default.

The business risk is familiar. If a departing employee keeps an expensive organization device, the business may lose the hardware. Revoking remote access or deleting the cloud VM does not erase source code copied earlier to that device. A managed desktop gives the business a separate response: revoke the person’s remote access and remove the managed workspace. It does not recover the device or undo a prior copy, so access controls and offboarding still need to be designed before the employee leaves.

![KDE Plasma system information on an Ubuntu 24.04 desktop showing KDE Plasma 5.27.12, 4 vCPUs, and 15.6 GiB of memory.](https://zcp.zsoftly.ca/images/blog/2026/private-employee-desktop-kde-system.webp)

An Ubuntu 24.04 desktop running KDE Plasma, with 4 vCPUs and 15.6 GiB of memory.

## Where this helps the business

Business requirements usually drive this decision before technical preference does:

- Reduce the amount of source code and company data stored on laptops. The architecture centralizes the primary copy, but it does not block every transfer. A device on the mesh can mount the shared drive directly. A remote session can also move data through clipboard sync or local-drive redirection unless the business configures and enforces controls for those features.
- Keep every desktop and the storage it uses reachable only by your own team. We never expose RDP and the file share publicly, and we lock the one public IP each of those VMs carries to administrator access only. The one exception, by design, is the mesh coordination server’s own public port, covered above.
- Run on open-source software instead of paying for per-seat desktop or VDI licensing.
- Support a distributed team without the all-or-nothing, office-bound VPN model traditional setups assume.
- Make infrastructure costs visible as shared services and per-employee desktops instead of a single per-seat SaaS subscription.

Infrastructure built once and reused for each employee centralizes the primary copy of company data. That benefit depends on the controls described above. It does not prevent data from leaving a laptop.

## The decision framework

A team handling no sensitive data, fully in-office, is still better off on traditional laptops. This architecture solves a problem that team does not have.

A distributed team handling sensitive data and evaluating VDI licensing costs is exactly who this is built for.

A team needing GPU-heavy desktop workloads (CAD, ML training, video editing) needs different sizing than what is tested here. Treat this as a starting point, not a direct match.

A team dependent on Windows-only applications needs its own compatibility check. This is an Ubuntu desktop, and we tested a browser and a terminal session, not a specific application list.

## Decide with a small pilot

1. What company data and source code would move onto this infrastructure?
2. Which employees need distributed, off-site access, and which are fully in-office?
3. Is the team already paying for a hyperscaler Cloud PC subscription and its productivity suite, or deciding fresh?
4. Does any workload need dedicated GPU performance, such as CAD, ML training, or video editing?
5. Who owns onboarding, offboarding, and backup once this is running?
6. Which identity, MFA, logging, clipboard, download, and local-drive controls must be configured and tested for the workflow?
7. Does the business need file-level privacy between employees, or is a shared team drive acceptable?
8. What is the per-employee budget, including endpoint replacement, operations, and the controls the business needs?
9. How will the team handle video calls, given they do not perform well inside the remote session?
10. Did the team test the network path from every location employees connect from? The gap between a direct and a relayed connection is real enough to matter.
11. Does offboarding revoke a departing employee’s own device from the mesh, or does it only delete their desktop?
12. Does the team depend on any Windows-only application? This is an Ubuntu desktop, tested with a browser and a terminal, not against a specific application list.

Start with one or two people who need backend access, while they keep using their existing devices for meetings and routine work. Confirm the application fit, network path, file-transfer controls, logging, backup, and offboarding process before expanding the rollout.

## Get started

This is part 1 of a 3-part series on private employee desktops on ZCP. [Part 2 breaks down the full cost](https://zcp.zsoftly.ca/blog/what-private-employee-desktops-cost), including a direct comparison against Windows 365. [Part 3 covers what we learned testing it](https://zcp.zsoftly.ca/blog/what-we-learned-testing-private-employee-desktops), including the real limitations.

[Talk to us](https://zcp.zsoftly.ca/contact) about whether this fits your team, or walk through the [technical tutorial series](https://docs.zcp.zsoftly.ca/tutorials) to see every tested step.

## Related articles

Engineering

October 11, 2026

### [The Restart That Hid a Libvirt Bug](https://zcp.zsoftly.ca/blog/the-restart-that-hid-a-libvirt-bug)

A seven-minute VM create, two wrong turns, a self-healing timer I built and then deleted, and the package update that fixed it.

Engineering

October 5, 2026

### [Private Desktops: Lessons from Testing](https://zcp.zsoftly.ca/blog/what-we-learned-testing-private-employee-desktops)

What to test before a private desktop rollout: daily work, video calls, network paths, storage, and offboarding.

Engineering

September 29, 2026

### [What Do Private Desktops Cost?](https://zcp.zsoftly.ca/blog/what-private-employee-desktops-cost)

Compare private desktop costs: shared services, per-person workspaces, and Windows 365 pricing.