Products › VDI
Virtual Desktop Infrastructure
A co-equal focus area alongside RDP and Proxmox — currently in development, release timing tied to revenue from the foundation products
Wayland-native VDI for Linux infrastructure
Virtual Desktop Infrastructure is a different product class from remote desktop sharing. RDP shares an existing desktop session that’s already running. VDI creates virtual desktop sessions on demand — headless on the server, materialized only when a client connects, broker-managed, multi-user, designed for fleet operation.
Lamco’s VDI focus area is co-equal with RDP and Proxmox — not a sub-category of either, even though it builds on the same Wayland-native foundations. The anchor product, Lamco-vdi, is a headless Smithay-based compositor with a custom QUIC + AV1 transport, designed to fill the gap left by the recent collapse of independent open-source Linux VDI options.
See the RDP focus area for desktop sharing, and the Proxmox focus area for VM access — those handle different problems. VDI is the headless multi-user layer above them.
Why this isn’t the same as RDP Server
Different problem; different architecture. The product line distinction matters for procurement.
Lamco RDP Server (desktop sharing)
- — Connects to a running Linux desktop session and shares it
- — Single user / single session per host
- — Requires a Wayland compositor already running
- — RDP wire protocol — native Windows clients work
- — H.264 / H.265 / AV1 via VA-API / NVENC
- — Use case: remote-access an admin’s workstation, support a user, demo a desktop
Lamco-vdi (virtual desktop infrastructure)
- — Creates virtual desktops on demand — headless server, no host desktop required
- — Multi-user, broker-managed session pool
- — Custom Smithay-based compositor written for headless operation
- — QUIC custom wire protocol, not RDP — thin clients use Lamco client app
- — AV1-first encoding with budget-aware resource management
- — Use case: enterprise VDI fleet, education labs, contractor desktops, ephemeral workstations
The independent Linux-VDI market collapsed
Direct verifiable observations from the open-source / SMB Linux-VDI landscape, 2023–2026.
FlexVDI — defunct
Founded 2015, KVM-optimized VDI from Zaragoza. Ceased operations October 2023. Community confirmed dead.
Deskpool — defunct
Open-source VDI broker for Proxmox/oVirt. No longer maintained.
UDS Enterprise — expensive
~€78/concurrent user/year. Functional but heavy UI, X11-only on Linux guests.
KASM — container-only
Container-focused remote desktops. Different model than full-VM VDI.
PVE-VDIClient — SPICE-only
Proxmox-focused, locked to SPICE protocol. No RDP/QUIC, no Wayland-native.
Citrix / Omnissa / DCV — X11-only on Linux
Every commercial Linux VDI requires X11 sessions. Wayland is unsupported across the major vendors.
The combination — viable independent VDI dying off, commercial vendors stuck on X11, VMware Horizon refugees fleeing 6× license increases — defines the gap Lamco-vdi targets.
Lamco-vdi at a glance
Distinct from Lamco RDP Server — ~85% incompatible architecture by design.
┌─────────────────────────────────────────────────────────────────┐
│ Thin clients │
│ Lamco VDI client app ─QUIC + AV1─▶ │
└──────────────────────────────────┬──────────────────────────────┘
│
┌──────────────────────────────────▼──────────────────────────────┐
│ Lamco-vdi server (per-host) │
│ ┌────────────────────────┐ ┌────────────────────────────┐ │
│ │ Session broker │ │ Budget-aware resource mgr │ │
│ │ • spawn / pool / kill │ │ • CPU / mem / GPU quotas │ │
│ │ • auth, idle reaper │ │ • Per-session encode tier │ │
│ └────────┬───────────────┘ └────────────────────────────┘ │
│ │ │
│ ┌────────▼───────────────────────────────────────────────┐ │
│ │ Headless Smithay compositor (one per session) │ │
│ │ • GLES rendering │ │
│ │ • In-process app surface, no DRM/KMS │ │
│ │ • Capture pipeline → AV1 encoder → QUIC stream │ │
│ └────────┬───────────────────────────────────────────────┘ │
│ │ │
│ ┌────────▼─────────────────┐ │
│ │ D-Bus management API │ ← shared with Lamco RDP Server │
│ └──────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
What’s shared with the rest of Lamco
- — D-Bus management interface (common control plane with Lamco RDP Server)
- — AV1 / VA-API encoding lessons from the RDP-server work
- — IronRDP contributions feed back when relevant (e.g. multi-codec, autodetect)
What’s deliberately different
- — Custom Smithay compositor (headless), not a regular desktop session
- — QUIC custom wire protocol, not RDP
- — AV1-first encoding pipeline; no need for H.264 backwards compatibility
- — No dependency on the published
lamco-*ecosystem crates today (codebase is standalone)
Lamstore as a possible storage layer
Open architectural question, not a committed direction.
VDI deployments need persistent per-user state — profile data, app config, sometimes user-installed software. The default answer is “mount a filesystem,” but at fleet scale that becomes a performance and atomicity problem (concurrent profile syncs, crash-safe writes, snapshot semantics, deduplication across thousands of similar desktops).
Lamstore — a separate Lamco research project on extent-based storage with hardware-atomic page writes — is being explored as a potential persistence layer for VDI, alongside conventional filesystem and CoW options. Its primary motivation is PostgreSQL atomic-write integration (eliminating Full Page Image writes), but the same extent-store + atomic-write primitives map cleanly to per-user VDI profile storage.
What “rearchitecting it as an option” would mean
- — Lamstore stays a standalone project with its own roadmap (PG integration first)
- — Lamco-vdi could optionally sit on top of Lamstore for per-user persistence at fleet scale
- — Conventional filesystem-backed deployment stays the default; Lamstore would be the high-end / large-fleet path
No commitment yet. The conversation is real, the integration shape is still open, and the storage layer is not the bottleneck for getting Lamco-vdi released. Listed here for completeness because the option exists and may inform future architecture.
Where this stands today
- Repository
- Private, not yet public. Lives in
lamco-vdi-dev. - Code state
- Architecture settled, most of the codebase written. Standalone — no dependencies on the published
lamco-*crates. - Release prerequisites
- Revenue from Layer 3 (Lamco RDP Server) and Layer 4 (Proxmox products) needs to be established first. VDI is Layer 5 in the company strategy — funded by the layers below it, not in parallel.
- Open questions
- Storage layer (Lamstore vs conventional FS), broker UI, licensing model, hosting / packaging story, Proxmox-specific integration shape.
- Why this page exists today
- VDI is a real focus area, not a future bullet point. The work is ongoing; the strategy depends on it. The page exists so the focus area is visibly co-equal with RDP and Proxmox — even though the product itself lands later.
Related focus areas & foundations
Foundation product line. Revenue from RDP funds VDI development; encoding and protocol lessons feed back.
Co-equal focus area. Lamco-vdi’s primary deployment target on PVE clusters — tight integration planned.
Open-source Wayland capture / video pipeline. Lamco-vdi may adopt these as the standalone codebase consolidates.