When limits change

A new limit restarts a live service. A datastore gets it in place, with no restart.

An apply with new limits

The dry run shows each change, for example memory_limit: 512 MiB → 2 GiB or cpu_limit: (server default) → 2 CPUs.

How the change applies

Resource	Result
A live service	Ferry restarts it (trigger `restart`). It keeps its image: there is no new build.
A live service, when a build or deploy key also changed	Its `blueprint` deploy brings the new limits.
A service with no deploy yet	It gets the limits with its first deploy.
A suspended service	It keeps its limits. The apply gives the warning `service 'NAME' is suspended: resume and restart it to apply the new resource limits`.
A datastore	It gets the limits in place, with no restart. The `maxmemory` of Redis follows.

Less memory can stop a datastore

If the new memory limit is below what the datastore uses, the kernel can kill it.

A service or a datastore that exists keeps each limit that the entry does not set. numInstances follows the same rule.

Limits from ferry update --memory or from the dashboard stay after a new apply of a file with no plan, memoryLimit or cpuLimit.
A limit that the entry sets wins. A new apply of a file with plan: starter puts back 512 MiB and 0.5 CPU.