Proxmox helper scripts: what they run on your host, and how to pin them

The Proxmox VE helper scripts are the one-line installers that turn a fresh Proxmox host into a Home Assistant box, a Jellyfin server or a Docker VM in a few minutes. Most guides stop at “copy the command, paste it into the shell”. This one reads the code first: what a script changes on your host, how to pin it so the same code runs every time, and which scripts belong on a server you depend on.

What the Proxmox helper scripts are, and who maintains them

The collection began in August 2021 as tteck’s personal repository, tteck/Proxmox. When he could no longer maintain it, the project moved to the community-scripts organization on 1 November 2024, with the full history carried over (18,582 commits on the day we checked). The old repository is archived. The README now credits tteck “in memory”, and a core team of volunteers reviews changes. New scripts are tested in a separate DevScripts repository before they reach the main one.

That history matters when you copy a command from an old forum post or video. A URL that contains tteck/Proxmox still downloads, but it runs code frozen in November 2024, and its version check only accepts pve-manager/8.1 to 8.3. On Proxmox VE 9 it stops with “This version of Proxmox Virtual Environment is not supported”. Always start from the current repository or community-scripts.org.

Since August 2026 the shared engine (the code that asks the questions, creates the container and handles errors) lives in a second repository, community-scripts/core. The scripts in ct/ are now short: the Debian one is 45 lines, and its third line loads the engine from core at run time. Keep that in mind for the pinning section below, because a pin on one repository no longer pins the other. The README also notes that the same scripts run unchanged on an Incus host, through the project’s separate Incus repository.

The most-installed helper scripts

If you came for a specific script, these were the ten most installed in the last 30 days according to the counter on community-scripts.org (read 2 November 2026). Each runs with the same command as the Debian example below; only the path at the end of the URL changes.

What happens when you run a helper script

Every script page on the website gives one command in the same form. For the plain Debian container it is:

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

curl -fsSL downloads the script quietly and fails on an HTTP error, the $(...) turns the file into a string, and bash -c runs that string. Nothing is saved to disk, so there is nothing left to read afterwards. main in the URL means “whatever is on the main branch right now”. We traced what a run does from the source, at the commits listed in the test box at the end:

1. 1Load the engine from the second repository

   Line 3 of ct/debian.sh sources core/build.func from community-scripts/core, branch main, unless you point it elsewhere. The engine then fetches around 20 more function files the same way.

2. 2Check the host

   It stops unless it runs as root, in bash, on amd64 or arm64, on a Proxmox node with a supported version. Over SSH from outside the node’s network it warns and recommends the Proxmox web shell instead; sessions from the node itself or the same /24 get no warning.

3. 3Ask about diagnostics, once

   On the first run a dialog asks “Send Diagnostics of LXC Installation?”. Your answer is stored in /usr/local/community-scripts/diagnostics. With DIAGNOSTICS=yes, each install reports the app, the container’s resources, CPU, GPU and RAM facts and, when it fails, the failing command and its log lines to telemetry.community-scripts.org. Answer no, or set DIAGNOSTICS=no in that file, to send nothing.

4. 4Default or Advanced

   Default asks only what it must, such as the storage when there is more than one. Advanced shows every setting below before anything is created.

5. 5Download a template and create the container

   It updates the template list with pveam, downloads the OS template if it is not cached, and calls pct create with the next free ID.

6. 6Run the install half inside the container

   It fetches install/debian-install.sh and runs it through lxc-attach: update the OS, set up the message of the day, configure console login, clean up. For an app such as Uptime Kuma, this is where the app itself is downloaded.

7. 7Leave an update command behind

   It writes /usr/bin/update into the container. Typing update in the container console downloads the same ct/ script again, from the same branch, and runs its update function.

What Default mode gives you

Read these before you accept the defaults on a server rather than a home lab. They come from the engine’s built-in values and the Debian script’s own header; other apps set their own CPU, RAM and disk.

How to read a helper script before you run it

The project’s own README says it plainly: the commands run as root on your host, so read the script before you paste it. Because the work is split into three parts, reading only the file in the URL is not enough. Download all three and page through them:

APP=debian
mkdir -p ~/cs-review && cd ~/cs-review
curl -fsSLO https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/$APP.sh
curl -fsSLO https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/$APP-install.sh
less $APP.sh $APP-install.sh

# every place the code downloads or runs something else
grep -nE 'curl|wget|source|bash -c|eval' $APP.sh $APP-install.sh

What to look for in the two files:

• The var_ lines at the top of the ct/ script: CPU, RAM, disk, OS version and var_unprivileged. A 0 there means a privileged container.
• Every URL. App installs often call fetch_and_deploy_gh_release, which downloads the app’s latest GitHub release. Check that the repository it names is the app’s official one.
• Anything that writes outside the container in the ct/ half: pct set, bind mounts, device passthrough, edits under /etc/pve.
• The engine is the larger part: core/build.func and the files it loads come to several thousand lines. You do not have to read it every time, but read it once, and read its changes when you move your pin.

Pin a helper script to a commit

A URL with main in it can run different code tomorrow than it ran today. Pinning means replacing main with a full commit hash, so the code you read is the code you run. The common advice is to pin the script’s URL. Since the engine moved out, that pins only the 45-line script, while the engine still comes from core/main. Pin both repositories:

git ls-remote https://github.com/community-scripts/ProxmoxVE refs/heads/main
git ls-remote https://github.com/community-scripts/core refs/heads/main

S=7774a1a28d6e637c47a7476de3e9167fbe337d25   # ProxmoxVE commit you read
E=09fac1952f6050395aae8e6ecc9d4900c5c180d2   # core (engine) commit you read

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/community-scripts/ProxmoxVE/$S \
COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/$E \
  bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/$S/ct/debian.sh)"

Both variables are the ones the project documents for testing a fork or branch: COMMUNITY_SCRIPTS_URL decides where the install/ half comes from, COMMUNITY_SCRIPTS_CORE_URL where the engine comes from. The two hashes above are the heads of both branches on 2 November 2026; both URLs answered 200, and the pinned file’s SHA-256 matched our clone. Use the commits you actually read, not ours.

The stricter way: run from a local checkout

If you want to read diffs instead of URLs, clone both repositories next to each other and check out the commits you reviewed. The ct/ script looks for the engine at ../../core relative to itself and the engine finds install/ next to ct/. Everything still comes from the commits you checked out, but not all of it from disk: the half that runs inside the container downloads the engine files from GitHub, and in checkout mode the engine points that download at community-scripts/core at the short hash of your checkout. That detection needs git on the node, which a fresh install may not have:

apt install -y git
mkdir -p /root/cs && cd /root/cs
git clone https://github.com/community-scripts/ProxmoxVE.git
git clone https://github.com/community-scripts/core.git
git -C ProxmoxVE checkout 7774a1a28d6e637c47a7476de3e9167fbe337d25
git -C core checkout 09fac1952f6050395aae8e6ecc9d4900c5c180d2
bash /root/cs/ProxmoxVE/ct/debian.sh

# next time: see exactly what changed before you move the pin
git -C ProxmoxVE fetch && git -C ProxmoxVE log --oneline HEAD..origin/main -- ct/debian.sh install/debian-install.sh
git -C core fetch && git -C core diff --stat HEAD origin/main

Two limits apply to every pin:

• A pin fixes the installer, not the app. 449 of the 635 files in install/ call the release helper, and its default version is latest. Two installs a month apart can get two app versions.
• The update command inside the container reuses the scripts URL from the install and loads the engine from core/main unless you set the variable again: COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/$E update.

The Proxmox post-install script: what it changes

The most-run host tool is post-pve-install.sh, usually the first thing people run on a new node. It asks before every change, but the prompts are short, so here is what each yes does on Proxmox VE 9. The first two rows only appear on a node that has no .sources file in /etc/apt/sources.list.d yet, such as an old 8.x layout upgraded by hand or a provider image. A fresh 9.x install, or a node upgraded with the official 8 to 9 guide, already has .sources files: the script shows “Deb822 sources detected”, leaves the source format alone and goes straight to the enterprise repository.

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"

Before you run it, keep a copy of what it edits. On a ZFS install a root snapshot is the cleanest undo; on the default ext4 or XFS layout copy the files:

cp -a /etc/apt /root/apt-before-post-install

# ZFS root only: check the dataset name first, then snapshot it
zfs list -o name | grep ROOT
zfs snapshot rpool/ROOT/pve-1@before-post-install

Only if the script wrote a new debian.sources (the migrate prompt above): add non-free-firmware back to its Components: lines and install intel-microcode or amd64-microcode with apt, so microcode keeps receiving updates. On a fresh Proxmox VE 9 install the file is untouched, and the Proxmox documentation lists non-free-firmware there by default.

Useful helper scripts for a server node

Most of the 649 container scripts are apps. The host tools in tools/pve/ are the ones that touch the node itself. We read each of these; this is what it does and whether we would run it on a production host:

For the guests themselves, the VM scripts (debian-vm, ubuntu-vm, docker-vm, opnsense-vm) save the fiddly parts of building a cloud image VM, and they have no updater: you patch the guest like any other machine. If you are weighing a single Docker VM against many containers, installing Docker on Debian by hand takes about as long as the script and leaves nothing you have not read.

Production node or home lab?

Our rule of thumb: in a home lab, run them from the website and enjoy the time saved. On a node that carries customer or business workloads, pin both repositories, read the diff when you move the pin, avoid the nag patch and unattended updates, and test new scripts on a spare node first. If you are still choosing a hypervisor for that node, Hyper-V vs VMware covers the main commercial options, and what is Hyper-V the Windows one.

Snapshot and roll back

Undoing a helper script means undoing what it created, which is usually one container. Before an update or any change inside it, take a snapshot from the host:

pct snapshot 105 before-update
pct listsnapshot 105

# the update went wrong
pct rollback 105 before-update

# it worked: drop the snapshot again
pct delsnapshot 105 before-update

Container snapshots need storage that supports them. local-lvm (LVM-thin) and local-zfs, the two layouts the Proxmox installer creates, both do; a container on plain Directory storage does not, so back it up instead with vzdump 105 --mode stop --storage local. Snapshot mode is no way around that: the vzdump documentation says it needs every backed up volume on storage that supports snapshots. Stop mode shuts the container down for a consistent copy and starts it again; --mode suspend keeps the downtime shorter. A new container is only in your backup job if that job covers all guests; a job with a fixed list of IDs needs it added.

pct stop 105
pct destroy 105 --purge    # --purge also removes it from backup, replication and HA jobs

To undo the post-install script, put back the copy of /etc/apt (or roll back the ZFS snapshot), then run apt update. To drop the nag patch, delete /etc/apt/apt.conf.d/no-nag-script and /usr/local/bin/pve-remove-nag.sh and reinstall the original file with apt --reinstall install proxmox-widget-toolkit, plus apt --reinstall install pve-yew-mobile-gui if that package is installed, because the hook patches the mobile UI too. If you disabled HA by mistake, systemctl enable --now pve-ha-lrm pve-ha-crm corosync turns it back on.

Rolling back rpool/ROOT/pve-1 resets more than APT: the cluster configuration database /var/lib/pve-cluster/config.db lives on that dataset, so every VM and container config created after the snapshot disappears from the node. Plan a reboot straight after the rollback.

Common helper script errors

A helper script saves you from building the container, not from running the app. If all you need is one of these apps online and you do not need a hypervisor of your own, a Standard KVM VPS runs it directly, with snapshots and a browser VNC console in the panel for the day an update goes wrong.

Frequently asked