Your server
Every Workspace has one dedicated virtual machine. Projects organize the applications on that machine, while the machine defines the CPU, memory, and storage they share. Understanding that relationship helps you plan capacity and interpret resource problems.
Last updated
AI agent? Start with llms.txt.
The free machine has reserved capacity
The included Small workspace has 2 vCPU, 2.5 GB of RAM, and 20 GB of storage dedicated to the Workspace. Other customers do not share that virtual machine.
KVM provides the hardware virtualization boundary between Workspaces, using the same class of isolation major cloud providers use between customers. Services stay available without sleeping, cold starts, or eviction. See Security for the broader security model.
Projects share the machine
Every Service and Project database uses capacity from the same machine. Creating another Project creates an organizational boundary, not more hardware.
During a zero downtime web deploy, the current and new versions briefly run together, and Tokay accounts for that overlap when starting the release.
Usage shows where capacity is going
The dashboard shows usage for the whole machine. Each Project, Service, and database also shows its share of CPU, memory, and disk, including the platform overhead needed to run it.
Check these views before adding a heavy workload and when one application starts affecting the rest of the Workspace.
Memory pressure stops the process that caused it
When a process needs more memory than the machine can provide, Tokay stops that process and records the reason. A scheduled job reports Ran out of memory, and repeated events appear in usage and incident views.
The virtual machine itself stays protected. Common fixes include processing data in smaller batches, streaming instead of loading everything at once, or moving to a larger machine.
Copies of a Service share the machine
A Web Service, Function, or Background Worker can run several copies of its app side by side. Web and Function copies share incoming requests, so when one copy crashes the others keep answering. Each Background Worker copy runs the whole worker, which suits a worker that takes jobs from a queue. Change the count under Copies on the Service's Settings tab. It applies in seconds, without a deploy.
Each copy is a full process that uses its own share of your server's memory. A web deploy briefly runs the new version's copies beside the old ones, so leave room for both. Copies that don't fit stop the same way any process does under memory pressure.
Copies share the Service's environment variables, databases, and persistent files, but not what your code keeps in memory. Sessions stored in memory sign people out when a request reaches a different copy, and a scheduler built into the app runs each job once per copy. If your app may not work correctly as several copies, Tokay warns you before you add them.
Disk usage comes from data and history
Databases, persistent Service files, and deployment data all use the Workspace disk. Tokay limits logs and cleans old deployment data automatically, so persistent files and database growth are the main areas to inspect.
See Files and persistent storage for app owned data. Larger Workspace Sizes are available when the workload outgrows the current capacity.