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.

Feature	Description	Required By
TUN/TAP Device	Enables /dev/net/tun inside the container for VPN and tunnel support	WolfDisk, Tailscale, WireGuard, OpenVPN
FUSE	Enables /dev/fuse for user-space filesystems	WolfDisk, AppImage, sshfs, rclone mount
Nesting	Run LXC or Docker inside the container	Docker-in-LXC, nested containers
NFS	NFS server/client support inside the container	NFS shares
Keyctl	Kernel key management for systemd support	Some systemd services

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.

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, pull, edit, logs and delete.