Sizing and Capacity

Use these baselines to plan an initial deployment, then validate capacity with representative applications and user concurrency. Turbo Server scales horizontally, so you can separate roles and add hosts as demand grows.

What You'll Learn

• Which baseline to use for an initial deployment
• How to plan storage for Hub and Application hosts
• Which workload characteristics drive Application-host capacity

---

Planning Baselines

Use the following conservative planning baselines for an initial deployment. Actual capacity depends on the applications, concurrency, security software, and storage performance in your environment.

Deployment component	CPU	Memory	Storage planning baseline
Initial or small production host	4 CPU cores at 2.6 GHz or faster	16 GB	Role-dependent; use the Hub and Application reservations below
Dedicated Hub for a larger deployment	8 CPU cores or more	32 GB or more	1 TB or more for Hub data
Dedicated Portal	4 CPU cores or more	16 GB or more	Allow capacity for binaries, logs, and operational headroom
Dedicated Application host	4 CPU cores or more	16 GB or more	250 GB or more for the image cache, plus at least 128 GB free on the system volume for user profiles and session data

For an evaluation, you can co-locate the Controller, Hub, Portal, and Application roles. Co-location does not eliminate any role's storage consumption: budget at least 500 GB for Hub data, 250 GB for the Application image cache, and 128 GB of free space on the system volume. If these locations share a volume, allocate at least 1 TB of usable capacity.

These storage figures exclude database growth, logs, backups, and temporary upgrade or migration capacity. Monitor each volume and expand it before free space becomes operationally constrained.

Application Hosts

Application hosts usually reach capacity before the other roles because each active user session consumes application CPU, memory, and storage. Validate Application-host capacity with representative application images and the expected peak concurrency.

Start from these CPU ratios:

• Productivity applications such as Office: roughly one core, with hyperthreading, per five active sessions
• Applications with sustained high CPU use: roughly two to four cores per active session

Allocate memory for the working set of every concurrent application instance, plus the operating system, Turbo services, and any monitoring or endpoint-security software. Provide a compatible GPU only when the application publisher requires one, sized according to their guidance.

Turbo Server's own overhead is small: streaming a session to a browser costs about 1.3% average CPU on a single-vCPU guest, because Windows performs the video encode that Remote Desktop already produces.

Disk consumption grows with cached application images, temporary user profiles, and synchronized session data. Retain at least the 250 GB image-cache and 128 GB free system-volume baselines from the table above, then increase them for large images or persistent profile data.

Launch Concurrency

Simultaneous launches require more short-term CPU and storage throughput than the same number of staggered launches. This commonly occurs in classrooms, shift changes, and scheduled training sessions.

The figures below were measured on the legacy platform using default Azure instances with nothing else installed. Treat them as reference points, since security and monitoring agents shift the result:

Instance	Behavior
Standard D4s v3 (4 vCPU, 16 GiB)	About 14 concurrent sessions of a typical Office application such as Excel or Project before CPU or memory runs short
Standard D4s v3 (4 vCPU, 16 GiB)	15-25 seconds per launch for 10 staggered sessions; about 2 minutes for the same 10 launched simultaneously
Standard F8s v2 (8 vCPU, 16 GiB, compute-optimized)	About 30 seconds for that same burst

Compute-optimized instances handle bursts noticeably better than general-purpose ones at the same memory. Base production capacity on the worst expected launch pattern rather than steady-state utilization alone.

Hub Hosts

Start with at least 500 GB for Hub data. For a larger deployment or a repository with many retained revisions, start with at least 1 TB and monitor actual growth.

The current Hub stores whole application layers as content-addressed blobs. It does not provide the legacy platform's block-level deduplication, so do not reduce capacity estimates based on expected block reuse between image revisions. Estimate storage from the distinct layers and revisions you intend to retain, synchronized session data, and upload staging space.

Hub memory use increases with concurrent image and session-data transfers. Allowing 8 GB plus 50 MB per concurrent user is a workable starting figure, carried from the legacy platform. Monitor memory utilization, transfer concurrency, and storage latency under representative load.

Database Capacity

SQLite is appropriate for evaluation and single-Controller deployments. Use external SQL Server or Azure SQL when the deployment requires Controller high availability.

Monitor all database volumes. Analytics data grows with session and usage volume, so expand database storage before it approaches a provider or edition limit.

When to Add Hosts

Separate or add roles when monitoring shows sustained resource pressure:

• Add Application hosts when session concurrency, application CPU, memory, GPU, or cache activity approaches the validated host capacity.
• Move the Hub to dedicated storage when application images and retained revisions outgrow the shared data volume.
• Add Portal hosts when concurrent users cause sustained CPU, memory, or response-time pressure. Place Portal hosts behind a load balancer with session affinity enabled.
• Move to external SQL Server or Azure SQL when you require Controller high availability.

For a production design that exceeds these baselines, contact Turbo Support and provide representative application profiles, expected concurrent users, launch patterns, retention requirements, and availability objectives.