Extensions

The Extensions section of a server (/servers/:id/extensions) is where you add optional software to a box — extra databases, caches, admin tools, runtimes and security packages — and manage what’s already there. The page itself is available on all plans; a few individual extensions need a higher tier to install (each card shows its minimum plan).

Extensions answer “what software is installed on this box.” That’s a different layer from Services (“is it running”) and Apps (“Docker workloads”) — so something like Redis intentionally shows up in more than one place.

Install an extension, step by step

1. Switch to the Available tab (the toolbar’s second segment) to see everything you can add, or search / filter by category to narrow the list.
2. Click Install on a card to open its drawer. You’ll see the extension’s facts (category, minimum tier, footprint) and any Prerequisites — for example pgAdmin needs Docker and PostgreSQL installed first.
3. For a web-served extension (pgAdmin), optionally set a Domain to serve it at — leave it blank to use the default. Point that domain at the server in DNS & TLS so it resolves.
4. Click Install. The installer runs on the agent and its output streams live into the drawer, line by line, ending in a success or failure state. When it’s done the card flips to Installed.

Some extensions install themselves

Runtimes like Node.js, Go and Python are detect-only — they show up as installed after you create a site of that type (they read Via site until then), so there’s no Install button for them here.

What else you can do

• Installed / Available tabs — the top toolbar toggles between what’s on the box and what you can add, each with a live count.
• Search and filter by category — full-text search plus a category dropdown (Databases, Cache, Containers, Database Tools, Runtimes, Security, Monitoring, …).
• Manage an installed extension — click Manage to open the all-in-one hub: facts, live runtime vitals (status, PID, memory, uptime), an Auto-start on boot toggle, and Start / Stop / Restart controls for service-backed extensions.
• Tune it inline — extensions with a real config surface get a Configuration tab: MariaDB (buffer pool, connections, durability, slow-query log — with a hardware-derived recommended value you can click to fill), Redis (max memory + eviction policy) and UFW (firewall on/off).
• Read its logs — service-backed extensions get a Logs tab showing the systemd journal tail.
• Jump to where it’s configured — packages configured elsewhere deep-link out: Docker → Apps, PostgreSQL / MongoDB → Databases, BIND9 → Nameservers.
• Manage PHP versions — the PHP card opens its own hub: the installed versions list, set-default, restart FPM, and open a version’s full config.
• Remove it — the trash action arms an uninstall. Destructive removes (which drop data or a protection layer) require you to type the extension id to confirm; MariaDB additionally offers Back up all databases first.
• Marketplace — the toolbar’s Marketplace button opens the fleet catalog to browse and install across every server at once.

How it works

Everything on this page runs through the server’s agent, which does the work natively (no shell-out to a legacy CLI):

Action	Job	Agent does
List installed	extension.list	reads the pushed extensions inventory
Install	extension.install	runs the installer, streaming progress lines
Remove	extension.remove	uninstalls (optionally --backup for MariaDB)
Update	extension.update	updates the package in place
Start / stop / restart / boot	service.action	drives the systemd unit
Read logs	service.logs	tails the unit’s journal

The card list is cache-first: it reads the agent-pushed extensions inventory, so an offline box still shows its last-known installed software instead of an empty view. The agent re-pushes that inventory after every install / remove / update and on its periodic sweep. Install and remove don’t return JSON — they emit the same plain [mz] … progress lines the CLI prints, which is what streams into the drawer.

The list of extensions, their categories, minimum tiers and prerequisites come from a shared manifest, joined per-server with the live installed / version / running state. There’s no separate MZPanel-side record of “what’s installed” — the box is the source of truth.

CLI & automation

Every action maps to an mz extension 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 extension list --json            # installed / version / running per extension
mz extension install redis          # install; progress streams to stdout
mz extension update netdata         # update a package in place
mz extension remove mariadb --backup # remove; dump all DBs first (MariaDB only)

The argv here is identical to what the panel dispatches. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• Base packages can’t be removed here. PHP, WP-CLI and process isolation power the panel itself — they show a note instead of a Remove action. Switch PHP versions in PHP settings instead.
• Destructive removes ask you to type the id. Removing an SQL/NoSQL engine destroys its databases; removing UFW or Fail2ban drops a protection layer. Those arm a type-the-id-to-confirm step. Only proceed if you understand the consequence — a cloud/network firewall should protect the box before you remove UFW.
• Removing Docker destroys everything in Apps. Every container, app/stack, image and named volume goes with it.
• pgAdmin needs its prerequisites. Install Docker and PostgreSQL first, or the Install button stays disabled with a “Needs …” hint.
• Extension locked behind a plan? The card shows Upgrade with the minimum tier when your workspace plan is too low. Pro unlocks Docker, pgAdmin, MongoDB, Netdata and more; Supervisor needs Plus.
• Agent must be online to change anything. Offline, the section renders the last-known list read-only and shows an “agent offline” state — install, remove and service controls need a live connection.
• Redis appears in Services too. That’s intentional: Extensions manages the package, Services manages the running process. They stay in sync.

Related

• Marketplace — browse and install across the whole fleet.
• Services — start/stop the daemons these extensions install.
• Apps — Docker containers and stacks (needs the Docker extension).
• Databases — where MariaDB, PostgreSQL and MongoDB are tuned.
• PHP — manage PHP versions and per-version settings.