Sites

The Sites section of a server (/servers/:id/sites) is where you create and run the non-containerised web apps that box serves from Nginx + PHP-FPM: WordPress, plain PHP / Laravel / Symfony, static HTML/SPA, and Node.js / Python / Go runtime apps. It’s a searchable list of site cards — create, enable, disable, delete and (on Pro) cap each site’s resources. Site CRUD is available on all plans; per-site resource plans are Pro and up.

Docker workloads live elsewhere

Containerised apps and Compose stacks are managed in the server’s Apps section, not here. Sites are the vhost-served web apps; Apps are the Docker ones.

Create a site, step by step

1. Click New site to open the create drawer.
2. Pick a Site type — WordPress, PHP, Static, Node.js, Python or Go — and enter the Domain (e.g. example.com). The domain must include a TLD.
3. Fill in the type-specific fields:
   • WordPress — nothing else to set. You get WordPress (latest), the server’s default PHP, a Redis object cache, a www alias, and HTTPS issued automatically.
   • PHP — choose the Framework (Laravel / Symfony / plain) and PHP version; Laravel/Symfony default the document root to /public.
   • Node.js / Python / Go — set the runtime version, the Start command the supervisor runs, and the internal App port Nginx reverse-proxies to.
   • Optionally set a Document root and, for PHP/runtime sites, a Git repository (which enables the site’s Deploy tab).
4. Pick the SSL method (Auto Let’s Encrypt, or None for now — WordPress always auto-issues) and click Create site.

The site is provisioned in the background (~1 minute). A pending card with a spinner shows above the list while the agent builds the Linux user, PHP-FPM pool / systemd unit, Nginx vhost and certificate; the real card replaces it when the site comes up — no toast, the list simply reflects the live state.

Tip

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

What else you can do

The list is searchable (by domain or alias) and filterable. Each card is the entry point to that site’s full management.

• Filter by type (All types / WordPress / PHP / Apps / Static) and, on Pro, by resource plan; the counts next to each type update live.
• Refresh from the agent — the list reads a pushed inventory cache; the refresh button (showing “synced Nm ago”) asks the agent to re-push now.
• Enable / disable a site — disable takes it offline (the vhost stops serving) without deleting anything; enable relinks it.
• Delete a site — permanently removes its files and database. Destructive and not undoable, so back up first if the data matters.
• Open a site — click through to the per-site shell (Overview, Plugins, Cache, SSL, PHP, Deploy and more).
• Bulk actions — select cards to reveal a floating bar: Set plan (Pro), Clear cache, Back up, Enable, Disable and Delete across the selection at once.
• Resource plans (Pro) — the Plans button opens a drawer to define reusable packages of CPU/RAM/task/disk caps, then assign one to a site from its plan column.

Per-site resource limits (Pro)

On Pro and up you can cap what each site is allowed to consume, so one runaway site can’t take down the whole box. It’s built on stock Ubuntu — systemd cgroups v2 and ext4/XFS disk quota, no proprietary kernel. Assign a resource plan (a named CPU/memory/tasks/disk package) from the site’s plan column, or set caps per site:

Resource	Cap
CPU	A hard ceiling (e.g. 200% = 2 cores) plus a fair-share weight when the box 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.

Caution

Disk quota needs the filesystem quota feature enabled on the server, which requires a one-time reboot to activate. 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.

How it works

Every action here dispatches a site.* job to the server’s agent, which runs it natively (no mz shell-out) against Nginx, PHP-FPM, systemd and the box’s package tools:

Action	Job	Agent does
List	site.list	reads the pushed inventory snapshot
Create	site.create	provisions user + pool/unit + vhost + install + cert
Enable	site.enable	relinks the Nginx vhost
Disable	site.disable	unlinks the vhost (stops serving)
Delete	site.delete	removes files, database and config
Clone	site.clone	copies a WordPress site to a new domain
Resource caps	site.limits-set / site.limits-clear	writes the systemd slice + quota

MZPanel does not mirror the full site state in its own database — the box’s config is the source of truth. The list you see is an agent-pushed cache, so it renders instantly and works read-only even when the server is briefly offline; mutating actions need the agent online.

CLI & automation

Every action maps to an mz command on the box — the same engine the dashboard drives. SSH in and run them directly, or let an on-box AI (ClaudeCode) run them:

mz site list --json                                    # every site on the box
mz site create example.com --json                      # a WordPress site
mz site create app.example.com --type nodejs \
   --runtime 22.x --app-port 3000 --json               # a Node.js runtime app
mz site disable example.com --json                     # take it offline (vhost unlinked)
mz site delete example.com --json                      # remove files + database

For non-WordPress types pass --type static|php|nodejs|python|go plus the relevant flags (--framework, --runtime, --app-port, --start-cmd, --git, --docroot). Always pass --json for machine-readable output. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• Bulk “Clear cache” and “Back up” are not wired yet. In the current build the floating bulk bar’s Clear cache and Back up buttons are placeholders and do nothing. Clear a site’s cache from its own Cache section instead, and use a backup job for backups. Bulk Enable / Disable / Delete and Set plan are real.
• Offline servers show a cached list. The section renders the last pushed inventory and shows a preview banner; create, enable/disable, delete and clone need the agent online.
• Delete is permanent. It removes files and the database with no undo — a bulk delete lists exactly what’s about to go before you confirm. Back up first.
• Clone only supports a brand-new domain today. Cloning a WordPress site into a new domain on the same server works; the overwrite and subfolder modes are not wired in the agent yet and return a clear error.
• Runtime sites start from a placeholder. New Node/Python/Go (and PHP-framework) sites come up with a placeholder app until you deploy real code from the site’s Deploy tab.
• The resource-plan column only appears on Pro. On Free/Plus the plan filter, the Plans button and the per-card plan control are hidden.

Related

• Site overview — the per-site health cockpit once a site exists.
• Sites (across the fleet) — the same sites from the account level.
• Cron jobs — scheduled tasks on this server.
• The mz CLI — driving the box from the command line.