Workstations
KARL Containerised Workstations
A desktop that exists only while somebody is using it, scheduled as a container and rebuilt from a signed image every session.
KARL replaces the VM-heavy desktop stack with Kubernetes-orchestrated workstation instances that exist only while a session is live. The desktop runs as a Karl Pod, the session streams to a low-cost endpoint over the LAN or a WAN link, and CPU, memory and GPU are bound on connect and released on disconnect. When an instance is compromised or drifts, it is not repaired. It is terminated and rescheduled from the signed base image. We deliver the full KARL capability set ourselves: sizing, deployment onto our own Karl and Ceph foundations, image build and update pipelines, identity integration through our own IAM, and day-two operation.
Delivered in partnership with KARL Technology, Italy, under their patented containerised workstation technology, WO2023/012553. Infinite Networks is the delivery and support layer: we scope, deploy, integrate and operate KARL on infrastructure we run, so everything KARL offers is available from us as a managed service rather than as a licence handover.
Delivery Model
One container per session, scheduled by Kubernetes, rather than a persistent virtual desktop
The Endpoint
A thin client or an existing desktop, carrying no state and no user data
Resource Behaviour
vCPU, memory and GPU bound at connect and released again at disconnect
Our Role
Sizing, deployment, image pipelines, identity and day-two operation, all run by us
Specification
Model
Container-per-session desktop, not persistent VDI
Orchestration
Karl Pods scheduled by Kubernetes, per session
Components
Karl Hypervisor, Pools, GPU, Snap, DaaS, RDP gateway
Endpoints
Thin clients or existing desktops as display and input
Allocation
vCPU, RAM and GPU bound on connect, freed on disconnect
Recovery
Terminate and reschedule from the signed base image
What You Get
Density Instead Of Overprovisioning
Resources are bound at session start and released at disconnect, so a floor of eighty desks is provisioned against concurrency rather than headcount. There are no eighty idle virtual machines holding committed memory overnight.
Compromise Means Rebuild
A suspect instance is terminated and rescheduled from the signed base image, so remediation is measured in seconds and the resulting desktop is provably the standard build. There is no long forensic repair of a machine nobody trusts any more.
Thin Endpoints, Real Desktops
The endpoint carries no state and no user data: it decodes a session and forwards keyboard, mouse and USB redirection. Existing desktops can serve as endpoints, so refresh cycles stop being a capital planning exercise.
Sits On Infrastructure You Own
Karl Pods land on the same Karl clusters and Ceph pools we deploy for virtualisation, and sign-on runs through our own identity layer over OIDC. The workstation layer is not a second estate with its own storage, identity and backup story.
How It Works
Five stages from a floor plan to a desktop that rebuilds itself. Concurrency drives the sizing throughout, not headcount.
Profile The Floor
We look at what people actually run, how many of them are signed in at the same time rather than how many are on the payroll, and which roles need a GPU. That concurrency figure is what the platform gets sized against.
Build The Image
Karl OS is assembled with your applications, drivers and policy into a signed base image. Every session starts from it, which makes the standard build something that boots rather than something written down in a document.
Land The Platform
Karl is deployed onto the same Karl clusters and Ceph foundations we already run, with Kubernetes scheduling the Karl Pods. Sign-on is wired to our own identity layer over OIDC rather than to a second directory.
Stream To Endpoints
The endpoint decodes the session and forwards keyboard, mouse and USB redirection, and nothing else. Existing desktops can serve as endpoints, so the rollout does not have to begin with a hardware purchase.
Rebuild, Not Repair
A drifted or suspect instance is terminated and rescheduled from the signed image. Updates ship as a new image version, so a change lands at the next connection rather than as a patch run across live desktops.
Against Traditional VDI
Both put the desktop in the data centre. What differs is what exists between sessions, and what that costs you to run.
Unit Of Delivery
- Traditional VDI
- A persistent virtual machine per user, running whether or not anyone is signed in
- KARL Workstations
- A container scheduled for the length of a session and destroyed at disconnect
Capacity Planning
- Traditional VDI
- Provisioned against headcount, because every user owns a machine of their own
- KARL Workstations
- Provisioned against concurrency, because resources are only bound while a session is live
Image Drift
- Traditional VDI
- Desktops diverge from the template over time and are patched in place afterwards
- KARL Workstations
- Every session boots the signed base image, so drift has nowhere to accumulate
Compromised Desktop
- Traditional VDI
- Isolate, investigate and repair a machine somebody still has to trust afterwards
- KARL Workstations
- Terminate and reschedule, so the replacement is provably the standard build
Endpoint Refresh
- Traditional VDI
- A capital cycle driven by desktops that have to run the operating system locally
- KARL Workstations
- Endpoints only decode a session, so existing hardware can keep serving as a terminal
Storage And Identity
- Traditional VDI
- Often a second estate with its own storage, backup and directory integration
- KARL Workstations
- The same Karl clusters and Ceph foundations, with sign-on through our own IAM
What We Need From You
A pilot can be scoped from these five. The awkward applications matter more than the common ones.
An Application Inventory
What each role runs, including the difficult entries: licence dongles, legacy clients, anything expecting a hardware key or a specific driver.
Concurrency Figures
How many people are signed in at the busiest point of the day, broken down by department. This is the number the platform is sized against, not headcount.
Endpoint Reality
What is on the desks now, roughly how old it is, and whether it can carry on as a terminal instead of being replaced during the rollout.
The Network Between Floors
The links between the endpoints and wherever the pods will run. Session streaming is sensitive to latency in a way that file sharing simply is not.
A Pilot Department
One real team doing real work. We measure session density and rebuild time against your applications rather than against a demo image.
Send the inventory and the concurrency figures and we will come back with a pilot scoped on one department, measured on your own applications.
Start An EnquiryQuestions About Workstations
What people ask once they realise this is not a virtual machine per desk.
No. VDI gives each user a persistent virtual machine that exists whether or not they are signed in. KARL schedules a container for the length of a session and destroys it at disconnect, so capacity is planned against concurrency and there is no long-lived desktop left to drift.
Profile and document storage is mounted into the session from persistent storage on the estate, kept separate from the disposable instance. The desktop is rebuilt every session; the data behind it is not touched.
GPU is one of the resources bound at session start and released at disconnect, so a design or analysis role can be given one without a card sitting idle overnight inside a tower under somebody's desk.
We do. KARL Technology holds the patented technology and builds the platform. Infinite Networks scopes, deploys, integrates and operates it on infrastructure we run, so the number you call is ours.
Updates land as a new signed image version. Running sessions finish on the version they started on and the next connection is scheduled onto the new one, so a rollout is a scheduling change rather than a maintenance window on every desk.
See KARL On Your Workload
We will scope a pilot on one real department and measure session density and rebuild time against your own applications, not a demo image.
Sales
- New servers, identity rollouts and workstation pilots
- Specifications, sizing and monthly pricing
- Moving an existing estate across to us
sales@infinite-networks.net
Support
- Anything already running with us
- Incidents, capacity changes and restores
- Accounts, access and policy changes
support@infinite-networks.net
Office
#002, Ceaser's CastleSainikpuri, Defence Colony
Hyderabad 500 094
India

