Proxmox Workloads

This section is where the platform stops being abstract and starts doing jobs.

Some services belong conceptually to Networking. Some belong conceptually to GPU and AI. Some are really application stacks with their own logic. But when the question becomes "how do I run this on Proxmox?" this is the right home.

If the workload is common and the immediate question is just "what is the fastest sane way to get this online?" start with Proxmox Helper Scripts before dropping into the more opinionated runbooks below.

What Belongs Here

• LXC or VM deployment guides that are specific to Proxmox
• hardware passthrough workflows tied to Proxmox guests
• application stacks whose instructions depend on Proxmox storage, networking, or guest management

In This Section

• Proxmox Helper Scripts - the first stop for community-scripts.org when you want the quickest sane Proxmox path before following a workload-specific runbook.
• Pi-hole LXC On Proxmox - the Proxmox-specific container build for the secondary Pi-hole instance after the networking design is already settled.
• TrueNAS SCALE On Proxmox - the path for moving a host-side naspool into a managed NAS VM with SMB, NFS, alerting, and a mirror-plus-spare layout.
• Kubernetes On Proxmox With k3s - the path when a single Docker-style guest stops being enough and the lab actually wants a small Kubernetes cluster with storage, ingress, and LAN-facing service IPs.
• GPU Passthrough On Proxmox - NVIDIA host setup, LXC passthrough, and the single- or dual-GPU layouts that make local AI workloads practical on Proxmox.
• GPU Power Management On Proxmox - persistence mode, boot-time reapplication, and the 250 W tradeoffs that keep dual-GPU hosts inside saner thermal and PSU limits.
• Open WebUI And Ollama On Proxmox - the fastest path to a usable local AI stack when you want the interface and the inference engine online without overthinking the separation.
• Open WebUI Standalone Frontend On Proxmox - the split-frontend path when inference already lives in dedicated Ollama or llama.cpp guests and the browser layer should stay light.
• llama.cpp Inference On Proxmox - the lower-level single-model path when control over GGUF models, build flags, and server behavior matters more than convenience.
• llama.cpp On Proxmox - the lower-level single-model path when control over GGUF models, build flags, and server behavior matters more than convenience.

• llama.cpp Router Mode On Proxmox - the multi-model path for one Open WebUI connection, on-demand loading, and a cleaner long-term inference setup.

• OpenClaw On Proxmox - the personal-assistant path that sits on top of Router Mode when the lab wants Telegram, Discord, scheduled workflows, and an always-on gateway.
• SearXNG LXC On Proxmox - the local metasearch backend for OpenClaw research and other retrieval-heavy workflows that should stop depending on public instances.
• Router Mode Deployment Example - the concrete deployment walkthrough for the dual-RTX-3090 Router Mode layout.
• Router Mode Deployment Example - the concrete deployment walkthrough for the dual-RTX-3090 Router Mode layout.

AI Workloads

The AI side of this section now breaks into five practical shapes.

One is for getting something working quickly. One is for peeling the browser layer away from the runtime once the split starts to matter. One is for taking direct control of the inference stack. One is for the point where a single model feels too limiting and the lab wants choice without manual restarts. One is for turning the same local model estate into an assistant.

Path	Best When	What You Trade
Open WebUI And Ollama On Proxmox	you want the shortest route to a usable chat stack	less control over the serving layer
Open WebUI Standalone Frontend On Proxmox	you already trust remote Ollama or llama.cpp backends and want the browser layer to stop carrying inference baggage	more moving parts between UI and inference
llama.cpp Inference On Proxmox	you want direct control over GGUF models and runtime tuning	more manual setup and maintenance
llama.cpp On Proxmox	you want direct control over GGUF models and runtime tuning	more manual setup and maintenance
llama.cpp Router Mode On Proxmox	you want multiple models behind one endpoint and one UI connection	more planning around VRAM, presets, and lifecycle
OpenClaw On Proxmox	you want a mobile-first assistant that uses the local model stack through Telegram, Discord, and scheduled workflows	more channel, daemon, and exposure plumbing

Once inference already lives elsewhere, the standalone Open WebUI page is the browser-first split. Once Router Mode exists and the lab wants an assistant rather than one more browser tab, OpenClaw is the follow-on path.

Once the assistant starts leaning on repeatable retrieval rather than one-off manual browsing, SearXNG LXC On Proxmox becomes a supporting service worth treating as part of the stack instead of an afterthought.

NAS And Shared Storage

This is the other workload shape that eventually stops feeling optional.

At first it looks like a storage detail. In practice it becomes the point where Proxmox guests, backup jobs, Time Machine, media storage, and shared model directories either stay loosely coordinated or finally get a dedicated home.

If the host is still using a direct naspool, start with Storage And ZFS. If the plan is to move that role into a managed NAS VM without buying separate hardware first, use this cluster:

• TrueNAS SCALE On Proxmox - the overview for when the host-side pool should become a managed NAS tier.
• TrueNAS VM Build And Pool Design - resource reallocation, VM creation, passthrough, and the mirror-plus-spare pool layout.
• TrueNAS Shares And Proxmox Integration - NFS, SMB, Proxmox storage integration, shared model mounts, and boot ordering.
• TrueNAS Protection, Verification, And Failure Handling - snapshots, SMART checks, UPS integration, hot-spare behavior, and recovery drills.

Kubernetes And Container Orchestration

Sometimes the workload really does want Kubernetes semantics, but that still does not mean the Proxmox host should become the cluster.

If the plan is to keep Proxmox as the infrastructure layer and run orchestration inside dedicated VMs, start with the k3s cluster below. If the job is still one application guest and a simpler container stack, stay with the lighter VM or LXC paths instead.

• Kubernetes On Proxmox With k3s - the overview for when the lab wants a real cluster boundary instead of one more handcrafted guest.
• Kubernetes VM Build And k3s Bootstrap - VM creation, Debian preparation, control-plane install, worker joins, and workstation access.
• Kubernetes Storage, Ingress, And Exposure - Longhorn, Traefik, MetalLB, and cert-manager.
• Kubernetes Verification, Upgrades, And HA - end-to-end testing, upgrade discipline, troubleshooting, and the optional HA control-plane path.

Secure Service Exposure

Several workload pages eventually hit the same question: how should this service actually leave the house?

That decision is now grouped here so Open WebUI, Pi-hole, Grafana, Prometheus, and the rest do not each grow their own slightly different HTTPS explanation.

• Secure Service Exposure On Proxmox - the decision hub for tunnels, reverse proxies, and certificate strategy.
• Cloudflare Tunnel On Proxmox - the outbound-only path when you want remote access without opening inbound ports.
• Nginx Reverse Proxy LXC On Proxmox - the self-hosted reverse-proxy path with a dedicated guest and wildcard certificates.
• SAN Certificates On Proxmox With Certbot - the grouped-certificate middle ground when wildcard feels too broad but one certificate per service still feels excessive.
• Individual Certificates On Proxmox With acme.sh - the tighter certificate-isolation path once wildcard no longer feels like the right blast radius.

What Does Not

Pure concepts still belong in their own sections.

DNS theory belongs in Networking. GPU compute concepts belong in GPU & AI. General virtualization theory belongs in Virtualization.

This section exists for the Proxmox-specific execution layer on top of those ideas.