Skip to main content
The plan a template needs is the higher of two plans: the one calculated from what the services require, and the min_plan you declared. Any plan can use a template as long as it meets both. You do not write the calculated part; the platform derives it from the manifest.

What is calculated

The API calculates it over the plan catalog, never from a fixed list, so it stays correct when plans change. For the plans themselves, see Plans and limits. Services switched off by an answer are not counted, so a template whose Postgres is optional asks for less memory when the user picks SQLite. A template with a connection that is not available over public addresses stays out of the public gallery.

Image slots

A template of image uses one slot per distinct image the user runs. Services that share the same source.image and the same source.context (the same build) share a slot; the same source.image with another context folder is another image and another slot. Three apps from the same template use one, and a new version of the template keeps the same slot. The slot is released when the last app that uses the image is gone. A code template uses none. In your own private template, the images are yours and already occupy your slots.

Why a template does not fit

When a template does not fit an account, the card and the page say why. The reasons are: The same list is returned by the API for each template when you are signed in, in account.reasons.

min_plan

min_plan is a commercial decision of the author, for example “only from Enterprise-28 up”. It is the id of the plan, not the name shown in the dashboard:
The ids are economy, pro, scale, intermediary and enterprise-<size>. A value that is not the id of an existing plan is refused with invalid_plan by the CLI, the editor, the API and the CI of the public repository, so a template never silently points to a plan that was renamed. Use it sparingly: if the services already force a plan, min_plan is redundant.

See the result before you publish

vertra template validate and POST /v1/templates/validate return the calculated plan for your manifest (here, for the starter bot):
required_plan is the lowest plan that meets the requirements and min_plan, and ram_min_total is the sum of the minimum memory of all services in MB. Both are null when the manifest is too invalid to calculate. See Validate and test.

Deploy settings never grant more

The deploy block of a service can only restrict behavior, never unlock something the plan does not include. A manifest that asks for blue-green on a plan without it still runs without it. See Deploy settings.
Last modified on October 30, 2026