Create a site

A site is a domain served from one of your servers. You create and manage sites from the dashboard — pick a server, choose a type, and the agent provisions everything on the box (Nginx vhost, document root, process, certificate). Site CRUD is available on all plans.

Site types

MZPanel provisions six site types end-to-end. The type decides how the site is served:

Type	How it’s served
WordPress	PHP-FPM pool + Nginx with FastCGI cache
Static	Nginx serving files from a document root — no runtime
PHP (plain or Laravel / Symfony)	PHP-FPM pool; for Laravel/Symfony the document root is /public
Node.js / Python / Go	A systemd service runs your app on a local port; Nginx reverse-proxies to it

Static and PHP sites are served directly by Nginx and PHP-FPM. Node, Python and Go sites get a systemd unit that keeps the process running, with Nginx in front as a reverse proxy.

Note

For PHP-framework and runtime sites, real code is deployed via the deploy flow — see Staging & deploys. New runtime sites start from a placeholder app until you deploy.

Create a WordPress site

1. Open the server you want to host the site on, go to Sites, and choose Create site.
2. Pick WordPress as the type and enter the domain.
3. Confirm. The agent provisions the Linux user, the dedicated PHP-FPM pool, the Nginx vhost and a WordPress install, then issues a certificate.

The new site appears in the list as it comes up — no toast, the card simply shows the live state. From there you can manage it: SSL, PHP version, cache, domains and more, all from the site’s manage drawer.

Tip

You can manage every site from the account-level Sites page too, not just from inside its server — handy across a fleet of many servers.

Enable / disable / delete

Each site can be enabled, disabled or deleted from its card or manage drawer:

• Disable takes the site offline (the vhost stops serving) without removing anything — useful for pausing a site.
• Enable brings it back.
• Delete removes the site and its configuration from the server.

Deletes are destructive — back up first if the data matters.

Per-site resource limits (Pro)

On the Pro plan you can cap what each site is allowed to consume, so one runaway site can’t take down the whole server. This is built on stock Ubuntu features — systemd cgroups v2 and ext4/XFS disk quota — with no proprietary kernel.

Open a site’s manage drawer and use the Limits tab to set:

Resource	Cap
CPU	A hard ceiling (e.g. 200% = 2 cores) plus a fair-share weight when the server is busy
Memory	A soft reclaim threshold and a hard limit (OOM-kill above it)
Tasks	A process cap that stops a fork bomb inside the site’s slice
Disk / inodes	A hard quota per site’s Linux user

Each site runs its PHP-FPM under a dedicated systemd slice, so the caps apply to exactly that site. The Limits tab also shows live usage bars (used vs. limit) so you can see which sites are near their ceiling. Defaults follow your plan tier and can be overridden per site.

Caution

Disk quota needs the filesystem quota feature enabled on the server, which requires a one-time reboot to activate. The dashboard offers a one-click enable and prompts for the reboot. A site that hits its memory cap is OOM-killed and may return a temporary 502 — that’s the limit doing its job, not a panel error.