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 into atomic release folders with one-click rollback, and spin up a throwaway environment per pull request. You drive it from a site’s Staging and Deploy tabs (open any site from Sites or a server’s Sites list). These workflows are on the Pro plan and up.

Staging & push-to-live (WordPress)

For WordPress, the loop is clone → edit on staging → push to live. Use the Clone action on a site to create a staging copy (its URLs are search-replaced for the staging domain), make your changes there, then push selected pieces back to production from the staging site’s Staging tab.

The push is not all-or-nothing — you choose exactly what goes:

Piece	Options
Files	Whole webroot, just wp-content, themes + plugins, uploads, or none (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: a push can take 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 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 — from the site’s Deploy tab.

• 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.
• Your build command (e.g. composer install, npm run build) runs 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.

The Deploy tab shows the release timeline (which release is active) with a per-release Rollback.

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

Point a deploy at a git repository and branch: MZPanel clones it, runs your build command, and flips the release symlink. Build output streams live to the dashboard. The build runs on your server via the agent — your source code never passes through MZPanel’s infrastructure. Connect a repo once under Git connections to deploy from private repositories without pasting a token each time.

Containerized workloads (Docker apps and Compose stacks) build from git a different way — with a Dockerfile or Nixpacks auto-detect. See Docker apps & stacks for that path.

PR preview environments

Open a pull request and MZPanel can 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 pr<n>-<app>.box.mzpanel.com — so reviewers can click through the change before it ships. You can also create and destroy previews by hand from the Deploy tab.

Previews are triggered by the pull_request webhook from a connected GitHub repo (a per-repo webhook or a GitHub App installation).

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.

How it works

Every action here dispatches a job to the server’s agent, which runs it natively against your webroot — no mz shell-out, and nothing leaves the box.

Action	Job	Agent runs
Clone to staging	site.clone	site clone <domain> --to <staging> (WP search-replace)
Dry-run / push to live	site.push	site push <staging> --to <prod> (rsync + optional DB)
Enable atomic deploys	deploy.init	scaffolds releases/, shared/, current
Deploy a release	deploy.run	clone → build command → atomic symlink flip
Rollback	deploy.rollback	re-points current at a kept release
List releases	deploy.list	reads the release timeline
Create / destroy preview	deploy.preview-create / -destroy	per-PR preview env under pr<n>-…

Release history and the active symlink live on the box; MZPanel’s control plane only records the connected repo/branch and preview webhook wiring.

CLI & automation

Each 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 clone example.com --to staging.example.com --mode new --json
mz site push staging.example.com --to example.com \
   --files wp-content --db --dry-run --json     # preview; drop --dry-run to apply
mz deploy run app.example.com --json            # build + atomic release
mz deploy rollback app.example.com --to <release>

Pass a sub-action and --json for machine output. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• Push targets are same-server, same-type. A staging push runs on one box, so targets are that server’s sites only; a WordPress staging copy pushes to a WordPress production site. Cross-server moves use the file-transfer flow instead.
• Atomic deploys are for non-WordPress sites. WordPress writes to its webroot at runtime, so it uses Clone → Staging, not the release-folder Deploy tab.
• Rollback is code-only. Flipping the symlink back does not undo database migrations — keep them backward-compatible.
• Fork PRs are ignored on purpose. Previews build only for branches in the same repository, so untrusted fork code never runs on your box.
• Auto-posting the preview URL back to the PR is still being finalized. For now, copy the preview URL from the Deploy tab.
• Needs the agent online. Clone, push, deploy and previews all run through the agent; when the server is offline these actions are unavailable.

Related

• Docker apps & stacks — git-build with Dockerfile/Nixpacks, releases and rollback for containers.
• Git connections — connect repos for private deploys and deploy-on-push.
• Server sites — the site list these tabs open from.
• The mz CLI — driving the box from the command line.