Platform architecture · desktop planning← Back to main page

Virtual Desktop Platform

One person. One remote desktop. Prove it at home first, then design each cloud build separately.

PLANNING ONLY · nothing deployed or tested

Outside this pilot: shared desktops · high availability · automatic failover · GPU workloads · public desktop ports

Compare all plans
01 · The local proof comes first

Proxmox · prove access and recovery

A proposed single-user guest on the home server. Every device, route and restore remains to be verified.

Status: planned · no VM built

1Reach the desktop

One person

Candidate devices

Mac laptop
Windows laptop
iPad · Android tablet
Phone
First client: to choose
sign in

Private
connection

No public
desktop portRoute & protocol: to decide
remote
session

Proxmox home server

Planned

One remote desktop

1 user · 1 session

Synthetic demo files only

Host capacity: unverifiedRescue console: unverified
Guest OS: Linux proposed · to decide
Meeting screen-sharing shows only the visible desktop. The VM and its files stay on the host.

2Protect it two ways

Work files

File sync is not backup

User files

Planned test data

back up

Versioned file backup

Tool, target & keys: to verify

restore

Earlier version → new folder

Compare checksum; original kept

Whole desktop VM

Same-host copy ≠ off-host backup

Full VM

Planned guest backup

back up

Off-host VM backup

Destination & key recovery: to verify

restore

New VM ID, network off

Console-only test; keep copy isolated

Two recovery layers can still share one failure domain. A shared NAS, its capacity, and independent key access must be reviewed.

3One step at a time — earn the next stage

Readiness check

  • Owner authorises VM work
  • Host room & rescue path
  • Off-host backup approved
  • OS · client · protocol chosen

Proxmox proof

First · planned
  • Build one desktop
  • Test one client
  • Test both restores

Acceptance

Needs evidence
  • Results & limits
  • Recovery timings
  • Repeatable runbook

Fresh AWS build

Only if accepted
  • New network & IAM
  • Costs & backup
  • Expiry & teardown

Azure comparison

Later
  • Linux VM desktop
  • or Windows AVD
  • Separate design & gates
Readiness not proven → stay at planning

Arrows show a proposed sequence. Cloud stages start only after the local proof is accepted; they are fresh builds, not transfers of the Proxmox VM.

Reusable design intent

Linux setup with cloud-init / Ansible, test method, evidence and runbook

≠

Redesigned for each environment

Image · network · identity · licences · desktop access · backups · costs

Read the diagram

PlannedDecision pendingGated / laterCommon mix-up
Proxmox plan: select one client and private access route, build one guest, then prove file recovery and isolated whole-VM recovery. No client or restore has passed yet.
Readiness decisions & recovery detail

Before any guest is built

  • Select one OS, client and protocol; do not assume a mobile app proves compatibility.
  • Verify host capacity for both the pilot and restored copy, off-host storage, a rescue console, and permission for actual VM work.
  • Keep encrypted-backup keys recoverable independently of the guest and its backup target.

Restore without a duplicate live identity

  • Restore a new VM ID and disconnect its network before first boot.
  • Check from the console; the restored hostname and machine identity must not collide with the original.
  • Record failures and timings. Remove the test copy only under an agreed cleanup plan.
02 · Separate build after local acceptance

AWS · plan a private EC2 desktop

A fresh Linux build in a dedicated VPC. Region, size, protocol, access method and spending envelope are decisions to make.

Status: gated plan · no AWS resources
Planning only · local recovery is the entry gate. No VM migration is implied; cloud networking, identity, recovery and cost controls need a separate design.

1Reach a private cloud desktop

One person

One selected client

Mac or Windows
Tablet: pending

Re-test the chosen client against the cloud desktop stack.

Client & protocol: to test
sign in

Private
access path

No public
desktop port

VPN or reviewed overlay; private routing required

Access & egress: to design
private
session

AWS VPC

Proposed · private subnet

EC2 Linux desktop

Fresh build · 1 user

Encrypted EBS · no public IP

SG: private source onlyIAM role: least privilegeKMS & endpoints: to design
Image · size · protocol: to decide
Private subnet is a starting point, not the whole control. Route, security-group rules, guest firewall, identity and outbound dependencies all need review.

2Design both recoveries

Work files

Sync / versioning alone ≠ restore proof

User files

Synthetic data only

back up

Versioned file repository

S3-backed option; tool & keys pending

restore

Earlier file → new path

Compare checksum; original kept

EC2 & attached volumes

Snapshot creation ≠ recovery proven

EC2 / EBS

Planned backup scope

back up

AWS Backup plan

Vault, retention & KMS: to design

restore

New EC2, isolated first

Quarantine subnet / SG selected before restore

Same-account backups share an account-compromise risk. Account separation, delete protection and independent key recovery remain decisions.

Estimate before provisioning

Region, EC2 hours, EBS, backup, access, endpoints / NAT, logs and traffic. A dated estimate is required; budget alerts are not a hard spending cap.

Give the pilot an expiry

Owner, scheduled stop and review date. Stopped compute can still leave billable storage, networking and recovery points.

Verify teardown

Inventory EC2, EBS, AMIs, snapshots, recovery points, IPs, access services and logs. Retain only explicitly agreed recovery evidence.

3Plan → prove → recover → decide

Entry gate

  • Local recovery accepted
  • Cloud scope authorised
  • Cost estimate approved
  • Expiry & cleanup agreed

AWS design

Decisions pending
  • VPC · route · IAM
  • Image · keys · egress
  • Backup & restore scope

Desktop proof

Planned
  • Fresh EC2 build
  • One client / protocol
  • Disconnect & reconnect

Recovery proof

Needs evidence
  • Earlier-file restore
  • Isolated EC2 restore
  • Timings & access checks

Decision & teardown

After acceptance
  • Actual costs & limits
  • Retain / remove agreed
  • Azure remains separate
Local recovery not accepted → AWS stays at planning
AWS plan: a private EC2 Linux desktop with separate file and instance recovery workflows. All services shown are proposed; none has been provisioned or tested for this project.
AWS design decisions, restore caveats & sources

Decisions to settle before a build

  • Choose image, architecture, instance size, protocol and a private client route; review software licensing and supported clients. Tablets remain pending.
  • If Amazon DCV is selected, verify its EC2 licensing checks and required S3 reachability / IAM permissions; do not assume a private subnet has every required dependency.
  • AWS Backup restores a new instance. Select quarantine networking and its IAM profile before restoring. User-data is not backed up; the original key pair is retained. Check identity and avoid contact with normal services until cleared.
  • A security group is an allow-list. Remove unneeded outbound permissions and review AWS service-traffic exceptions; it is not a complete isolation boundary by itself.

Official references · checked 23 Oct 2026

These references describe service capabilities. They do not establish a deployed, licensed or tested configuration.

03 · A later comparison, with an explicit fork

Azure · choose a desktop model first

Option A is a self-managed Linux VM. Option B is Windows Azure Virtual Desktop. They require separate access, identity, licensing and recovery designs.

Status: future plan · no Azure resources
Planning only · compare after the earlier stages. Select one option for a future pilot; this page does not propose running both.

1Option A · private Linux VM

One person

One chosen client

Mac or Windows
Tablet: pending

Validate the client against the chosen Linux desktop stack.

Client & protocol: to test
sign in

Private
access path

No public
desktop port

Private route and graphical protocol selected together

Route & identity: to design
private
session

Azure VNet

Proposed · private subnet

Linux VM desktop

Fresh build · 1 user

Managed disks · no public IP

NSG: private source onlyManaged identity: to designKey Vault: to decide
Image · size · encryption: to decide
This Linux lane uses a selected desktop stack on a VM. Azure Virtual Desktop is a separate Windows session-host design, shown below.

2Plan recovery for Option A

Work files

Sync alone ≠ backup

User files

Synthetic data only

back up

Versioned file repository

Blob-backed option; tool & keys pending

restore

Earlier file → new path

Compare checksum; original kept

VM & managed disks

Recovery point ≠ restore proven

Linux VM

Check supported disk / agent scope

back up

Azure Backup plan

Vault, policy & key access: to design

restore

Restore disks → isolated VM

Quarantine VNet / NSG before first boot

Subscription / account separation, retention and independent key access need review. A second recovery layer does not remove a shared account failure risk.

OR · Option B: Azure Virtual Desktop

A distinct managed desktop-access service to evaluate, if a Windows desktop is the goal.

Future option · Windows session hosts

Supported client

Windows App / supported client route; device coverage to verify

sign in

Entra identity

Tenant, entitlement, sign-in policy and supported join model: to design

broker

AVD control plane

Workspace, app group and host pool type: to choose

session

Windows session host

Supported edition, licence eligibility, profiles and recovery: separate gates

Linux is not an AVD session-host option. The AVD lane needs its own network, profile and data-recovery design. Managed brokering does not prove workload backup or availability.

Compare complete costs

VM hours, disks, backup, access services, traffic and logs; add eligible Windows / AVD licensing and profile storage for Option B. No price is assumed.

Separate the evidence

A Linux VM result does not validate AVD. Compare the same tasks, client behaviour and recovery outcomes on whichever option is selected.

Plan expiry & cleanup

Agree a stop date and inventory. Review retained disks, IPs, vault recovery points, profiles, networking and logs before declaring teardown complete.

3Choose the model before the pilot

Comparison gate

  • Earlier results reviewed
  • Azure scope authorised
  • One desktop model chosen
  • Cost & expiry agreed

Azure design

Decisions pending
  • VNet · access · identity
  • Linux image or AVD hosts
  • Licence & key checks

Selected pilot

Future
  • One user / chosen client
  • Fresh build & config
  • Record access behaviour

Recovery proof

Needs evidence
  • Files / profiles in scope
  • Isolated VM or host test
  • Document recovery limits

Compare & close

After evidence
  • Cost & operational tradeoffs
  • Keep / remove agreed
  • Record teardown evidence
Desktop model or licence unresolved → no Azure pilot
Azure plan: choose between a private Linux VM with a selected remote-desktop stack and a separate Windows Azure Virtual Desktop design. Neither is deployed, licensed or validated for this project.
Azure model boundaries, recovery decisions & sources

Decisions to make explicit

  • Choose one lane. Do not infer that Linux tools, guest images or clients transfer to Windows AVD.
  • For the Linux plan, restore disks and establish quarantine networking before creating / booting the test VM. Review NSG defaults, effective rules, egress and network reachability.
  • Azure VM backups cover supported attached disks; temporary disk data and memory state are not included. Review the support matrix and application consistency requirements.
  • For AVD, check supported Windows editions, identity / join prerequisites, host pool model, licensing and client support. Design profile / user-data recovery separately.

Official references · checked 23 Oct 2026

Service documentation supports the planning choices; it does not establish implementation or recovery acceptance.

← Back to main page