Docker apps & stacks

MZPanel runs containerized workloads on your servers two ways: single apps (one image) and stacks (a full docker compose file). Both are managed from the dashboard and are gated to Pro+.

Marketplace 1-click apps

The Marketplace (account level) is one catalog of apps and extensions. Pick an app — n8n, Ghost, an AI UI, and more — choose a target server, give it a domain, and deploy. The Marketplace is state-aware: it shows what’s already installed on each server (with an “Installed N/M” badge) and lets you update or remove in place, so the full lifecycle lives in one screen.

Under the hood, deploying an app from the catalog provisions the container, wires up the nginx vhost, and issues SSL — the same flow you’d get configuring it by hand, without the steps.

Compose stacks

A stack is a docker compose file you deploy as a unit. MZPanel validates the compose (docker compose config) before bringing it up, so YAML and missing- variable errors surface inline instead of failing halfway. Day-2 actions include Update images (pull + recreate), health-depth (it reads the real failing healthcheck reason and restart count, not a guess), and per-service inspection.

Stacks back up as a unit too — a DB-consistent backup captures the compose file, logical database dumps, and non-database volumes for a full restore.

Env store, build from git, rollback

For both apps and stacks you can manage configuration and deploys from the dashboard — no SSH editing of .env files:

• Env store — set environment variables per app/stack from the Env tab. Secrets are masked (reveal on demand), survive rebuilds, and stay out of build logs.
• Build from git — point an app at a Git repository and MZPanel clones and builds it on the box. With a Dockerfile it builds that; without one, it uses Nixpacks auto-detect (Node, Python, Go, Ruby, and more) so you don’t need a Dockerfile at all. Pushing a new commit can trigger an automatic rebuild via a repo webhook. Builds run a RAM/disk preflight first so a low-memory VPS isn’t pushed over the edge.
• Releases + rollback — each successful build is kept as a release. If a deploy goes bad, roll back to a previous release instantly from the Releases tab — it reuses the already-built image, so there’s no rebuild.

Source code stays on the box

Builds run on your VPS through the agent, not on MZPanel infrastructure — your source code never leaves your server. The trade-off is that a build is a short spike of CPU/RAM on the box; the preflight guard keeps it in check.

For per-PR preview environments built from these apps, see Staging & deploy.

App proxy — reaching apps privately

Admin UIs like phpMyAdmin, pgAdmin, and webmail open as real pages on a MZPanel domain — not an iframe — through a reverse proxy that tunnels HTTP over the agent’s existing WebSocket to the app listening on localhost on your box.

Because the app only listens on 127.0.0.1 and your box opens no public port for it, the box hostname and IP stay fully hidden — there’s nothing to scan or attack. A proxy session is owner-scoped and time-limited; large data transfers (such as database export/import) go through native tools, not the proxy.

See also

• Manage databases for the database admin UIs the proxy serves.
• Tiers & quotas for what each plan includes.