Manage resources

Open an App and select Resources. The page is divided into Plan, Shape, and Burst tabs.

Only Team owners and admins can change an App’s resources. How resources and usage relate explains the purchased shape, allocations, and burst that this page edits; the stable rules are listed in Resource limits and quotas.

Review the Plan tab

The Plan tab opens with How your App runs. The diagram separates the always-on services reserved on Your home node from the Burst pool and the usage-billed Cron pool.

To review or change purchased CPU, memory, and storage, open the Shape tab, or select Change plan on the Plan tab to open the same panel. Shape has seven reservable-service memory sliders plus the supported service toggles:

1. Enter the new CPU, service-memory, and storage amounts.
2. Review the new monthly price and the amount that will appear on the next bill.
3. Confirm the change.
4. Follow the resize status until it reaches a final result.

Storage can grow but can’t be reduced. A smaller CPU or memory shape is also rejected when the App’s required services no longer fit.

Configure automatic storage expansion

On the Shape tab, database and workspace storage can expand automatically when usage reaches the configured threshold. Media storage isn’t part of automatic expansion.

For each supported storage type:

1. Turn automatic expansion on or off.
2. Optionally set a maximum storage ceiling.
3. Review the displayed billing effect.
4. Save the storage setting.

Each expansion adds a fixed storage block to the purchased plan and permanently raises that storage amount. If you leave the ceiling blank, synsmarts uses the automatic ceiling shown in the portal. The ceiling is never silently exceeded.

Review the allocation breakdown

The Plan tab also shows where purchased capacity goes. MySQL, the Valkey roles, OpenSearch, RabbitMQ, Varnish, and NFS use customer-set memory reservations; each reservation is also that service’s hard limit, except NFS, whose limit is 1 GiB or the reservation if larger. PHP-FPM, Nginx, Scheduled Jobs, and the WAF don’t have customer memory reservations or limits. They use the unallocated headroom, and PHP-FPM worker count and OPcache grow when a service reservation is reduced. The breakdown is read-only outside the Shape controls.

Choose spike behavior

The Burst tab’s Burst & scale-out card controls CPU spike behavior. It doesn’t show memory controls for PHP-FPM, Nginx, Scheduled Jobs, or the WAF: those workloads always use unallocated memory headroom without a customer-set limit. Reservable services don’t use memory past their reservation, except NFS, whose container can use up to 1 GiB or the reservation if larger.

Choose one:

• Always keep my site fast (default) — the App draws whatever it needs. Use beyond the free allowance is metered.
• Keep my site fast, with a spending limit — the App draws extra capacity up to a multiple you choose. The extra cost stops at that limit, and the limit follows the plan when you resize.
• Never spend more than my plan — CPU is held to the plan. Heavy traffic slows pages down instead of costing more.
• Custom, per container — set each container’s CPU spike limits yourself.

Select Apply changes to submit.

Follow the resize

Applying resource changes restarts App services and can briefly affect availability. A reduction never moves the App. An increase can apply where the App runs or move the App to where the new size fits. The resize status distinguishes an in-place restart from a move, and a move also sends an email before it starts and when it completes. A move that needs new capacity waits for it within a bounded window rather than stalling indefinitely. If the window runs out, the resize status reports a terminal failure. No email announces the failure, so the status is the signal to watch.

A move only proceeds when the App can keep serving without the pod being moved. Rather than take the last serving replica offline, the resize fails and the App keeps serving.

How long a resize takes depends on which of these paths it follows; the status is the progress signal. Keep the page open until the status reports completion or a terminal failure, then test the live App. Don’t submit another resource change while one is active.

Recover from a problem

• If the page reports that the configuration is stale, select Load the latest configuration and repeat the edit.
• If another operation is active, wait for it to finish.
• If the configuration exceeds the plan, correct the App’s configuration file or change the plan.
• If a write includes legacy PHP-FPM or Nginx memory fields, remove them. The API rejects those fields as Dynamic memory isn’t editable.
• If the plan is too small for the App’s required services, choose a larger plan.
• If Change plan is unavailable, contact synsmarts support.
• If a resize fails or its status is unknown, select Load the latest configuration, review the current plan and allocation, and retry only after the prior operation is final.
• If resource editing is unavailable for the App, contact synsmarts support.