Creating a Plan
A plan is a hosting product: every account references one, and everything the account may use flows from it. Panelica plans go far beyond counting domains: they carry kernel-enforced resource isolation, the same class of per-tenant CPU, memory, IO and process limits that CloudLinux is known for, built on the Linux kernel's native cgroups v2 so it works on stock Ubuntu, Debian, AlmaLinux and Rocky kernels with no kernel replacement.
Plans → Create Planhttps://YOUR-SERVER-IP:8443/plans/createEmail 10 · DB 5 · FTP 2 · Cron 5
IO 10 MB/s · Mode: strict
How enforcement actually works
Understanding this section makes every field below obvious. When an account is created on a plan, Panelica creates a dedicated cgroup slice for that account in the kernel's cgroups v2 tree and writes the plan's limits into the kernel's own control files: cpu.max, memory.max, memory.swap.max, pids.max and io.max. From that moment the kernel itself polices the account: this is not a polling script that reacts after the damage, it is the same mechanism the kernel uses for containers.
Everything the account runs is placed into its slice: its PHP-FPM pools, SSH and SFTP sessions, FTP transfers and cron jobs are all attached automatically by Panelica, so there is no way to "escape" the limits by choosing a different entry point. When a limit is hit, the kernel acts and Panelica records the event (CPU throttling, out-of-memory kills, blocked forks) so you can see in the panel's resource monitoring exactly which tenant hit which wall and when.
The result is the CloudLinux promise delivered with native kernel machinery: one customer's runaway site cannot slow down, crash or starve the others.
Basic information and hosting limits
After the name and description, the Resource Limits section sets the classic hosting numbers. Disk and bandwidth take a MB/GB unit selector; -1 means unlimited, and setting it requires the dedicated "set unlimited" permission.
| Limit | Default | Notes |
|---|---|---|
| Max domains | 1 | Addon domains the account can create |
| Disk quota | 5 GB | Total storage for files, mail and databases |
| Inode quota | unlimited | File-count ceiling; useful against millions of tiny cache files |
| Monthly bandwidth | 50 GB | HTTP/HTTPS traffic per month; exceeding it flags the domain |
| Max subdomains | 5 | |
| Email accounts | 5 | |
| Databases | 2 | |
| FTP accounts | 1 | |
| Cron jobs | 3 | |
| Docker containers | 0 | 0 disables Docker for the plan entirely; N caps it; -1 unlimited |
| Node.js apps | unlimited | |
| Python apps | unlimited |
Resource Isolation (cgroups v2), field by field
This section appears when resource isolation is enabled on the server and your license and permissions include it. These are the hard, kernel-enforced walls.
CPU limit (%). 100 means one full core, and the field scales both ways: 50 gives half a core, 400 gives four. The form offers presets from a quarter core to eight.
Memory (MB) and swap (MB). memory.max is a hard ceiling. Swap is separate: 0 gives the account no swap at all (strictest and most predictable), -1 leaves swap unlimited.
Process limit (pids). Caps how many processes and threads the account can have at once.
:(){ :|:& };:) dies at process number 50: the kernel refuses the 51st fork. The server does not even blink, and Panelica logs a fork-block event for the account. Without this wall a single user could take the whole machine down in seconds.Disk IO: read/write bandwidth and IOPS. Throughput limits with KB/s to GB/s units and a separate IOPS cap; 0 means unlimited.
Network limit. Enforced on the Nginx side: the value is written into the account's vhosts as a transfer rate limit, in KB/s, MB/s or Mbps.
Quota mode. How the softer quotas (the hosting-limit table above) behave on overage: strict blocks creating new resources once a quota is exceeded, monitor only logs the overage.
strict can keep serving their site but cannot create a new database or mailbox until they clean up; under monitor everything keeps working and the overage is simply visible to you, useful for soft-launch or grace-period policies.PHP-FPM pool defaults
A subsection (behind its own PHP-limits permission) sets what accounts on this plan start with: max children (how many PHP requests run concurrently), PHP memory limit and max execution time.
Access permissions
This card is permission-gated as a whole. Switches for what the account may use:
- SSH as a three-level choice: none (no shell at all), jailed (an isolated, chroot-jailed environment: safe file operations without seeing the rest of the server), or full (a real shell, still confined to the account's jail and cgroup limits). Full is offered to ROOT, or to resellers whose own plan carries it; a reseller cannot grant more than they have.
- FTP, MySQL, cron jobs, SSL, backups: simple on/off switches (all on by default except where noted).
- Git (off by default), with a repository cap when enabled.
System
Plan status (active or inactive), a display order for listings, and the Default switch that makes this the plan preselected wherever plans are chosen.
Example plan recipes
Three starting points that map the fields to real products; tune them to your hardware.
| Field | Starter | Business | Agency |
|---|---|---|---|
| Domains / Subdomains | 1 / 3 | 5 / 10 | 20 / 50 |
| Disk / Bandwidth | 2 GB / 20 GB | 10 GB / 100 GB | 50 GB / 500 GB |
| Email / DB / FTP / Cron | 3 / 1 / 1 / 1 | 10 / 5 / 2 / 5 | 50 / 20 / 10 / 20 |
| CPU / Memory / Swap | 50% / 256 MB / 0 | 150% / 768 MB / 0 | 400% / 2048 MB / 0 |
| PIDs / IO write / IOPS | 30 / 5 MB/s / 500 | 60 / 20 MB/s / 2000 | 150 / 50 MB/s / 5000 |
| PHP children / memory / time | 5 / 128 / 30 | 10 / 256 / 60 | 25 / 512 / 120 |
| SSH | none | jailed | full |
| Quota mode | strict | strict | monitor |
Quotas for admins and resellers
For ADMIN and RESELLER the form is quota-aware: a My Limits card shows their remaining capacity, each numeric field is checked against what both their own plan and their leftover quota allow, hints under the inputs show the remaining headroom (turning yellow near the edge, red past it), and the form refuses to submit while any field exceeds it. Switches the parent plan has disabled are hidden and forced off, and the SSH level cannot exceed the parent's. The server enforces all of this again regardless of the client.
Editing
/plans/edit/ID opens this same form loaded with the plan's values; units are shown in the friendliest form (GB where round, IO in the unit that fits), and saving updates accounts governed by the plan.