Ask around in any Proxmox homelab forum how someone got Jellyfin, Uptime Kuma, or Vaultwarden running in ten minutes flat, and the answer is almost always the same: they pasted one line into the Proxmox shell and let a script do the rest. That script came from a project most people just call "the community scripts" — a free collection of installers that build and configure an LXC container for you, instead of you doing it by hand, template download and all.
If you've spent an evening manually creating a container, installing Debian packages one by one, and hunting down the right config file for whatever app you're trying to run, this is the shortcut you've been missing. It won't replace understanding Proxmox itself, and it isn't magic — you're still running someone else's shell script with root access, which is worth taking seriously. This guide covers what the project actually is, how to use it safely, and where it can bite you if you're not paying attention.
What You Will Learn
- What the Proxmox VE Community Scripts project is and where it came from
- How the one-line install commands actually work under the hood
- The difference between Default and Advanced setup modes
- How to install an app, check on it afterward, and update it later
- The security tradeoff you're making every time you pipe a script into bash
- Common mistakes and error messages, and what to do about them
What Is This Feature?
Proxmox VE Community Scripts (the GitHub repository is community-scripts/ProxmoxVE) is a library of shell scripts that automate the boring part of self-hosting: creating an LXC container, installing an application inside it, and wiring up the basic configuration so it actually runs. The project covers several hundred apps, from media servers like Jellyfin and Plex, to home automation tools like Home Assistant and Node-RED, to databases, monitoring dashboards, and developer tools like Gitea and Portainer.
It didn't start out this organized. The project traces back to a single developer, tteck, who published a handful of these installers a few years ago and they took off in the homelab community. It's now maintained by a small core team and a much larger group of contributors under the community-scripts GitHub organization, with a proper website at community-scripts.org where you can search for an app and copy its install command directly.
Quick refresher if containers are new to you: LXC stands for Linux Containers, and it's the lightweight virtualization option built into Proxmox VE. Unlike a full virtual machine, an LXC container shares the host's Linux kernel instead of booting its own copy, so it starts in a couple of seconds and uses a fraction of the RAM and disk a VM would need for the same job. Most of these scripts default to an unprivileged container — meaning root inside the container isn't actually root on your Proxmox host, which limits the damage if the app inside ever gets compromised.
Under the hood, every install script in the collection is a thin wrapper around a shared library called build.func. That's what draws the text-based menu you see when you run a script, handles picking a container ID, and applies whatever CPU, RAM, and disk settings you choose before handing off to the app-specific install steps. You don't need to know this to use the scripts, but it explains why every single one feels the same to use even though they install completely different software.
Why Would You Use It?
The honest answer is time. Setting up something like Vaultwarden — a self-hosted password manager — by hand means creating a container, installing Rust or grabbing a prebuilt binary, setting up a reverse proxy for HTTPS, and configuring a systemd service, and that's assuming nothing goes wrong. The community script does all of that in about two minutes and asks you maybe four questions along the way.
There's a real learning angle too, if you use it right. A lot of beginners run a script once to get something working, then open the container with pct enter and poke around to see how it was put together — what user the service runs as, where its config lives, how the reverse proxy is set up. Reading someone else's working setup teaches you things a blank Debian install never will.
I'd push back a little on treating this as a replacement for actually learning Proxmox, though. If you only ever run other people's scripts, you'll eventually hit a situation the script doesn't cover — a weird network setup, a storage backend it doesn't expect, an app version it hasn't caught up to yet — and you'll be stuck without the fundamentals to work through it. Use these scripts to save time on the tedious parts, not as a substitute for understanding what a container actually is.
And the caveat that matters most: every one of these commands works by piping a script straight from the internet into bash, running as root. That's an enormous amount of trust to hand a maintainer you've probably never heard of. The project has a real team behind it, an MIT license, and a public repository you can inspect, which puts it in a much better position than some random gist — but "well-known" isn't the same as "risk-free." More on that in a minute.
Prerequisites
- A working Proxmox VE host on version 8.4 or any 9.x release (this guide was tested on 9.2) — the project explicitly supports these versions
- Root shell access, either through the Proxmox web console or SSH
- An internet connection on the Proxmox host itself, since the scripts download a container template and packages during install
- At least a few GB of free storage — most containers default to a small disk, but some apps (media servers especially) need more
- Ten minutes and a specific app in mind — browsing community-scripts.org beforehand helps, since not every app has a script
Step-by-Step Tutorial
1. Check your Proxmox VE version
Open a shell on your Proxmox node and run:
pveversionYou're looking for something like pve-manager/9.2... in the output. If you're on an older 7.x install, most of these scripts won't run correctly — it's worth updating Proxmox itself first.
2. Find the app you want on the community-scripts site
Go to community-scripts.org and search for the app by name. Each script's page lists what gets installed, the default CPU/RAM/disk allocation, and any post-install notes specific to that app — worth a quick read before you run anything.
3. Copy and run the install command
Every script page gives you a one-line command that looks like this pattern (using Uptime Kuma, a self-hosted status page tool, as the example):
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/uptimekuma.sh)"Paste it into your Proxmox shell and press Enter. A text menu opens almost immediately, asking whether you want Default or Advanced settings.
4. Choose Default or Advanced
Default picks sensible resource values — usually a small number of CPU cores, a modest amount of RAM, and enough disk for the app to run comfortably — and asks almost nothing else. Most installs finish in under five minutes this way.
Advanced lets you set the container ID, hostname, CPU cores, RAM, disk size, storage location, network bridge, and whether the container is privileged or unprivileged, before anything gets created. Pick Advanced if you already have naming conventions or a specific storage pool you want the container on — otherwise Default is fine for a first try.
5. Let it finish and note the details
The script creates the container from a Debian template, installs the app and its dependencies, and configures whatever's needed to get it running — a database, a reverse proxy config, a systemd service, depending on the app. When it's done, it prints the container's IP address and, for apps with a login, any auto-generated password. Copy that password somewhere safe; it's often shown exactly once.
6. Open the app
Point a browser at the IP address and port the script gave you. Most web apps land on a standard port like 3000, 8080, or 443 depending on what they are — the script's final output line tells you exactly where to go, so there's no guessing involved.
7. Check it in the Proxmox UI
Back in the Proxmox web interface, you'll see the new container listed under your node with its assigned ID. Click into it, check the Summary tab to confirm it's using roughly the resources you expected, and set Start at boot under Options if you want it to come back automatically after a host reboot.
Commands Explained
| Command | What it does |
|---|---|
bash -c "$(curl -fsSL <script-url>)" | Downloads the install script from GitHub and runs it in the current shell immediately — this is the pattern every community script uses |
pveversion | Prints your installed Proxmox VE version, so you can confirm the scripts support it before running one |
pct list | Lists every LXC container on the host along with its ID, status, and name — useful right after an install to confirm the new container exists |
pct enter <CTID> | Opens a root shell directly inside a container without needing SSH or a password, handy for poking around after a script finishes |
pct config <CTID> | Shows the full configuration of a container — CPU, RAM, disk, network settings — so you can see exactly what the script set up |
Common Errors
"Unable to resolve host" or the download just hangs. The Proxmox host itself doesn't have internet access, or DNS isn't configured correctly on it. Test with ping github.com from the shell — if that fails, the fix is in your host's network setup, not the script.
The menu appears but nothing responds to keyboard input. This usually happens when you're running the command through certain SSH clients or terminal multiplexers with unusual key handling. Try running it from the Proxmox web UI's built-in Shell instead — it's the most reliable option for these interactive menus.
Script fails partway through with "storage 'local-lvm' does not exist." Not every Proxmox host uses the same storage names. If you renamed your storage or set up something custom, choose Advanced mode instead of Default so you can pick the right storage target explicitly.
Container is created but the app inside never starts. Check the app's own logs before assuming the script failed — pct enter <CTID>, then look at journalctl -u <service-name> -n 50 for whatever service the app runs as. A lot of "the script is broken" reports turn out to be a port conflict or a resource limit the app hit after install.
Troubleshooting
If a script errors out immediately with something about a missing template, it's often because the container template it needs hasn't been downloaded to your storage yet. Most scripts handle this automatically, but on a very fresh Proxmox install with no templates cached, the first run can take noticeably longer while it fetches one — that's expected, not a failure.
When an install seems to succeed but the app is unreachable, confirm the container actually got an IP address first. Run pct enter <CTID> and then ip a inside it — if there's no address on the container's network interface, the problem is almost always the bridge selected during setup, not the app itself. Double-check it matches the bridge your other working VMs and containers use.
For anything specific to the app rather than the container, most script pages on community-scripts.org list a few known issues and their fixes near the bottom. It's worth a search there before assuming you've found a new bug — a surprising number of "broken" reports turn out to already have a documented answer.
Best Practices
Read the script before you run it, at least the first time you use one for a new app. The URL in every install command is a plain text file — open it in a browser and skim it. You don't need to understand every line, but you should be comfortable with what it's doing before handing it root access.
Snapshot before you experiment. Once a container is running, take a Proxmox snapshot before poking around inside it or running an update. If something breaks, rolling back takes seconds instead of a full reinstall.
Don't run install scripts from anywhere except the official community-scripts/ProxmoxVE repository. Copies and forks show up on forums and video descriptions, sometimes outdated, occasionally modified in ways you wouldn't want. Bookmark the official site and use that.
Keep containers backed up like anything else on your host — vzdump or Proxmox Backup Server both work fine on these containers, since as far as Proxmox is concerned they're ordinary LXC containers once created. The script doesn't do anything to exempt them from your normal backup routine.
Give resource-heavy apps more than the Default allocation up front. A media server or a database will outgrow the conservative defaults quickly under real use — it's easier to size it right in Advanced mode than to resize a disk and adjust RAM later.
Frequently Asked Questions
Is this an official Proxmox feature?
No. It's an independent, community-maintained project, unaffiliated with Proxmox Server Solutions GmbH. It just targets Proxmox VE as its platform.
Are these scripts safe to run?
They're maintained by an active team, open source under the MIT license, and widely used, which is about as reassuring as a community project gets. But you're still running root-level shell scripts from the internet, so treat that with the same caution you'd give any third-party install script — read it first if you're at all unsure.
Can I update an app after installing it this way?
Yes. Most containers include an update helper you can run from inside the container, and re-running the original install command against an existing container ID typically detects it and offers to update rather than reinstall. Check the specific app's script page for its exact update method.
What if the app I want doesn't have a script?
Then you're back to a manual install — create the container yourself and set it up by hand, or check the project's Discussions page to request the app. Not everything self-hostable has a script, and that's fine; this is a convenience layer, not a complete substitute for knowing how to build a container from scratch.
Do these scripts work on Proxmox Backup Server or Proxmox Mail Gateway too?
No — they're built specifically for Proxmox VE and assume the pct and qm tooling that comes with it. Running one against a different Proxmox product isn't supported.
Conclusion
Once you've used one of these scripts, it's hard to go back to setting up a simple self-hosted app the long way. A one-line command, a couple of menu choices, and two or three minutes later you've got a running container instead of an evening lost to dependency errors.
Just don't let the convenience turn off your judgment. Skim the script before you run it, snapshot before you change anything, and keep your containers backed up the same way you would if you'd built them by hand — because as far as Proxmox is concerned, that's exactly what they are.