Self-hosted service
MacRimi/ProxMenux avatar
MacRimi/ProxMenux

ProxMenux: A Menu-Driven Toolkit for Proxmox VE Homelabs

Project brief: Menu-driven Proxmox VE toolkit, post-install, backup/restore and a live web dashboard for the homelab.

2,974 stars155 forksTypeScriptGPL-3.0

At a glance

What is it?
ProxMenux bundles post-install tasks, backup and restore workflows, and a web dashboard into a single CLI. It targets Proxmox VE users who want a guided, menu-based approach without writing scripts.
Who is it for?
Adopt ProxMenux if you run a Proxmox VE homelab and prefer a guided menu over hand-written scripts, especially for post-install tasks and backup management. Skip it if you need a fully scriptable, API-first tool or if you distrust piping remote install scripts.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What ProxMenux Solves for Proxmox Administrators

Proxmox VE is powerful but its native web interface does not cover every post-install task, and many homelab operators end up juggling shell snippets and custom scripts. ProxMenux addresses that by providing a menu-driven CLI that walks you through common operations: post-install configuration, backup and restore, and health monitoring. The intended user is the homelab owner who wants a repeatable, guided process without memorizing Proxmox commands. The README positions it as an interactive toolkit, and the inclusion of a web dashboard suggests it also targets those who prefer a browser over a terminal for monitoring. The project is written primarily in TypeScript, though the runtime components rely on Bash and Python, which is worth noting for anyone expecting a single-language codebase.

Architecture: A CLI Plus a Flask Web Monitor

The repository shows two main components. The first is the menu-driven CLI, which uses the dialog package for interactive terminal menus. The second is ProxMenux Monitor, a web dashboard built with Flask (Python) that runs as a systemd service named proxmenux-monitor.service. The dashboard provides real-time CPU, RAM, disk, and network usage, plus an overview of VMs and containers. It includes login authentication and TOTP-based two-factor authentication, which is a sensible addition for a service exposed on a network. The Monitor is installed automatically as part of the standard installation, so you get both interfaces in one go. The design separates the interactive shell experience from the web-based monitoring, but they share the same installation and update mechanism. The README does not detail how the CLI communicates with the Monitor, so the exact data flow between them is not clear from the material.

Installation and First Launch

Installation is a single command that pipes a remote script into bash: bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)". The README includes a warning about copying scripts from the internet and points to the source code for review. After installation, you run the menu command to start the CLI. The Monitor is available at http://<your-proxmox-ip>:8008. Service management uses standard systemd commands: systemctl status proxmenux-monitor, journalctl -u proxmenux-monitor -n 50, and systemctl restart proxmenux-monitor. The installer automatically pulls in Debian packages: dialog, curl, jq, git, and python3 with pip. These dependencies cover the menu UI, network operations, JSON parsing, updates, and the Flask dashboard. The installation script is the only entry point, and there is no mention of a package manager alternative, so you are tied to that one-liner.

Backup and Restore, Post-Install, and the Beta Channel

The README lists backup and restore as a core feature, but it does not specify which Proxmox entities are covered, such as VMs, containers, or host configuration. The post-install aspect likely covers common server setup steps, but again the details are absent from the material. The beta program gives early access to features from the develop branch, including new Monitor builds. The beta install command is bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/develop/install_proxmenux_beta.sh)". When a stable release is published, the next menu launch notifies the user and offers to switch automatically. This update mechanism is a practical touch, but it also means the tool can change behavior without explicit user action. The release history shows a recent stable v1.2.4 and several beta releases, indicating active development and a willingness to iterate, but also that some features may be less stable.

Security Considerations and the Web Dashboard

The Monitor's authentication and 2FA are welcome features, but the README does not describe how credentials are stored or whether HTTPS is supported. It mentions reverse proxy support for Nginx and Traefik, which suggests that in production you would put the service behind a proxy for TLS. Without that, the dashboard would run over plain HTTP, which is risky on an untrusted network. The README also includes a Code of Conduct section that talks about security and code responsibility, but it is not a substitute for a security audit. The installation method, piping a script from a URL, is a common pattern but one that requires trust in the maintainer and the repository's integrity. The project uses GPL-3.0, so if you modify and distribute it, you must share your changes. For a homelab, that is usually not a burden, but it is a factor if you plan to embed parts of the code in a proprietary tool.

Limitations and When ProxMenux Is the Wrong Fit

The most obvious limitation is the lack of detail about backup and restore specifics. The README does not say whether it supports scheduled backups, incremental backups, or restoration of individual files. If you need fine-grained control, you may still have to write your own scripts. The dashboard is described as real-time, but the README does not specify the polling interval or the performance impact on the Proxmox host. Since it runs as a systemd service, it consumes resources continuously, which could be a concern on a low-end server. The beta program is a double-edged sword: you get new features early, but the README explicitly warns that beta builds may contain bugs. For a production environment, sticking to stable releases is safer. If you prefer a fully scriptable, API-driven approach, ProxMenux's menu-driven design might feel restrictive. The tool is built for interactivity, not for automation, so it is not ideal for unattended operations.

Alternatives and How They Differ

A common alternative is writing your own Bash scripts or using Ansible playbooks that call the Proxmox VE API. Ansible gives you idempotent, repeatable automation that can be version-controlled and run headless. ProxMenux, by contrast, is interactive and menu-driven, which is easier for a single administrator but harder to integrate into a CI/CD pipeline. Another alternative is the Proxmox VE built-in web interface itself, which already covers many monitoring and management tasks. ProxMenux adds a dashboard that runs outside the Proxmox interface, but if you are comfortable with the native UI, you may not need it. The key difference is that ProxMenux bundles post-install and backup workflows into a guided experience, whereas Ansible requires you to define those workflows yourself. If you value convenience over control, ProxMenux is a reasonable choice; if you need automation and reproducibility, Ansible or raw API calls are more appropriate.

Maintenance and Upgrade Costs

Upgrades are handled through the same update mechanism as the beta channel: the menu checks for new versions and offers to switch. The README does not describe an automatic upgrade for the stable channel, so you may need to manually trigger updates. The project's recent release cadence, with multiple beta releases in a month, means you can expect frequent changes. That is good for getting fixes, but it also means you should read the changelog before upgrading. The dependency list is modest and standard for Debian, so the maintenance burden is low. The web dashboard runs as a systemd service, which is easy to manage and restart. The GPL-3.0 license has no cost implications for personal use, but if you distribute modified versions, you must comply with the license terms. The project's documentation site and changelog are the primary sources for tracking changes, and the README points to them for guides and release notes.

Editorial conclusion

Adopt ProxMenux if you run a Proxmox VE homelab and prefer a guided menu over hand-written scripts, especially for post-install tasks and backup management. Skip it if you need a fully scriptable, API-first tool or if you distrust piping remote install scripts. Before adopting, verify the install script source, test the beta branch only on a non-critical host, and confirm that the Monitor's Flask-based dashboard meets your security expectations for network exposure. The project is actively maintained with recent releases, but its beta program signals that some features may still be unstable. Check the changelog on proxmenux.com to see if the latest stable v1.2.4 covers your needs.

Official sources

  1. Official README
  2. Project repository
  3. Release notes
Community notes

Community notes