Create Proxmox LXC From Web UI: The Safe, Complete Guide

To create Proxmox LXC from web UI used to mean opening the full Proxmox VE console, clicking through the container wizard, and hoping you picked the right storage and template. Stashboard collapses that into a single guarded form on the same dashboard you already use for Docker. This deep how-to walks through exactly how to create Proxmox LXC from web UI — and destroy one safely — covering every field on the New LXC form, the double safety gate that keeps the whole feature off by default, and how Stashboard polls the real Proxmox task so it tells you the truth about whether the container actually came up. Destroy landed in V6.13; create in V6.13.1.

New here? Start with the Stashboard self-hosted homelab dashboard overview, and read the manage Proxmox from a web dashboard pillar guide for the full surface. If you have already wired up Proxmox LXC update monitoring, you have everything you need to create Proxmox LXC from web UI in minutes. 🧩

Where create Proxmox LXC from web UI lives

The entry point is a New LXC button on the Proxmox page, next to the guest cards for a connected node. It only appears once the feature is switched on (see the gate below) — until then there is nothing to click, which is deliberate. Pressing it opens the New LXC modal: one scrollable form with sensible defaults already filled in, so the fastest path to create Proxmox LXC from web UI is to pick a template, set a hostname, and submit. Everything else has a working default you can leave alone.

⚠️ The double gate: both switches are OFF by default

Creating and destroying guests are the most dangerous things the dashboard can do, so each is double-gated and both gates ship OFF:

1. A server-wide master switch — Settings → Create guest (and a separate Destroy guest switch). Until you flip it, the capability does not exist for anyone, and the New LXC button stays hidden.
2. A per-host opt-in — Allow create (and Allow destroy) on the individual Proxmox connection. Enabling create globally still does nothing on a host you have not explicitly trusted for it.

⚠️ Both gates must be on before a single byte reaches Proxmox. If either is off, Stashboard returns a deterministic 403 before any API call is made — the request fails closed, never half-done. This is the same fail-closed model used everywhere else you can mutate a guest, so once you understand it once you understand it for create, destroy, clone, and restore alike.

The New LXC form, field by field

Here is every field you will touch to create Proxmox LXC from web UI, in the order they appear:

• VMID — pre-filled from the cluster’s next free id (Proxmox /cluster/nextid), so you normally leave it. Override it only if you keep a numbering scheme; a clash is caught (see 409 below).
• Hostname — the container’s name, shown on its card after creation.
• Template — a combobox populated from your vztmpl-capable storages (it lists the .tar.zst / .tar.gz templates Proxmox already has). Pick one from the list, or type a volid directly — e.g. local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst — if you keep templates somewhere the listing didn’t surface. This is the one field with no safe default; you must choose a template.
• Root password or SSH public key — set at least one so you can actually log in. Paste a public key for key-only access, or set a root password, or both.
• Cores / Memory / Swap — CPU core count, RAM in MiB, and swap in MiB. Defaults are modest (a single core, a small RAM allocation) and fine for most appliances.
• Rootfs storage + size — pick the storage for the root disk and its size in GiB. The storage dropdown is filtered to storages that can hold a container rootfs (see adding LVM-thin storage if your list is empty).
• Network (net0) — the full primary interface row: interface name (eth0), bridge (e.g. vmbr0), MAC (auto-generated if blank), IPv4 as DHCP or a static CIDR with a gateway, the same pair for IPv6, an optional VLAN tag, a rate limit, and a per-interface firewall toggle. It all maps straight to a Proxmox net0 string, so what you set here is exactly what the container gets.
• DNS — optional nameserver and search domain; leave blank to inherit the host’s settings.
• Options — Unprivileged (recommended, on by default), Nesting (the features flag you need to run Docker inside the LXC), Start at boot (onboot), Start after create, and Add to HA (register the new guest with High Availability).

These fields map one-to-one onto pct create, so there is nothing magic happening when you create Proxmox LXC from web UI — Stashboard just builds the call you would otherwise type by hand and hands it to the Proxmox API.

What submit actually does: 403, 409, 502, and the task UPID

When you submit, the request runs a strict sequence, and each failure mode is its own honest status code rather than a generic error:

• 403 — gate closed. If the master switch or the per-host opt-in is off, Stashboard refuses before any Proxmox call. Nothing is created, nothing is touched.
• 409 — VMID already in use. If the chosen id collides with an existing guest, you get a clean conflict instead of a confusing host-side failure. Bump the id and retry.
• 502 — the host rejected it. If Proxmox itself refuses (bad template volid, storage out of space, an invalid net0), Stashboard surfaces the host’s own error message verbatim as a 502 — you see what Proxmox said, not a swallowed stack trace.

If the call is accepted, Proxmox returns a task UPID — the id of the long-running create job. Stashboard polls that UPID to completion and reports the task’s real exit status, so a “started” is never mistaken for a “succeeded”. On genuine success it auto re-scans the node, and the new container’s card appears on its own — no manual refresh. That honest, end-to-end feedback loop is the whole reason it is responsible to create Proxmox LXC from web UI in the first place.

Destroying an LXC: stopped-guest check + double-confirm

Destroy (V6.13) is the mirror image, and it is deliberately harder to do by accident. Two guards stand in front of it:

• Stopped-guest check — you cannot destroy a running container. Stop it first; the action stays disabled until the guest is actually stopped, so there is no “destroy a live service” footgun.
• Double-confirm that names the target — the confirmation dialog spells out the exact guest (CT <vmid> · <name>) and node you are about to delete, and you commit with a separate, destructive Destroy container click. There is no one-click destroy from the card.

Like create, destroy is double-gated (Settings → Destroy guest + per-host Allow destroy, both OFF by default), runs through the same 403/UPID-polling path, and re-scans on success so the card disappears once the task really finishes. ⚠️ Destroy is irreversible — it removes the rootfs. If the data matters, snapshot or back up the guest first.

The audit tab

Nothing here is silent. Every create and every destroy attempt — successful or not — writes an audit row: who triggered it, when, which host and node, the target VMID, the action, and the outcome (success, or the verbatim error and status code). A 403 that never reached the host is logged just as plainly as a completed create. Creates land on the Create tab and removals on the Destroy tab, so when you create Proxmox LXC from web UI you always have a “who built or deleted what, when” trail on the Audit page to fall back on.

How to verify it works

• Flip Settings → Create guest on, then Allow create on the host — the New LXC button should appear. With either off, it should not.
• To create Proxmox LXC from web UI, submit a minimal container (template + hostname, defaults for the rest). Watch the task progress, then confirm the new card auto-appears after the re-scan.
• Cross-check on the host: SSH in and run pct list — the new VMID should be there with the hostname you set.
• Try creating with an in-use VMID on purpose — you should get a clean 409, not a host crash. Then stop and destroy the test container and confirm both the card and the audit row reflect it.

⚠️ Risks and edge cases

• No login set. If you skip both the root password and the SSH key, the container will create but you won’t be able to log in. Set at least one.
• Template volid typos. A hand-typed volid that doesn’t exist becomes a host-side rejection (502) — read the verbatim message; it’s usually “no such file”. Prefer picking from the combobox.
• Storage and capacity. A rootfs size larger than the storage can hold fails at the host, not in the form. Check free space on the chosen storage first.
• Destroy is permanent. The stopped-guest check and the named double-confirm exist for a reason — there is no undo once the task completes.

Bottom line

The ability to create Proxmox LXC from web UI turns “open the PVE console and click through the wizard” into one guarded form on the dashboard you already live in. Pick a template, set a hostname, accept the defaults, and submit — while a double gate that is off by default, deterministic 403/409/502 handling, real task-UPID polling, an auto re-scan, and a full audit trail keep it honest and safe. For the complete picture of everything the Proxmox surface can do, read the Proxmox web dashboard pillar guide. 🚀

Stashboard is open source — you can find the full source code on GitHub and pull the ready-to-run image directly from Docker Hub. Issues, PRs, and stars are always welcome. 🙌