Watch: creating a container, option by option

A full walkthrough of the create screen — template and variant, name, root password, memory and CPU limits, notes, storage, bind mounts, and every networking mode. The written steps are below.

Overview

WolfStack provides comprehensive container management for both Docker and LXC containers. Create, start, stop, restart, clone, and migrate containers across your entire fleet from a single dashboard.

Docker Containers

• View all running Docker containers with live CPU, memory, and network stats
• Start, stop, restart, and remove containers
• View real-time container logs
• Open a web terminal (shell) into any container
• Pull images and create containers from the App Store
• Manage Docker volumes and networks

LXC Containers

• Create system containers from downloadable templates
• Full lifecycle management: start, stop, freeze, unfreeze, destroy
• Clone containers locally or across nodes
• Migrate containers between servers in one click
• Edit container configuration directly
• Assign WolfNet IPs for cross-node communication
• Set CPU, memory, and disk resource limits
• Autostart containers on boot

Creating an LXC container

1. In the sidebar, click the node you want the container to run on, then choose LXC.
2. Click Create Container at the top of the list.
3. Pick a distribution template — Debian, Ubuntu, AlmaLinux, Alpine and more are downloaded on demand the first time you use them.
4. Give the container a name (this becomes its hostname), and set memory and CPU limits if you want to cap them — leave them blank for no limit.
5. Optionally tick Start after create and Start on boot.
6. Click Create. The container appears in the list within a few seconds; use the Start button if you didn’t auto-start it.

Container DNS

WolfStack rewrites an LXC container’s network config each time it starts it, so the container comes up on the address you chose rather than DHCP’ing over it. That rewrite keeps the resolvers the container is already using — it only falls back to public DNS (1.1.1.1 / 8.8.8.8) when the container names no nameserver at all.

To pin resolvers instead, open Settings → Network and fill in DNS → Nameservers (and optionally Search Domains). WolfStack then writes those into every network backend the container ships — /etc/resolv.conf, /etc/network/interfaces, systemd-networkd, netplan and NetworkManager — and, on a DHCP interface, tells the client to ignore the lease’s DNS so your choice survives every renewal. On a Proxmox CT the value is stored in the container’s own nameserver: / searchdomain: fields, so it round-trips with the Proxmox UI. Leave the fields blank to go back to “keep whatever the container uses”. No chattr +i needed.

Where the container runs its own resolver — a /etc/resolv.conf symlinked to systemd-resolved or resolvconf — WolfStack leaves that file alone unless you have pinned nameservers explicitly.

How container networking is assigned

Each container automatically gets a bridge IP on the lxcbr0 bridge. When WolfNet is enabled, containers also receive a WolfNet IP (10.10.10.x) for encrypted cross-node communication — the bridge IP’s last octet matches the WolfNet one for easy identification. To put a container on a VLAN or vSwitch instead, open its Settings → Network tab and pick the uplink; see Networking.

Deploying a Docker container

The fastest route is the App Store — 530+ pre-packaged apps you deploy in one click. To run an arbitrary image yourself:

1. Open the node in the sidebar and choose Docker.
2. Click Create Container (or Deploy from Compose to paste a docker-compose.yml).
3. Enter the image (for example nginx:latest), a name, and any port mappings, environment variables and volumes the app needs.
4. Choose a restart policy — unless-stopped is the usual choice for a service you want back after a reboot.
5. Click Create. WolfStack pulls the image if it isn’t present and starts the container.

Every container row has Logs, Terminal, Stats and a Settings dialog for changing resources, networking and restart policy after creation.

LXC Container Features

WolfStack lets you toggle advanced LXC features from the container's Settings page. These are applied to the container configuration and take effect on the next start.

Cloning & Migration

Clone creates a copy of a container on the same node. Migrate moves a container to a different node in the cluster — WolfStack handles the file transfer, IP reassignment, and route configuration automatically.

Migration works across clusters too (a one-time transfer token authorises the push), and between Proxmox and native nodes in either direction — the container’s hostname, memory and CPU limits, autostart flag and network settings all travel with it. The migrate dialog lets you pick the destination bridge and rename the container, and a name clash on the destination is caught up front — before anything is stopped, so a rejected migration costs no downtime.

To keep an LXC container running through a node failure instead of moving it on demand, see WolfHA High Availability — standby copies that replicate on a schedule and fail over with the same name, MAC and IP.

Card View

Every container and VM screen supports a card view as an alternative to the default table view. Toggle between the two layouts using the view switcher at the top of the page — your preference is saved per screen.

• SVG pie charts — Each card displays live CPU, RAM, and disk usage as small SVG pie charts for at-a-glance resource monitoring
• Responsive layout — 4 cards across on desktop, 2 on tablet, 1 on mobile
• Available everywhere — Card view works on Docker, LXC, and VM screens
• Per-screen preference — Switch the Docker screen to cards while keeping LXC as a table, or vice versa — each screen remembers its own setting

Additional Features

vSwitch VLAN networking

An LXC container’s network-interface editor can put the container straight onto a provider vSwitch (Hetzner vSwitch, OVH vRack, generic 802.1Q). Pick a vSwitch uplink NIC from the dropdown and enter the VLAN ID — WolfStack creates the tagged sub-interface and bridge if they don’t exist and attaches the container, with no separate Networking-page step. Each interface row also has a delete button, so a NIC can be removed and is dropped when you save. See Networking for the full vSwitch model.

VNC Desktop Access

One-click VNC into any running Docker, LXC, or Proxmox-LXC container. WolfStack detects the container's OS (Debian/Ubuntu, Alpine, RHEL/Rocky/Fedora), probes for an existing desktop environment (Cinnamon, MATE, GNOME, KDE, XFCE, LXQt, LXDE, Openbox, Fluxbox, IceWM, i3) and lets you choose:

• Full Desktop — install TigerVNC + XFCE4 (~450 MB on Debian-family, ~30 MB on Alpine).
• VNC Only — install just TigerVNC + a fallback xterm and reuse whatever desktop is already in the container. Recommended when the container already has a DE (e.g. Linux Mint, Ubuntu Desktop, Kubuntu).

The install runs live in a console tab so you can watch it. Once installed, the WebSocket bridge tunnels VNC through WolfStack's port 8553 — works behind Cloudflare, corporate proxies, or any environment that restricts traffic to well-known ports. No port publishing on the container, no firewall rules, no per-user VPN.

Distro coverage

• Debian / Ubuntu — pulls tigervnc-standalone-server, tigervnc-common, and tigervnc-tools (the latter provides vncpasswd).
• Linux Mint — an apt preferences file at /etc/apt/preferences.d/wolfstack-mint-fix.pref pins the Mint repo below Ubuntu so XFCE/GTK packages resolve against the Jammy base. Works around the linuxcontainers.org Mint 22.x (Wilma / Xia / Zara / Zena) LXC images that mix a Jammy base with Mint’s Noble-targeted repo.
• RHEL / Rocky / Fedora — pulls tigervnc-server + tigervnc (which provides vncpasswd).
• Alpine — minimal install with TigerVNC.

Multi-strategy startup so the install actually starts a session

• Strategy 1 — tigervncserver Perl wrapper reading geometry/security/password from /root/.vnc/config. The config-file approach sidesteps the version-dependent CLI flag churn (-localhost, -PasswordFile vs -PasswordFile=) that bites different distros.
• Strategy 1b — vncserver on RHEL-family installs that don’t ship the TigerVNC wrapper.
• Strategy 2 — direct Xvnc with WolfStack spawning xstartup itself. Bypasses the Perl wrapper entirely, no xauth/cookie shenanigans, no per-distro flag quirks.
• LXQt fallback — if the chosen desktop’s package set is unsatisfiable on a broken LXC template (e.g. Mint Zena’s GTK t64 transition vs Jammy libc6 2.35), WolfStack installs LXQt instead and tells you so.
• xterm last resort — if no desktop installs cleanly, xstartup still launches an xterm so the session isn’t a black screen.

Admin user & failure diagnostics

• Admin user auto-creation — if no non-root user exists, an admin account is created and added to sudo (Debian/Ubuntu) or wheel (RHEL). The VNC session runs as that user because GNOME / KDE / Cinnamon refuse to run as root.
• Idempotent install — re-running the install on an already-set-up container reinstalls cleanly without breaking the existing session.
• Diagnostics on failure — if Strategy 1 + 1b + 2 all fail to bring up port 5901, WolfStack captures the start-up log and surfaces it in the modal so you see the real error rather than a swallowed exit code.

Docker Compose Stacks

A full Compose manager lives alongside single containers: create stacks in a built-in YAML editor (or import an existing docker-compose.yml), validate, bring them up/down, restart, pull, and tail logs — per stack, per node. The stacks directory is configurable in Settings → File Locations, so WolfStack can adopt the compose layout you already have.

Secrets in Compose New in v24.37

Stop pasting passwords into YAML. Store them once in the Secrets Manager (linked from the Compose page), then reference them in any compose file as ${KEY}:

environment:
  - MYSQL_ROOT_PASSWORD=${DB_PASSWORD}

WolfStack injects the value when the stack is deployed — it never gets written into the stack folder or a .env file, and secrets are stored encrypted on the node the stack runs on. Names that could change how Docker itself behaves (PATH, DOCKER_HOST, …) are refused outright.

Export and import secrets

The Secrets page has Export and Import buttons. Export writes every secret on the node to one JSON file encrypted with a passphrase you choose (Argon2id key derivation, AES-256-GCM; twelve characters minimum). Import takes that file plus the passphrase on any other node and merges the entries: new keys are added, identical keys are reported as unchanged, and keys that already exist with a different value are left alone unless you tick Replace values of keys that already exist. A wrong passphrase, or a file that has been altered, is refused outright — there is no partial import. Keep the file with whatever else you copy for a standby or a rebuild; without it, a stack on the new host starts with blank credentials.

Deploy a stack to another node

Each stack on the Compose page has a Deploy to node action. Pick another WolfStack node in the cluster and WolfStack copies the stack directory to it — the compose file, .env (written mode 0600 on the target) and any other regular files up to 1 MB each and 16 MB in total; larger files and symlinks are skipped and listed in the result, because bind-mounted data is not the stack and is not what a deploy should move. It then adds the Secrets Manager entries the compose file references to the target's Secrets Manager (replacing a stale value of the same name, since the point is that the stack works there), and, unless you untick Start, runs docker compose up -d on the target and shows the same report the Up button gives — including any ${KEY} that still resolved to an empty string. A stack of the same name already on the target is not touched unless you tick Overwrite, and an overwrite replaces files by name without deleting extra files the target already had. The deploy waits up to fifteen minutes for the target's image pulls.

Stacks are not started by the WolfStack daemon

WolfStack never runs docker compose up on its own at daemon start. Containers that already exist come back through Docker's own restart policy, so on an established host a reboot restores every stack without WolfStack's help. On a host where a stack's containers have never been created — a standby that only received the compose directory, or a node rebuilt from a copy of it — nothing will start them until you press Up on the Compose page (or run docker compose up -d in the stack directory). Up recreates only the containers whose definition changed; Recreate (docker compose up -d --force-recreate) rebuilds every container in the stack from the compose file, for the case where a container has drifted at runtime and Up sees nothing to do. Volumes are kept either way. To keep “the daemon is running” from looking healthier than it is, WolfStack checks once Docker is reachable after start-up and logs a warning naming every stack under the compose root that has no containers at all on this host.

Container Cron Jobs

WolfStack lets you manage cron jobs inside individual Docker and LXC containers directly from the dashboard. View, create, edit, and delete crontab entries without needing to shell into the container.

Update Checks & Automatic Updates

For Docker containers, WolfStack periodically checks whether a newer version of each container’s image is available, and updates can be applied from the dashboard.

Updates can also be applied automatically. A background image watcher checks on a schedule and, for any container opted in, pulls the new image and re-creates the container:

• Per-container policy — auto-update is opt-in on each container, so you choose exactly which workloads track latest.
• Maintenance window — a cluster-wide window (cron schedule + duration) confines auto-applies to a time you pick; with no window set, updates apply as soon as they’re detected.
• Bounded concurrency — a parallelism limit (one at a time by default) stops a host with many containers being swamped by simultaneous image pulls.
• Audit history — every applied update is recorded, giving a full trail of what changed and when.
• Check for updates now New in v25.16.1 — the watcher sweeps on a staggered schedule (six hours minimum, spread across the fleet so your nodes never all query a registry at once), so after switching it on there is nothing to see until the first sweep. This button runs one immediately on the selected node. Enabling the watcher — by hand, by a settings push, or when a node adopts the cluster's settings after being offline — now also starts a sweep straight away instead of waiting for the next slot. A node with checks on but no results yet says so on its containers page, with the same action inline.
• Per-cluster settings New in v25.16 — the settings are stored on each node and propagate to that node’s cluster. On a fleet with more than one node, Settings → Alerts → Docker Updates starts with a Settings for picker listing every node grouped by cluster: choose a node to read its config and to aim Save Settings and Push to all nodes at that node’s cluster. Following the “disabled on this node” notice from a container page pre-selects the node it was shown on, so the cluster you were looking at is the one you configure.

Docker Image Management

• View all pulled Docker images on a node
• Pull new images from Docker Hub or private registries
• Search Docker Hub for images
• Remove unused images

Docker Network Management

• View Docker networks on each node
• Inspect network configuration and connected containers

Try this on your own servers

WolfStack is free for personal use and installs in about two minutes — one command, no agents, works on any Linux server or Raspberry Pi.

Running it at work? Commercial licences start small and fund development.

Adopting an existing Compose setup

If you already run Docker Compose stacks, you do not have to move them to use WolfStack.

• The Compose directory is configurable. Set it under Settings → File Locations → Compose Directory and point it at your existing compose root. Every <name>/docker-compose.yml beneath it immediately appears as a managed stack — that is the real “import my existing files” path, with nothing copied or moved.
• The App Store honours the same setting. Compose installs from the App Store read that one directory too, so the two can never drift apart or leave stacks stranded if you relocate the folder.
• Import a single file. The New Stack editor has an Import .yml button that loads a compose file straight from your computer into the editor and suggests a stack name from the filename — no copy-paste.

Once a stack is managed, the full set of operations is available per stack: up, down, restart, recreate, pull, edit, logs and delete.