oneclickvirt pve turns a bare Proxmox host into a NAT virtual server farm

What the installer actually configures on a bare Proxmox host

The repository describes one-click server deployment for Proxmox VE, supporting bulk or individual VM provisioning with built-in internal and external port forwarding, and the primary language is Shell. The point of the project is to take a machine that has just had Proxmox installed and turn it into something that can hand out virtual servers. The environment variables make the intended shape clear: PVE_CREATE_COUNT, PVE_CREATE_CPU, PVE_CREATE_MEMORY, PVE_CREATE_DISK, PVE_CREATE_STORAGE, PVE_CREATE_SYSTEM and PVE_CREATE_IPV6 together describe a batch of guests with identical shape, and PVE_MAIN_INTERFACE, PVE_HOSTNAME and USE_PRIVATE_IP describe the host. CN=true selects the China route. It is a configuration driven script set, not an application with a user interface, and the documentation site carries a section describing the Proxmox VE partition contents. The repository layout backs that up, with scripts/, extra_scripts/, patches/, gpg/, dockerfiles/, tests/ and a log directory at the top level.

A noninteractive flag turns a confirmation-heavy script into automation

A one-click script that asks questions is not much use in a provisioning pipeline, so the project provides a documented way to skip the confirmations. When you need to skip script confirmation and input prompts, the same variable is used everywhere:

export noninteractive=true

The uninstall script treats noninteractive=true as equivalent to AUTO_CONFIRM=yes, which skips the uninstall confirmation as well. The same sentence that documents the flag also lists the environment variables that override defaults during installation and batch creation, which is the more useful half of the feature. The variables are plain names and values with no nesting, so an orchestrator can set them and run the script. The catch is that this is an environment contract maintained by a shell project, not a versioned API, so a future change to a variable name would break automation silently at the next upgrade. Pinning the script revision is the sensible precaution.

Kernel installation is verified, and a failed check leaves the host alone

The 2026.10.17 changelog entry describes the most delicate part of the whole flow. On Debian 13 and PVE 9 the installer replays kernel installation hooks, checks the initramfs, modules and boot entries, and retains a working recovery kernel. The English documentation section is more specific still. Kernel verification accepts both pve-kernel-* and proxmox-kernel-* concrete installed packages, including signed kernels, and checks the kernel image, initramfs and modules before reporting success. The working distribution kernel is kept as a recovery option, and failed installation checks preserve installed packages instead of purging PVE and automatically removing kernels. That is the correct failure mode for a script that touches the boot chain of a machine you may be running production guests on. An incomplete existing installation can be resumed with PVE_REPAIR_EXISTING=true, which preserves guests and recovery kernels, and default enterprise sources are backed up and disabled before retrying the signed no-subscription repository.

Network changes are rolled back by an independent timer

Moving a physical NIC into a bridge, or writing a new interface file, can leave a host unreachable, so this project treats that step as transactional. Network preconfiguration uses an ifupdown2 reload with a syntax check, a copy of recursively sourced interface files and an independent rollback timer. Host IPv4 and, when previously present, IPv6 HTTPS connectivity must survive the change before it is committed. The 2026.08.27 entry adds that a host bridge migration retains recursive interface configuration, and that a failed syntax or connectivity check triggers a rollback by a separate timer. The 2026.10.17 entry repeats that the independent IPv4 allocation now uses the real prefix and gateway, checks for ARP conflicts, releases the allocation lock before QEMU starts and persists address occupancy for full port NAT. On the firewall side, when UFW is already active, network setup adds forwarding rules limited to its guest bridges and the IPv4 and IPv6 subnets, and it does not enable an inactive UFW. Failed rule updates take part in the same network rollback as interface edits.

IPv6 delegation is configured by hand because the provider has to cooperate

The IPv6 story is where the script has to be told things it cannot discover. Static IPv6 prefixes and existing direct bridges are detected automatically, but if the provider supplies a separate routed prefix, you set it yourself and rerun build_nat_network.sh:

export PVE_IPV6_ROUTED_PREFIX='YOUR_DELEGATED_PREFIX_WITH_LENGTH'
export PVE_IPV6_DIRECT_GATEWAY='YOUR_HOST_IPV6_GATEWAY'
export PVE_IPV6_DIRECT_MODE=routed

Existing bridges are preserved and their IPv6 address is used as the guest gateway, and PVE_IPV6_DIRECT_BRIDGE plus PVE_IPV6_BRIDGE_GATEWAY let you pick a different one. The documentation draws a hard line about what the tool cannot do. An NDP proxy can route permitted IPv6 addresses through the host MAC, but it cannot bypass an upstream restriction that authorizes only one IPv6 address or a prefix that the provider has not routed to this machine. For pure IPv6 containers and virtual machines, IPv6 DNS is used, and direct, NAT66 and one-to-one mapping are validated separately, with creation stopped when the conditions cannot be met. If the configuration file is read-only or cannot be unlocked, the instruction is to fix write access before retrying.

Guest creation is a positional argument list, not a config file

The LXC path shows the interface most users will meet first. The buildct.sh script keeps the original NAT arguments, and the 14th parameter can specify an independent IPv4 address with CIDR or auto. It uses the same host, gateway, broadcast address, used address and ARP conflict checks as the virtual machine path, and it retains the actual subnet mask, with no public IPv4 port forwarding created. The 13th parameter set to y additionally requests IPv6, and the actual mode is written into the result:

bash buildct.sh 150 'YOUR_PASSWORD' 1 768 6 0 0 0 0 0 debian12 local y 198.51.100.195/27

The documentation warns that independent IPv6 requires the instance bridge and an available delegated prefix to be configured first, and that the host address or bridge gateway must not be used as the instance address. There is also a way to get no inbound mapping at all: setting the SSH, HTTP, HTTPS and port range parameters of buildct.sh and buildvm.sh to 0 leaves only the internal address and outbound capability. Passing a password that begins with a hyphen is supported, and the password is stored only in a local metadata file with permission 600, with IPv6 deletion rules matched on the full address.

Two release tags, three years of them, and a busy main branch

The tagging history is unusual and worth understanding before you rely on a specific revision. The only named releases are ndpresponder_aarch64 from 2023-08-22 and ndpresponder_x86 from 2023-08-21, both of which are binaries for the NDP responder rather than snapshots of the installer. The repository itself is not archived, and the last push was on 2026-10-20, three days before the date of the newest changelog entry. The licence is MIT, held in a file named License at the top level rather than LICENSE. The practical reading is that this project ships by commit rather than by release, and a CHANGELOG.md is the version history that matters. The documentation points to a China specific site and an English site, and the README asks that unadapted reseller machines be reported so support can be attempted, which tells you the target audience is operators of commodity VPS hardware.

Where this installer is the wrong tool

Three cases argue against it. The first is a hosted platform where you do not control the physical host. The scripts assume root on the Proxmox node, they edit interface files and reload ifupdown2, and they install kernels, none of which is possible or sensible on a managed offering. The second is a team that wants a declarative, reviewable infrastructure definition. Every parameter here is positional and interactive by default, so the result of a run depends on defaults that live inside the scripts rather than in a file you can commit and diff, and the environment variable overrides are the only reviewable part of the configuration. The third is ARM64 in a data centre that does not hand out routed IPv6, where the one thing the script adds beyond plain NAT is unavailable. There is also the self-patching image angle to consider, since the KVM and LXC images are pulled from separate repositories that patch themselves at build time, and a supply chain that reaches into a provisioning path deserves its own review. The stated alternative for a different job is the ecs project, a fusion test script for VPS providers listed in the friend links, which measures providers rather than configuring a host.

Editorial conclusion

Adopt oneclickvirt pve when you already own Proxmox VE hardware and need repeatable guest provisioning with NAT and port forwarding on ARM64 as well as AMD64, and treat it as an operations script rather than a product. Verify first that your provider actually routes a delegated IPv6 prefix to the host, because the script cannot bypass an upstream restriction, and read the changelog for the 2026.10.17 entry before running it on a host whose bridge carries production traffic.

Frequently asked questions

Official sources

1. License: MIT
2. oneclickvirt/pve on GitHub
3. Project website
4. README
5. Releases