0.79.1
Guides

Deploying an application

An application is a Compose file plus the things ProxDock adds around it: a ZFS dataset of its own, an address on a network zone, and a place in the backup schedule. This page walks a real deploy of a bundled template on a single-node cluster.

Every screenshot is a capture of the real thing. Addresses and MAC addresses in them are fictional; nothing else has been touched.

1. Pick a template, or bring your own

Containers is where applications live. On a fresh cluster it is empty.

The containers screen with no applications, offering to create one.
One list, and a detail panel that owns everything you can do about the selected application.

New application opens on the Compose tab, where you paste a file of your own. The other tab is the bundled library.

The new-application dialog on the Compose file tab, with an empty Compose editor and the deploy options beside it.
Paste anything here. The tab beside it fills the same form from a template instead.

The template gallery, a searchable grid of 38 application cards.
38 templates ship inside the binary, so a template is always version-matched to the ProxDock deploying it.

The search covers the name, the category and the description, so "uptime" and "monitoring" both find the same thing.

The gallery filtered to a single result by a search for "uptime".
Each card carries its category, which service faces the LAN, and how many settings it needs.

2. Fill in what it needs

Picking a template fills in the ordinary create form. Most templates need very little: a name, a node, and a zone.

The chosen template's form, showing the application name, target node, storage limit, LAN-facing service and network zone.
The LAN-facing service is the one that gets the zone address. Everything else in the stack talks to it over the per-stack internal bridge.

Uptime Kuma is a good example of why that field exists. The template deploys two services: Uptime Kuma itself, and a small Caddy front end that terminates TLS. Caddy is the one that faces the LAN, so it takes the address; Uptime Kuma is reachable only from inside the stack.

3. Read what it will do

The curated form deploys straight away. Open in the Compose editor takes the same template to the Compose tab with its file loaded, which is where the transformation preview lives.

The template's Compose file loaded into the editor, with the deploy options beside it.
The same file you would have pasted. Nothing about a template is special after this point.

Preview transformation shows every change before anything is written.

The transformation preview listing eleven changes, each with a path, a before and after, and the reason it was made.
Eleven changes for this template, each with the reason attached. No issues means nothing here needs a decision from you; warnings and refusals appear in that bar when they do.

Some of what it did here:

Change Why
restart set to no A restart policy would resurrect the app on a node it migrated away from
image pinned to a digest Tags move; the exact digest is resolved and pinned at deploy
networks split An internal bridge for peers, plus the zone for LAN reachability
mac_address set A pinned MAC keeps ARP and switch tables valid across migrations
volumes rewritten into the dataset Data must live in the application dataset to be backed up
The named volume declaration removed It has nowhere left to point

The other half of the preview is the file that comes out.

The rendered Compose file the transformation produced.
What actually gets written and handed to docker compose.

Compose files covers the rules in full, including what is refused outright.

4. Deploy

The form is replaced by a pane that streams docker compose's own output, so a slow image pull looks like a slow image pull rather than a hung dialog.

The deploying pane, streaming compose output as the images are pulled and the containers started.
Creates run detached. Closing the dialog does not cancel the deploy; Activity has it either way.

The containers screen with the application running.
The list carries identity and status only.

5. What you get

The application's Overview tab, showing uptime, CPU, memory, storage, last backup and the two running services.
A pure dashboard: no controls. The header carries the node, the address, the LAN-facing service and the derived MAC.

A dataset was created for it, with a baseline snapshot taken once it came up:

apps/apps/uptime-kuma
apps/apps/uptime-kuma@created

That snapshot is what a rollback returns to, and the dataset is what a backup sends.

The detail tabs

Each tab owns its concern completely rather than scattering it across pages.

The Compose tab, showing the rendered file for the running application.
Compose is the file as deployed, digests and all, not the one you pasted.

The Logs tab, streaming container output.
Logs streams from the containers. Long-running views like this one offer a pop-out to a chrome-less window.

The Shell tab, an interactive terminal attached to a container.
Shell attaches to a service. Opening one is recorded in the audit log with the user who did it.

The Storage tab, showing dataset usage and the snapshots taken so far.
Storage leads with usage against the limit, then the snapshots below it.

The Updates tab.
Updates re-resolves the image digests and shows what moved, with a snapshot taken before anything is applied.

The Migrate tab.
Migrate hands the application to another node. On a single-node cluster there is nowhere to send it.

Where to go next