PanelicaDocs
panelica.com
Docs / App Hosting / Docker Manager

Docker Manager

Panelica 1.0.375 Verified 2026-07-23 App Hosting

The Docker Manager turns the server's Docker engine into a multi-tenant app platform: a template catalog for one-click deployments, a full container/image/volume/network toolset, and a Flow canvas that draws your whole container estate as a live diagram you can operate directly. If Docker is not installed yet, the page installs it for you with a streamed, step-by-step setup.

Panel locationDocker Managerhttps://YOUR-SERVER-IP:8443/docker/manager
 Docker Manager
Overview Containers (6) Applications PHP Runtimes Library & Engine
Running
5
Stopped
1
Needs Attention
1
Disk Usage
18 GB
john-uptime-kuma stack: monitoringCPU 2% · RAM 180 MB · healthy

The layout

Ten views organized into role-aware groups: Overview (stats, your applications grouped by stack with live CPU/RAM bars, quick actions and a compact Flow preview), Containers, Applications (the template catalog, plus stack backups for admins), PHP Runtimes (ROOT: the legacy PHP 5.6-7.4 container images), and Library & Engine (images, volumes, networks, plus Docker Hub search and engine settings for ROOT). Everything deep-links by URL hash.

One-click apps: the template catalog

The catalog covers dozens of curated templates across thirty categories, each card showing its image, RAM minimum, ports and deploy count; multi-container apps carry a Stack badge. Deploying is a two-step form: name (with live uniqueness checking), image tag, port overrides (with reserved-port warnings), environment variables in three groups (required, secret credentials with show/hide, advanced), RAM/CPU limits and autostart, then a confirmation summary. Deployment runs as a background job, so you can keep working; a success dialog then hands you the access URL, the generated credentials and the post-install notes.

Behind the scenes: generated credentials are stored in an encrypted server-side vault, retrievable later from the container's Information dialog. Port conflicts are resolved by actually testing ports and walking upward from the template's default. Multi-container stacks get their own private network and a shared stack label, with service aliases preserved so containers find each other by name. If a mid-deploy step fails, everything created so far is rolled back. A Deploy Doctor watches the new container for its first minutes and surfaces the real error line if it crash-loops.

Container operations

Every container, in table or card view, carries one consistent action menu: start, stop, restart, pause/resume, web terminal (xterm.js; a root-shell variant for ROOT), logs with live follow, live stats with history charts, processes, inspect, rename, clone, environment editing (recreates the container), image update to a new tag, live CPU/RAM limit changes without recreation, healthcheck editing, mount management and volume attach, a container file manager (browse, edit, chmod/chown, upload, download, search; optional as-root mode), a connectivity test (ping, DNS and port checks from inside the container), stack-wide bulk env changes, a compose.yml export, and domain linking that publishes the container on a domain or subdomain through the panel's Nginx.

Update badges compare registry digests so you see "update available" without pulling. Bulk toolbars cover stop/start/restart-all and, for ROOT, delete-all behind a typed DELETE.

Multi-tenant isolation, concretely: every container carries its owner's identity as labels, and lists are filtered server-side by them. Customer containers run inside the owner's cgroup slice, with CPU/RAM requests capped by the hosting plan and templates' RAM minimums enforced as a floor. Non-root users get privileged mode and dangerous capabilities stripped, bind mounts jailed to their own home, and named volumes remapped under their home so disk usage counts against their quota. Domain links write the same backed-up, test-then-reload Nginx proxy used across the panel.

The Flow canvas

Flow draws the estate as a four-column diagram: domains, containers, networks and volumes, wired together as they really are, with live per-container CPU/RAM and network/disk rates on the nodes. It is an operating surface, not a picture: right-click actions open embedded panels (terminal, logs, processes, file manager and the whole management set) directly on the canvas, dragging a wire from a container's pins to empty space opens an in-canvas draft form that creates and connects a network, volume or domain in place, and the template rail on the left deploys into the same canvas. Owner lanes group containers per customer (collapsible, resizable, colorable), a minimap, node search, marquee multi-select with a bulk bar, eight wire styles and an auto-layout keep large estates navigable.

Reading a stack at a glance: a WordPress template stack shows the app container wired to its database through a private network node, the database's volume hanging below it, and the domain node in the first column pointing HTTPS at the app. When the database container's RAM bar runs hot, you right-click it and open stats or a terminal without leaving the diagram.

Stacks, backups and legacy PHP

The stacks view (ROOT/ADMIN) backs up whole multi-container applications: database dump, volume export and a compose definition in one archive, streamed with progress, downloadable at any size and restorable from file. PHP Runtimes (ROOT) manages the Docker-based legacy PHP 5.6-7.4 images used by the PHP subsystem, including per-version extension presets, custom Dockerfile snippets and build history with rollback.

Access

The whole manager sits behind the docker license feature; plans decide how many containers an account may run (0 disables Docker for the plan). The views themselves are role-aware (roles and permissions): a USER or RESELLER gets Overview, Containers and the app templates; images, volumes and networks are separate permission keys defaulting to administrators; and Docker Hub search, engine settings, the legacy PHP Runtimes, root terminals and delete-all are ROOT-only. Admins and resellers deploy on behalf of a chosen customer, must pick that owner, and everything a customer sees is scoped server-side to their own containers. Installing the Docker engine itself is a one-time ROOT action.

Panelica Documentation · Written and verified against the live panel. · Last verified 2026-07-23 on Panelica 1.0.375