Windows VM in the Cloud with RDP on Dockup

A Windows VM in the cloud is appropriate when the workload requires a real Windows operating system, interactive RDP access, Windows-only software, or an environment that cannot be represented as a Linux container. Dockup supports Windows Server 2019, 2022, and 2025 plus Windows 10 and Windows 11 virtual machines.

A VM is not a default replacement for a container. It carries an operating-system lifecycle, remote desktop access, installed software state, and a larger security surface. Choose it because the workload needs Windows, not because RDP feels familiar.

Which workloads need a Windows Server VM?

Common reasons include:

• A vendor application supports only Windows.
• The service depends on Windows APIs or a .NET Framework version not suitable for Linux.
• A build or test process requires a Windows desktop.
• Automation controls a Windows-native application.
• A legacy service expects a Windows filesystem or registry.
• An operator needs an isolated remote desktop for approved work.
• Compatibility testing must cover Windows 10 or Windows 11.

Do not use a Windows VM solely to host a conventional Node.js, Python, Go, or container-friendly API. A Dockup service built from Git is easier to reproduce, deploy blue-green, health-check, and roll back.

Requirement	Better starting point
Standard web API	Git/container service
Windows-only installer	Windows VM
Interactive desktop	Windows VM
Stateless background worker	Container service
Browser compatibility on Windows	Windows 10/11 VM
Domain/server role test	Windows Server VM
Disposable Linux shell	Linux box

Make the operating-model difference explicit during architecture review.

Which Windows versions does Dockup support?

Query the current image list:

dockup win versions --json

The supported choices are:

Image	Typical use
server-2019	Legacy server compatibility
server-2022	Current enterprise server workloads
server-2025	New server features and testing
win-10	Desktop compatibility testing
win-11	Current desktop environment

Select the oldest version that satisfies the vendor and security requirements only when compatibility demands it. Older systems can increase patching and support risk. For new server workloads, validate against the vendor’s supported Windows Server releases.

Record the exact version in the runbook. “A Windows server” is not reproducible enough for recovery or replacement.

How do you create the Windows VM?

Provision a VM with a documented version, memory, and CPU allocation:

dockup win create \
  --project production \
  --version server-2022 \
  --memory 4096 \
  --cpu 2 \
  --json

The example requests 4,096 MB of memory and 2 vCPU. Size the machine from the software’s measured working set, concurrent user count, and background services. Do not allocate the maximum “just in case”; CPU, RAM, and disk consumption count against the plan balance with per-minute measurement.

Windows installation is heavier than starting a container, so provisioning is not an instant deploy. Keep the returned project/VM target and wait for the VM to become available before requesting access.

Paid Dockup plans allow unlimited deployments, databases, and workspaces. The recommended Go plan is $20 per month with $20 usage credit, while actual Windows resource consumption is metered separately from the subscription label.

For a workload that only needs SSH and a Linux operating system, compare Linux boxes.

How do you retrieve and use RDP access?

Request the connection details for the exact VM target:

dockup win rdp production/win-abc123 --json

The response contains the host, RDP port, username, and password. Treat the password as a credential that may be returned for access setup; do not paste it into an agent response, issue, or permanent runbook.

Connect with an RDP client from an approved device. Before opening the session:

1. Verify the target matches the intended workspace and VM.
2. Store credentials in an approved password manager.
3. Confirm who is authorized to connect.
4. Avoid shared personal credentials.
5. Record the purpose and expected session window.
6. Lock or close the session when finished.

RDP transport gives interactive access; it does not make every administrative action safe. A user with administrator privileges can install software, change firewall settings, expose data, or disable security controls.

An AI agent should not be given raw RDP credentials in a prompt. Use the VM for human-controlled desktop work or a separately reviewed automation path.

How should a Windows VM be configured for production?

Treat the VM as a server with declared state, even though Dockup provides the compute.

Document:

• Windows image and edition.
• CPU, memory, and disk expectations.
• Installed software and license ownership.
• Required Windows services.
• Application install and update procedure.
• Data directories and backup method.
• RDP users and access policy.
• Patch window and reboot behavior.
• Monitoring and log locations.
• Recovery or replacement plan.

Avoid manual-only knowledge. Keep installation scripts, configuration exports, or precise runbooks in version control without credentials. A VM that can only be rebuilt by remembering clicks is a single point of operational failure.

Separate durable data from replaceable system state when the application permits it. Store source code and installers in controlled locations. Back up application data with a method appropriate to that software; a Dockup service volume workflow applies to containers, not automatically to every Windows application.

What security controls matter for RDP?

RDP is a privileged access path. Apply least privilege and reduce exposure duration.

Risk	Mitigation
Credential sharing	Individual controlled credentials
Password in transcript	Never print or copy into chat
Unpatched OS	Defined update window
Untracked software	Installation inventory
Persistent admin session	Log off after work
Data copied to local device	Approved transfer policy
Disabled protection	Baseline review and audit
VM drift	Rebuild documentation

Do not disable Windows security features merely to make an installer work without understanding the consequence. Prefer vendor-supported configuration.

If the VM runs an internet-facing service, add application-level TLS, authentication, logging, and monitoring appropriate to that software. RDP access itself is not a deployment or observability system.

The security best practices article covers common production principles, while AI agent production guardrails explains why credentials must stay outside agent transcripts.

When should the workload move away from a VM?

Reconsider the VM when:

• The application becomes stateless and container-compatible.
• Installation can be reproduced in a Dockerfile.
• Interactive desktop access is no longer required.
• Scaling requires several identical instances.
• Manual patching and configuration drift dominate operations.
• A managed service replaces the Windows-only dependency.
• The vendor introduces supported Linux or web deployment.

A containerized Dockup service gains Git-based deployment, Dockerfile or Nixpacks builds, zero-downtime blue-green cutover, health gates, automatic push deployment, and deployment rollback. Those capabilities are difficult to reproduce with an opaque desktop-managed VM.

Windows VM handoff checklist

A complete Windows VM in the cloud handoff contains the target, exact version, requested CPU and memory, RDP owner, credential storage location, installed-software inventory, patch policy, data backup, monitoring, and rebuild plan.

Verify the image and access commands against the Dockup CLI reference. For metered cost modeling, read PaaS pricing explained.

Separate desktop access from service availability

An RDP session is an administration channel, not a health check. A disconnected desktop can leave the application running, and a successful RDP login does not prove the application is healthy.

Define service-level checks outside the interactive session: a public or private endpoint, Windows service state, application log, scheduled task result, or vendor-provided monitor. Record where those checks run and who receives alerts.

Plan patching and reboot behavior

Windows updates and vendor installers may require a reboot. Test the application’s startup sequence after reboot and verify that required services do not depend on an operator logging in.

Schedule patches, record the previous software state, protect durable data, and validate the workload afterward. A Windows VM in the cloud becomes production-ready only when maintenance can occur without improvising through an open desktop session.

Record licensing responsibility

Document which organization owns any Windows or third-party software licenses installed on the VM and how entitlement is verified during rebuild.

Keep an access review date

Review who can retrieve or use the RDP credential and remove access that no longer has a current operational purpose.

Start with a verifiable deployment

Provision a non-production Windows image, document every manual installation step, and prove that a second operator can connect and rebuild the environment without chat-stored credentials.

Start free at app.dockup.ai. The Free plan is $0 per month, includes $2.50 in starting credit, and supports one workspace, three databases, and three deployments.

FAQ

Which Windows versions can Dockup provision?

Dockup supports Windows Server 2019, 2022, and 2025 plus Windows 10 and Windows 11 images.

How do I get RDP credentials for a Dockup Windows VM?

Use dockup win rdp with the exact project/VM target and --json, then store the returned host, port, username, and password securely.

Should a normal web API run in a Windows VM?

Usually not when it is container-compatible. A Git or container service is easier to reproduce, health-check, deploy without downtime, and roll back.

Are Windows VM resources billed as a fixed instance?

Dockup measures CPU, RAM, and disk consumption per minute against the plan balance, so monitor actual use instead of relying only on the requested size.

Can I give an AI agent the RDP password?

Avoid placing RDP credentials in prompts or transcripts. Use human-controlled access or a separately reviewed automation interface with scoped permissions.