# community-scripts/ProxmoxVE: one-command LXC and VM installs for Proxmox VE

> The community fork of tteck's helper-scripts turns a Proxmox shell prompt into a service installer. Here is what it actually does, how to run your first script, and where the approach stops being the right tool.

**community-scripts/ProxmoxVE** — Proxmox VE Helper-Scripts (Community Edition). Paste a command into your Proxmox shell, answer a few prompts, and your container or VM is up and running.

- Repository: https://github.com/community-scripts/ProxmoxVE
- Website: https://community-scripts.org/
- Stars: 29,696 · Forks: 2,915
- Language: Shell
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/community-scripts-proxmoxve

## The gap between a Proxmox install and a running service

Proxmox VE gives you a hypervisor and a web UI. It does not give you Jellyfin. Between those two points sits the work most homelab operators actually resent: picking an LXC template, sizing the root filesystem, installing dependencies, creating a systemd unit, finding the port, and remembering which config file holds the listen address. community-scripts/ProxmoxVE exists to delete that stretch of work.

The README describes the project as community-driven automation scripts that install and configure popular self-hosted services with a single command, and states the collection covers hundreds of services across home automation, media, networking, databases, monitoring and more. That breadth is the point. A single script for Grafana is a convenience; a few hundred scripts behind one naming scheme and one prompt flow is closer to a package manager for Proxmox guests.

The audience is narrow and specific. You need root shell access on a Proxmox host and an internet connection during installation. If you are running Proxmox inside a VM for testing, or you administer a hypervisor that is not Proxmox, nothing here applies to you.

## What the repository layout reveals about the mechanism

The top-level entries are ct/, install/, misc/, tools/, turnkey/ and vm/, plus documentation and linting files such as CONTRIBUTING.md, SECURITY.md, CHANGELOG.md and .shellcheckrc. The split between ct/ and vm/ is the clearest signal of the design: container scripts and virtual machine scripts are separate trees, because creating an LXC container and creating a QEMU VM are different operations even when the end service is identical.

The install/ directory holds the entry points that the one-line commands fetch, and misc/ and tools/ hold supporting routines. The presence of .shellcheckrc tells you the scripts are held to a static analysis standard, which matters when the code runs as root on your hypervisor.

Each script follows the same two-mode pattern. Default mode picks resource defaults for CPU, RAM and storage and asks only the minimum required questions. Advanced mode exposes container settings, networking, storage backends and application-level configuration before anything is installed. After installation the container includes a post-install helper, reachable from the Proxmox shell, that applies updates to the installed service, changes application settings without hand-editing config files, and provides basic troubleshooting and log access. That helper is the part that distinguishes this from a collection of shell snippets: the lifecycle continues after the first boot.

Resource defaults are also a constraint. The README says each script page documents what the container includes and its default resource allocation. Default mode is fast because it decides for you, and the decision is what your container will live with.

## Installing your first service from the Proxmox shell

The README's Getting Started section does not publish a single universal command. It points to community-scripts.org, where you search for the service, open its script page, and copy the one-line install command shown there. The README gives Home Assistant, Nginx Proxy Manager and Jellyfin as search examples. Use the command from the script page rather than reconstructing one, because the URL encodes the specific script.

Once you have it, open the Proxmox Shell and paste the line. The script fetches itself and starts. You will be asked to choose Default or Advanced, then answer the remaining prompts. The README states most default installs finish in under five minutes, and that an internet connection is required during installation.

After the guest is created, the post-install helper is available from the Proxmox shell. The README lists what it handles:

```bash
# post-install helper actions described in the README
# - apply updates to the installed service
# - change application settings without editing config files
# - basic troubleshooting and log access
```

What you should see at the end is a new container or VM in the Proxmox web UI, booted, with the service already configured. If you chose Default, check the allocated CPU, RAM and disk against what the service actually needs before you start loading data into it.

## The script is the documentation, and that is the weak point

The install path is a shell script fetched over the network and executed as root on your hypervisor. The README does not describe checksum verification or signature checking for the fetched command, and it does not document a rollback procedure if an install fails halfway. That is not a hidden flaw; it is the trade-off the project chose in exchange for a one-line install. You are trusting the repository's main branch at the moment you paste.

The requirements table is also strict. Proxmox VE 8.4, 9.0, 9.1 or 9.2, a Debian-based host OS, root shell access, and network connectivity during installation. An older Proxmox release is not listed, and nothing in the README claims backward compatibility. If you are pinned to an earlier version, the scripts are not the right tool.

Default mode is the second place people get surprised. It optimises for finishing quickly, which means it will not interrogate you about storage backend or network bridge. If your host has multiple storage pools or a non-default bridge, Advanced mode is the honest choice, and it costs you the five-minute install.

Finally, this is a convenience layer over Proxmox, not a configuration management system. There is no state file, no idempotent re-run guarantee documented in the README, and no drift detection. Once a container exists, its configuration lives in Proxmox, not in the repository.

## How this differs from Terraform and Ansible on Proxmox

The obvious alternative for the same job is provisioning Proxmox guests with Terraform's Proxmox provider plus a configuration tool such as Ansible. The difference is not quality, it is the unit of work.

Terraform and Ansible describe desired state. You write the container definition, the resources, the network, and the configuration tasks, commit them, and re-apply. Running the plan twice converges rather than duplicating. The cost is that you author and maintain every definition yourself, and you need a working provider configuration and an inventory before the first container exists.

community-scripts/ProxmoxVE inverts that. The state is already written by someone else, and you consume it. There is no plan step, no provider block, no inventory. The cost is that you get the maintainer's choices, and your ability to review those choices is limited to reading the script before you run it. If you already run Terraform for your Proxmox estate, adding a helper-script installs an unmanaged guest into a managed environment, which is usually worse than either approach alone.

## Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-08-29. Recent releases are dated 2026-08-26, 2026-08-27 and 2026-08-28, so the project is being changed on a near-daily cadence. For a collection of install scripts that is the relevant maintenance signal: the scripts track upstream application changes, and a service that changes its install method will break its script until someone fixes it.

Upgrade cost falls into two buckets. The scripts themselves update continuously, so the version you paste today is not the version someone pasted last month. Guests you already created do not automatically follow, unless you use the post-install helper's update action. That split is worth understanding before you build a fleet on top of it.

The licence is MIT. In practical terms that permits use, modification and redistribution with the licence text retained, and it comes with no warranty. Since these scripts execute as root on your hypervisor, the absence of warranty is not a formality. Read the specific script you intend to run; the licence gives you the right to do so, and the responsibility sits with you. For anything in a regulated environment, treat the script as third-party code entering your privileged path and route it through whatever review that implies.

## Conclusion

Adopt it if you run Proxmox VE 8.4, 9.0, 9.1 or 9.2 on a Debian-based host and want a repeatable way to stand up Home Assistant, Jellyfin or Grafana without writing your own provisioning. Do not adopt it if you need declarative, version-controlled infrastructure, or if your hypervisor is not Proxmox VE. Before you paste anything, read the script page at community-scripts.org for that service and check the default CPU, RAM and storage it will claim, because those defaults are what the container gets.

## FAQ

### How do I use Proxmox VE helper scripts?

Find the service on community-scripts.org, copy the one-line install command from its script page, and paste it into the Proxmox Shell as root. Choose Default or Advanced setup and answer the prompts. The README states most default installs finish in under five minutes.

### What are the requirements for community-scripts/ProxmoxVE?

Proxmox VE version 8.4, 9.0, 9.1 or 9.2, a Debian-based host OS, root shell access on the Proxmox host, and an internet connection during installation. Older Proxmox releases are not listed as supported.

### Is Proxmox VE free?

The search question is about Proxmox VE itself, and this repository does not answer it. What the README does state is that the helper-scripts are a community project licensed under MIT, built on the foundation of tteck's original work.

### How do I install Proxmox VE helper scripts on Debian?

The scripts are not installed on Debian separately; they run on a Proxmox VE host, whose host OS the README describes as Debian-based. Proxmox VE 8.4, 9.0, 9.1 or 9.2 is required, with root shell access and an internet connection during installation.

## Sources

- [Official documentation](https://community-scripts.org/)
- [Official README](https://github.com/community-scripts/ProxmoxVE#readme)
- [Project repository](https://github.com/community-scripts/ProxmoxVE)
- [Release notes](https://github.com/community-scripts/ProxmoxVE/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/community-scripts-proxmoxve