Plans, quotas & enforcement

Plans

A plan is a reusable bundle of resources and lifecycle rules. Manage plans under Provisioning > Plans (New plan). When you pick a plan in the create wizard it fills and locks the cores, memory and disk, and the guest is tracked against the plan.

Setting	Meaning
vCPU cores / RAM (MB) / Disk (GB)	The resources the guest is created with.
Max port speed (Mbit/s)	NIC rate limit, 0 = unlimited.
Traffic limit (GB/mo)	Monthly traffic cap, 0 = unlimited.
Runtime (days)	Days until the plan expires, 0 = no expiry.
Grace period (days)	Days after suspension before the guest is deleted, 0 = never.
Snapshot limit	Snapshots a customer may keep per guest, 0 = no customer snapshots.
Active	Only active plans are offered in the create wizard.

The Plan section of a guest

A guest created from a plan gets a Plan section on its page with its expiry, the traffic used this month and the plan period. From there an admin can:

• Renew the plan by its runtime, Extend the expiry by a number of days, or Set expiry date (and Clear it).
• Suspend, Resume or Expire now.

The Limits section can Apply a plan to any guest (it re-applies the plan’s CPU, RAM and port speed and updates the guest’s plan assignment, traffic cap included) or set custom limits.

Enforcement

The php spark plans:enforce daemon applies the plan rules:

• Expiry: an expired guest is suspended. After the grace period it is deleted (never, with a grace period of 0). The owner receives an email a few days before expiry, on suspension and on deletion.
• Traffic: traffic is counted per month from the collected metrics. A guest above its traffic limit is throttled (its NIC is slowed down, by default to 5 Mbit/s), not suspended. The throttle is lifted when the counter resets at the start of the next month.

Note

Enforcement is off until you set enforce.enabled = true in .env, and it only ever touches guests that were created from a plan or had one applied. Other guests are never affected. Guests in a running migration and migration safety copies are skipped. The throttle speed is set with enforce.throttle_mbit in .env.

Resource packs

Provisioning > Resource packs defines budgets for customers: maximum vCPU cores, RAM, disk and number of servers, a node/storage/bridge/IP zone for placement, the allowed guest types and the OS template groups. A pack is assigned to a customer on their page under Users > Customers (Self-service resource pack).

With a pack assigned, the customer sees the remaining budget on My Servers and can create and delete their own servers in the portal (Create server):

• The customer picks only a name, the type (from the types the pack allows), cores, memory, disk, the operating system (from the pack’s template groups), a root password and SSH keys. Node, storage, bridge and IP come from the pack.
• Every request is checked on the server against the remaining budget (cores, memory, disk, number of servers). A server that does not fit is refused before anything is created.
• Only servers the customer created this way count against the budget, and only those can the customer delete. Servers you assign the usual way are not affected.
• The budget is reserved when the create is queued and freed when the server is deleted.
• Creates are refused while the pack’s node is in maintenance, its agent is missing or stale, or the chosen image is set to manual download and not on the node yet.

Note

Container templates are not limited by the pack; the template group whitelist applies to VM templates.

Next steps

• Creating a guest from a plan.
• Users & portal to see how customers view their servers.
• Alerts & webhooks for plan traffic and expiry alert types.