Sizing
How much infrastructure a Citrix SecurSpaces™ deployment needs, and what drives it.
For what the platform requires rather than how much of it, see System requirements.
How to think about it
A SecurSpaces cluster has two kinds of node, and they size differently:
| Node pool | Runs | Scales with |
|---|---|---|
| Service | The control plane — central service, frontend, coordinator, proxy, workspace service, and the database if it is in-cluster | The size of the platform, not the number of developers. Largely fixed. |
| Workspace | Developer workspaces, one pod each | The number of workspaces running at once, not the number that exist |
Sizing the service pool is capacity planning you do once. Sizing the workspace pool is arithmetic on the workspace specifications you offer, and it is the part that changes.
This page gives figures for two sizes: a 50-developer proof of concept and a 500-developer production deployment. Treat both as starting points and verify against your own usage — see Resource allocation for reading actual consumption.
Note
If you want to evaluate SecurSpaces rather than run a pilot with real users, the 1-Click VM is a faster route than building a cluster. It runs the whole platform on a single virtual machine. See Deploy for evaluation with the 1-Click VM. The guidance below is for a Kubernetes deployment that a group of developers will actually use.
Reference node pools
500 developers
| Cloud | Service node pool | Workspace node pool |
|---|---|---|
| AWS | Two m7i.2xlarge (8 vCPU, 32 GiB) |
m7i.4xlarge (16 vCPU, 64 GiB), autoscaling |
| Azure | Two Standard_D8as_v6 (8 vCPU, 32 GiB) |
Standard_D16as_v6 (16 vCPU, 64 GiB), autoscaling |
| Google Cloud | Two n2-standard-8 (8 vCPU, 32 GiB) |
n2-standard-16 (16 vCPU, 64 GiB), autoscaling |
50 developers (proof of concept)
| Cloud | Service node pool | Workspace node pool |
|---|---|---|
| AWS | One m7i.2xlarge (8 vCPU, 32 GiB) |
m7i.2xlarge (8 vCPU, 32 GiB), autoscaling 1–6 |
| Azure | One Standard_D8as_v6 (8 vCPU, 32 GiB) |
Standard_D8as_v6 (8 vCPU, 32 GiB), autoscaling 1–6 |
| Google Cloud | One n2-standard-8 (8 vCPU, 32 GiB) |
n2-standard-8 (8 vCPU, 32 GiB), autoscaling 1–6 |
The service node does not get smaller when the deployment does. The control plane runs the same services either way, and an in-cluster database can still use 2 cores and 4 GiB at its limit, so 8 vCPU and 32 GiB remains the sensible floor. What changes is the count: one service node instead of two.
That single node is the trade-off to understand. A proof of concept with one service node has no control plane redundancy — during a node failure or a node upgrade, the platform is unavailable and running workspaces lose their connection. That is usually acceptable while evaluating and never acceptable in production. Move to two service nodes before you take on real users, whether or not the developer count has grown.
The workspace pool is smaller in shape as well as in count, because a pool that scales in 16 vCPU steps is a coarse fit when peak demand is 20 workspaces. Smaller nodes waste less while idle.
Both sizes
What matters is the shape — 8 vCPU / 32 GiB for service nodes and 16 vCPU / 64 GiB for workspace nodes — not
the specific family. Earlier generations such as m6i or Standard_D8as_v5 are equivalent, and any
general-purpose instance of the same size works.
Important:
SecurSpaces requires
amd64nodes. AWS Graviton instances (m7g,m8g) and Azure ARM-based sizes arearm64and are not supported. See System requirements.
Two service nodes is a minimum for availability rather than for capacity. Run the workspace pool with autoscaling: workspaces pause when idle, so the pool should be able to shrink overnight as well as grow during the day.
Control plane resources
The chart requests modest resources and permits considerably more. Size your nodes against the limits, not the requests — the requests are what a service needs at rest, and the limits are what it may use under load. A cluster provisioned to the requests will schedule successfully and then throttle.
| Component | Request | Limit |
|---|---|---|
| MongoDB (Percona, in-cluster) | 500m CPU, 1 GiB memory | 2 CPU, 4 GiB memory |
| MongoDB (legacy Bitnami path) | 1 CPU, 2 GiB memory | 4 CPU |
Two m7i.2xlarge service nodes give 16 vCPU and 64 GiB in total, which accommodates the platform services
alongside an in-cluster database at its limits, with room for the ingress controller and cluster add-ons. A
single node of the same size fits the same workload for a proof of concept, without the redundancy.
Using a managed database instead of an in-cluster one frees that headroom, which is one reason it is the production recommendation. The figures above are the defaults for a single-member deployment. If you run the internal database in production, size it for your own load and redundancy rather than from this table. See The SecurSpaces database.
Workspace capacity
A workspace holds its CPU, memory, and disk allocation only while it is running. Capacity is therefore driven by how many run concurrently, which idle detection largely determines.
To estimate the workspace pool:
- Take the workspace specifications you offer, for example 2 vCPU and 8 GiB.
- Estimate peak concurrency. It is lower than your developer count — allow for time zones, meetings, and workspaces that pause when idle.
- Multiply, then add roughly 20% for the node’s own overhead and for scheduling slack.
Two worked examples, both at 2 vCPU and 8 GiB per workspace:
| Deployment | Peak concurrent | Total | Workspace nodes |
|---|---|---|---|
| 500 developers | 200 workspaces | 400 vCPU, 1,600 GiB | About 28 m7i.4xlarge
|
| 50 developers (PoC) | 20 workspaces | 40 vCPU, 160 GiB | About 6 m7i.2xlarge
|
Both are memory-bound rather than CPU-bound at this ratio, which is typical: an 8 GiB workspace on a node with 4 GiB of RAM per core exhausts memory before CPU. If your workspace specifications are memory-heavy, size on memory and treat the core count as a by-product.
This is also why the workspace pool autoscales and the service pool does not. In a proof of concept the difference is stark — outside working hours a pool that scales to one node costs a sixth of one that does not.
Idle detection is the largest single lever on this number. A deployment where workspaces never pause needs a pool sized for every workspace that exists, rather than for those in use. See Workspace idle detection.
Specification ceilings
The platform enforces these maximums on a single workspace specification:
| Resource | Maximum |
|---|---|
| CPU | 1000 cores |
| Memory | 10,000 GiB |
| Disk | 10,000 GiB |
| GPUs | 1000 |
These are product limits, not recommendations. What you can actually request is bounded by the hardware in your cluster.
Database
Sized separately, because it grows with retained audit data rather than with concurrency. See Database sizing.
In short: plan for 10–40 GB of data at 500 developers and provision at least 100 GiB of storage. For a 50-developer proof of concept, plan for 1–3 GB and provision at least 20 GiB. Size MongoDB to its 4 GiB memory limit in both cases — the working set is driven by query patterns rather than by user count.
Registry and storage
| Component | Guidance |
|---|---|
| Container registry | Standard tier is sufficient at any size. Enable cross-region replication for multi-region deployments. |
| Workspace storage | One persistent volume per workspace, at the disk size in its specification. This is usually the largest storage consumer in the deployment. |