# Container Limits for ZopDay VM Services, Refused Before Saving > A resource limit is only useful if you learn about its ceiling before you deploy. ZopDay VM services now take a CPU limit and a memory cap, both when the service is created, under Advanced settings,… Source: https://zop.dev/resources/blogs/container-limits-for-zopday-vm-services-refused-before-saving Published: 2026-10-14 · Author: riya-mittal · Tags: cloudops, containers, zopday --- A resource limit is only useful if you learn about its ceiling before you deploy. ZopDay [VM services](https://zop.dev/resources/blogs/zopday-push-to-deploy-vms-managed-load-balancer) now take a CPU limit and a memory cap, both when the service is created, under Advanced settings, and later in Settings → Runtime. A field left empty uses the default size. On ZopCloud, each service can use up to 0.5 CPU and 1 GB of memory. A larger value is refused before saving, and Deploy stays disabled with the reason shown. A served ceiling is a limit that the backend publishes and the screen reads, instead of a number copied into the interface. That is the idea behind how this change was built, and the sections below show why it matters. ## Two Fields Map Straight to Docker The two limits map directly onto the container runtime. The [CPU limit](https://zop.dev/resources/blogs/cpu-throttling-is-lying-to-you-why-your-container-limits-bleed-latency) becomes the docker `--cpus` setting and the memory cap becomes `--memory`. There is no translation layer in between, so the number you type is the number the runtime enforces. | Field | Where you set it | If left empty | |---|---|---| | CPU limit | Advanced settings when creating, Settings → Runtime later | Default size is used | | Memory (limit) | Advanced settings when creating, Settings → Runtime later | Default size is used | The runtime page shows the liveness path next to these fields and does not show Replicas. A VM service is one machine, so a replica count would offer a control that does nothing. ## The Ceiling Is Served by the Backend, Not Hard-Coded The ZopCloud ceiling is not typed into the interface. The deployer's default maximum CPU was lowered to 500m, with memory staying at 1Gi, and its pause-states endpoint now returns a `maxSize` next to the existing `defaultSize`. The app reads `maxSize` and refuses a larger ZopCloud value before saving. Architecture diagram If the ceiling lived in the interface, changing it would need a frontend release, and the screen and the server could disagree in between. With one source, a change to the maximum reaches the screen the next time it asks. The deploy-time check is unchanged. The screen is a courtesy that gives the reason early. The server check is the rule, so an out-of-date page cannot push an oversized value through. ## A Refusal Should Arrive While the Value Can Still Change Refusing at save time puts the message next to the field you just typed. Deploy stays disabled with the reason shown, so there is no step where a deploy starts and then fails on a number you set minutes earlier. This works when the screen has read `maxSize` recently. It cannot help a value that was valid when typed and became invalid after the ceiling was lowered, and that is the case the unchanged deploy-time check still catches. One related change: the old full service page route now opens the canvas drawer. These limits sit alongside the [per-app network isolation](https://zop.dev/resources/blogs/container-isolation-on-zopcloud-one-network-per-app) already on ZopCloud shared VMs. There is no migration, and the only API change is the added `maxSize` field.