Staging & deploys

MZPanel gives you a full staging-and-deploy workflow from the dashboard: clone a site to staging, push changes back to production safely, deploy apps from a git repo with releases and one-click rollback, and spin up preview environments per pull request. These workflows are available on the Pro plan.

Staging & push-to-live (WordPress)

For WordPress, the loop is clone → edit on staging → push to live. Clone a site to create a staging copy (with the URLs search-replaced for the staging domain), make your changes there, then push selected pieces back to production.

From the site’s Staging tab you choose exactly what to push — it’s not all-or-nothing:

Piece	Options
Files	Whole webroot, just wp-content, themes + plugins, uploads, or a custom path (via rsync)
Database	All tables, selected tables (e.g. wp_posts + wp_postmeta), or none — with reverse search-replace of the staging domain back to production
wp-config / secrets	Never pushed — production credentials stay intact

Safety is built in: every push takes a snapshot of production first (so you can roll back), and a dry-run shows the file and table changes before anything is written. A maintenance window is enabled briefly during the database import.

Caution

A database push overwrites tables — it doesn’t merge rows. If production collected new data (e.g. WooCommerce orders) while you edited staging, pushing that table loses it. Push content tables, not user/order tables, and rely on the mandatory pre-push backup as your safety net.

Atomic deploys & rollback

For PHP-framework (Laravel / Symfony), Node, Python, Go and static sites, MZPanel deploys into release folders with an atomic symlink switch — the Capistrano-style pattern.

• Each deploy builds into a new release folder; a current symlink is flipped atomically to point at it, so there’s no downtime and no half-applied state.
• Persistent files (.env, uploads, storage/) live in a shared/ directory symlinked into every release, so they survive deploys.
• Build steps (e.g. composer install, npm run build) run in the new release folder. If a build step fails, the symlink is not switched — the old release keeps serving.
• The last few releases are kept, so rollback is just flipping the symlink back — instant, no rebuild.

You manage this from the site’s Releases tab: a timeline of releases (commit, time, status, which is active) with a per-release Rollback button.

Caution

Rollback restores code instantly, but it does not roll back database migrations. Keep migrations backward-compatible and back up before running them. WordPress is not deployed this way — it writes to its webroot at runtime, so it uses the staging / push-to-live flow above instead.

Git-deploy from a repo

MZPanel can build and deploy an app directly from a git repository. Connect a repo and branch, and a git push triggers a rebuild and a zero-downtime release swap. Build logs stream live to the dashboard. The build runs on your server via the agent — your source code never passes through MZPanel’s infrastructure.

This works on the app and stack (Docker Compose) namespaces, with releases and rollback on top.

Note

Today, building from git uses a Dockerfile in your repo (or builds Compose stacks from source). Automatic builder detection without a Dockerfile (Nixpacks / Buildpacks) is designed but not yet built — see the roadmap. Bring a Dockerfile for now.

Per-app environment variables

Each app has an env store you manage from the dashboard instead of editing .env over SSH. Values are masked in the list with a reveal action, survive rebuilds, and are injected into the container at runtime.

Env values are encrypted at rest on the server (sealed with the agent’s own key) and materialized only into an ephemeral, in-memory file when the container starts — so a stray disk snapshot or backup never exposes them. The Env tab shows an “Encrypted at rest” badge to confirm this.

PR preview environments

Open a pull request and MZPanel can automatically deploy a throwaway preview environment for it, then tear it down when the PR is closed or merged. Each preview gets its own domain with HTTPS — for example under pr<n>-<app>.box.mzpanel.com — so reviewers can click through the change before it ships.

Previews are triggered by the pull_request webhook from a connected GitHub repo (via a per-repo webhook or a GitHub App installation). You can also create and destroy previews manually from the Previews tab.

Caution

Previews are only created for pull requests from a branch in the same repository. Pull requests from forks are deliberately ignored: MZPanel builds and runs on your server, with no isolated sandbox, so it never runs untrusted fork code on your box.

Note

Auto-posting the preview URL back as a PR comment requires a GitHub App with the right scope and is being finalized — for now, copy the preview URL from the dashboard.