Apps
Apps (/apps) is the account-level home for Docker: one screen that rolls up
every container and compose stack across all your connected servers, grouped
and searchable. It’s the fleet view — start, stop, restart and remove from here,
then jump into a single server’s Apps tab for the deep operations (logs, exec,
build-from-git, releases). Docker is gated to Pro and above.
Deploy a Docker app, step by step
Section titled “Deploy a Docker app, step by step”- Click Add Docker app to open the deploy drawer.
- Pick a Server — the target box the container will run on. Offline servers are flagged so you don’t deploy into thin air.
- Choose a source:
- Catalog — search the app catalog (n8n, Ghost, analytics, AI UIs, and more), click a tile, and adjust the Name. Stack apps are badged stack and bring up more than one service.
- Custom image — enter a Name, an Image (
org/image:tag), and optional Ports (8080→443).
- Add any Environment variables as key/value rows.
- Click Deploy to
. The app lands in the fleet list on its target server.
What else you can do
Section titled “What else you can do”- Switch views — toggle between Containers (the default roll-up) and Resources (images, volumes and networks across the fleet, with reclaimable-space hints).
- Filter and search — search by container, image or stack name; filter by status (All / Running / Stopped / Restarting) and by server.
- Work a stack — each compose project is one expandable card showing its member services, aggregate CPU/memory, and status. Expand it to Start all, Stop all, Redeploy, or Remove the whole stack.
- Open a container — click any container for a detail drawer with quick Start / Stop / Restart / Recreate, an environment editor, and Remove.
- Open in server — jump straight to that server’s Apps tab, where the deep, streaming operations live (logs, exec, build-from-git, releases, rollback, resource prune).
How it works
Section titled “How it works”Apps is a fleet roll-up: it aggregates the Docker state of every connected server
into one list, grouping containers by their compose project (stack) and leaving
truly standalone containers on their own. The quick actions dispatch per-server jobs to
each box’s agent, which runs them natively (never through a website’s tooling):
| Action | Job kind | Agent runs |
|---|---|---|
| List containers | docker.status | docker status --json |
| Start / Stop / Restart | docker.start / docker.stop / docker.restart | docker start|stop|restart <container> |
| Deploy a single app | app.create | app create <name> --domain … --image … |
| App lifecycle | app.start / app.stop / app.restart / app.delete | app start|stop|restart|delete <name> |
| List / deploy stacks | stack.list / stack.deploy | stack list --json · stack create <name> … |
| Stack lifecycle | stack.up / stack.down / stack.restart / stack.delete | stack up|down|restart|delete <name> |
State lives on each box (Docker’s own store plus MZPanel’s app/stack metadata under the agent) — the control plane doesn’t mirror it. There is no separate database of containers; the fleet view is assembled from what each agent reports.
CLI & automation
Section titled “CLI & automation”Docker workloads run on a single box, so the on-box mz CLI is the automation
surface — SSH into that server and run the same commands the dashboard dispatches, or
let an on-box AI (ClaudeCode) drive them:
mz docker status --json # every container on this boxmz app start <name> # start / stop / restart a single appmz app stop <name>mz stack list --json # compose stacks on this boxmz stack up <name> # bring a stack up / downmz stack down <name>Always pass a sub-action (bare mz app / mz stack errors) and --json for machine
output. See The mz CLI and the
command catalog.
For fleet-wide automation across servers from your own tooling, the control-plane job API is available on the Max plan — see the API reference.
Gotchas & troubleshooting
Section titled “Gotchas & troubleshooting”- Preview UI today. The fleet roll-up currently renders a representative Docker
slice so the layout and actions can be reviewed end to end; it is not yet wired to
live agent data. The engine underneath is real —
mz app/mz stackand thedocker.*/app.*/stack.*jobs run natively on the box — so the commands in CLI & automation work today even while the dashboard view is a preview. - Docker needs Pro+. On Free/Plus the section is unavailable; upgrade to run containers. See Tiers & quotas.
- Offline servers still list, actions don’t. A box’s last-known containers stay visible when its agent is offline, but start/stop/deploy need the agent connected — the deploy drawer flags offline targets.
- Removing a stack removes every service. Remove on a stack card tears down all of its member containers; remove a single container from its detail drawer instead if you only want one gone.
- Resource prune is guarded. In the Resources view, only unused images/volumes and non-builtin, empty networks can be removed — anything a running container depends on is protected.
Related
Section titled “Related”- Docker apps & stacks — the full lifecycle: catalog, compose, env store, build-from-git, releases and the app proxy.
- Tiers & quotas — what Docker access each plan includes.
- The mz CLI — driving a box from the command line.