Proxmox Community Helper Scripts and How to Run Them Safely

The tteck helper scripts you have run a hundred times still work, but the project you knew is gone: after tteck's passing in late 2024 the tteck/Proxmox repo was archived and the community forked it to community-scripts/ProxmoxVE, now 400+ scripts with weekly tagged releases. This post explains what those one-line LXC installers actually do under the hood, whether they are still safe post-handoff, and gives you a security-first workflow for piping bash into a root shell on your hypervisor. By the end you will have a repeatable process: read the script, pin a release, snapshot, test on a throwaway node, then run.

Key Takeaways

• New home: tteck's scripts live at community-scripts/ProxmoxVE; the old tteck/Proxmox repo is archived and frozen.
• What runs: a one-liner sources build.func, prompts for storage/CPU/RAM/network, then builds and provisions a full LXC on your node as root.
• Real risk: curl | bash as root on the hypervisor means arbitrary code on the box that controls every VM — read it before you run it.
• Safe path: pin to a tag or commit, snapshot first, test on a rebuildable node, and prefer unprivileged containers.
• Offline option: ProxmoxVE-Local self-hosts the whole catalog so you can review and run scripts air-gapped.

What happened to tteck's scripts?

tteck (Thomas) built the single most-used collection of Proxmox helper scripts in the homelab world — the one-liners that spin up Plex, Home Assistant, Pi-hole, or a Docker host in a container without you touching a template. After his passing, the original tteck/Proxmox repository was archived. Archived on GitHub means read-only: no new commits, no merged PRs, no security fixes. It still exists, and the old raw URLs still resolve, which is exactly why this matters — plenty of blog posts and YouTube videos point at dead raw.githubusercontent.com/tteck/Proxmox/... paths that will never be patched again.

The community regrouped under community-scripts/ProxmoxVE, hosted at community-scripts.github.io/ProxmoxVE (and the helper-scripts.com shortcut). It now carries 400+ scripts, a rotating group of maintainers, a real PR review process, and versioned releases you can pin to. The website generates the copy-paste command for each app, and each script page lists its default resources and source links.

The practical takeaway: audit your notes, your Ansible, and your cron jobs. Any automation still calling the tteck/Proxmox raw URLs is pulling from a frozen tree and should be repointed at community-scripts/ProxmoxVE.

What does a one-line installer actually do?

Here is a representative command from the current project:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/plex.sh)"

That is the whole trick, and also the whole problem: curl fetches a shell script over HTTPS and pipes it straight into bash running as root on your Proxmox node. There is no package manager, no signature check, no sandbox. Whatever the script says, your hypervisor does.

The build.func chain

The per-app script (ct/plex.sh) is thin. Near the top it sources the shared framework:

source <(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/misc/build.func)

So a single one-liner actually pulls in a second remote file, build.func, which is the real engine — several thousand lines that draw the whiptail menus, validate your Proxmox version, pick a storage pool, and call pct to create the container. The app script only defines variables (default CPU, RAM, disk, the Debian/Alpine base) and an install step that runs inside the new container to fetch and configure the actual software.

When you run it, build.func will:

1. Detect your Proxmox VE version (it supports the current 8.x and 9.x releases on Debian 12 "bookworm" / 13 "trixie") and refuse on unsupported releases.
2. Prompt you — default or advanced — for CT ID, hostname, disk size, cores, RAM, bridge, and whether the container is privileged.
3. Download the matching LXC template via pveam if it is not already on the node.
4. Create the container with pct create, start it, and run the app's install function inside it.

A typical Debian-based app CT lands around 1.5–3 GB on disk and finishes in 2–4 minutes on an SSD-backed node. The result is a normal LXC you can manage with pct, back up with vzdump, and snapshot like any other guest. If you are still choosing what belongs in a container versus a VM, these scripts pair well with the picks in 6 must-have LXC containers for your Proxmox homelab.

Is curl | bash as root actually safe?

Honest answer: the code in community-scripts/ProxmoxVE is reviewed and widely run, so the official scripts are as trustworthy as any popular open-source installer. But "trustworthy project" and "safe to pipe blind into root" are different claims. Three things make this pattern genuinely risky on a hypervisor specifically:

• Blast radius. The Proxmox host controls every VM and container on it. Code executed as root there can read every guest disk, dump your /etc/pve cluster secrets, and pivot anywhere. This is not a laptop; it is the most privileged box in your lab.
• Time-of-check to time-of-use. Even if you read plex.sh in your browser, the curl in your terminal fetches whatever is at that URL now. A compromised branch, a hijacked account, or a bad merge between your read and your run means you executed something you never saw.
• Transitive fetches. As shown above, the one-liner sources build.func, and install steps inside the container curl more code from upstream vendors. You are trusting a chain, not a file.

The fix is not to avoid the scripts — it is to stop running them blind. Read the app script and the functions it calls before executing:

# Fetch and read, do NOT pipe to bash
curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/plex.sh -o /tmp/plex.sh
less /tmp/plex.sh
curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/misc/build.func -o /tmp/build.func
less /tmp/build.func

Look specifically for: where it sources code from, any install step that adds third-party apt repos or GPG keys, and whether it creates a privileged container. The repo's own README says it plainly: evaluate external scripts carefully before running them, because the maintainers cannot audit every upstream vendor an install step reaches out to.

How to run community scripts safely

This is the workflow I actually use before letting one of these near a production node.

1. Verify the source. Confirm you are on github.com/community-scripts/ProxmoxVE, not a fork with a similar name. Copy the command from the official site, never from a random comment or a mirror. GitHub typosquats and look-alike orgs are real.

2. Pin to a tagged release or commit. main moves; a tag does not. The project cuts date-stamped releases (YYYY-MM-DD), so swap main in the URL for a release tag and you run exactly the code you reviewed:

# Pinned to a specific release tag instead of the moving main branch
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/2025-01-15/ct/plex.sh)"

3. Snapshot or back up the host state first. You cannot snapshot the PVE host like a VM, but you can protect what matters. If your root is on ZFS, take a recursive snapshot before the run; always back up the cluster config directory:

# ZFS root: instant rollback point
zfs snapshot -r rpool/ROOT@pre-helper-script
# Always: capture the Proxmox config (guest defs, storage, cluster secrets live here)
tar czf /root/pve-etc-$(date +%F).tar.gz /etc/pve

4. Test on a throwaway node. Run the script on a spare box or a nested Proxmox VM first. Confirm the container it builds is what you expected before you touch the node that runs your real services. If the script does something surprising, you find out on a machine you can wipe.

5. Prefer unprivileged containers. In the advanced menu, choose unprivileged unless the app genuinely needs host-level access. An unprivileged LXC maps root inside the container to an unprivileged UID on the host, so a container breakout is far less catastrophic. The tradeoffs are covered in privileged vs unprivileged LXC containers on Proxmox, and if the app is Docker-based, read running Docker inside LXC containers on Proxmox first — some of these scripts still default to privileged for exactly that reason.

6. Never run against a node you cannot rebuild. If losing the host would cost you data you do not have backed up elsewhere, do not experiment on it. That is a rule, not a suggestion.

Here is the quick decision table I keep in my runbook:

Situation	Do this	Why
Old tteck/Proxmox URL	Repoint to community-scripts/ProxmoxVE	Original repo is archived, no fixes
Production node	Pin a tag, snapshot, prefer unprivileged	Limit blast radius and enable rollback
Unfamiliar or forked script	Read build.func + install step	Catches added repos and privileged CTs
Air-gapped / sensitive lab	Use ProxmoxVE-Local	No live curl to the internet

Can you review and run these scripts offline?

Yes — this is the piece that changes the security calculus most. The community released ProxmoxVE-Local, a self-hosted mirror and web UI that clones the entire script catalog to a machine you control. You browse, read, and launch scripts from a local server instead of piping live from raw.githubusercontent.com on every run.

For an air-gapped or compliance-bound environment, that means you can pull the repo once, review the diff between releases at your own pace, and run from a frozen local copy with no outbound curl during execution. It also kills the time-of-check/time-of-use gap: the code you reviewed on your mirror is byte-for-byte the code that runs. If you manage more than a couple of nodes, standing up ProxmoxVE-Local internally is worth the afternoon it takes. It also pairs naturally with a habit of building your own base images — see Proxmox LXC templates: build and deploy custom containers for hardening the template layer these scripts sit on top of.

How does community vetting work now?

Under community-scripts, contributions go through GitHub pull requests reviewed by a maintainer team rather than a single author. New app scripts follow a template, get checked against a contribution guide and shellcheck-style linting, and are discussed before merge. Releases are tagged, so you get a changelog and a stable point to pin against instead of an ever-moving main.

That is a real improvement in resilience — a bus factor of one became a team — but it is not a security guarantee. Reviewers vet the helper script itself; they do not (and cannot) audit every upstream project an install step pulls in, nor guarantee a third-party apt repo will not push something bad next week. The project is explicit about this in its documentation and warns you to evaluate scripts before running them. Treat community review as raising the floor, not removing your responsibility. On offline runs with quantized-model-generated automation or copied one-liners, double-check the URLs and container flags by hand — a confident-looking command is not a correct one.

Conclusion

The tteck legacy is alive and better maintained than ever at community-scripts/ProxmoxVE, but the handoff is a good moment to fix a bad habit: piping unread bash into a root shell on the one box that owns your entire lab. Read the script and its build.func, pin to a tagged release, snapshot before you run, test on a node you can rebuild, and prefer unprivileged containers. Your next step: repoint any automation still hitting the archived tteck/Proxmox URLs, and stand up ProxmoxVE-Local if you want to review and run the whole catalog offline.