Build a browser-based view of your Proxmox homelab, verify it locally, and make it available when you are away
ProxMenux combines a menu-driven Proxmox VE toolkit with ProxMenux Monitor, a web dashboard for viewing host resources, network traffic, virtual machines, and LXC containers. This guide walks through the official stable installation method, explains what the installer changes, verifies the systemd service and local dashboard, and covers routine operations and troubleshooting. Once the dashboard works on your local network, we show how to connect it to a Localtonet HTTP tunnel without configuring inbound router port forwarding or requiring a public IP address.
📋 What's in this guide
How ProxMenux Monitor and Localtonet fit together
ProxMenux is an interactive toolkit built for Proxmox VE. Its terminal interface provides menu-driven access to post-installation, backup, restore, and related homelab management workflows. The standard installation also includes ProxMenux Monitor, a browser-based dashboard that runs continuously as a systemd service.
The Monitor is useful when you want an at-a-glance view without opening a terminal. It reports real-time CPU, RAM, disk, and network activity, and it presents the status of virtual machines and LXC containers. The interface is designed for desktop and mobile browsers. It includes login authentication, supports TOTP-based two-factor authentication, and can operate behind reverse proxies such as Nginx or Traefik.
After a standard installation, the documented local dashboard address is http://<your-proxmox-ip>:8008. Replace the placeholder with the LAN address of your Proxmox VE host. That local endpoint must work before remote access is introduced. Treat installation, local verification, application security, and public connectivity as separate layers so that a problem in one layer is easier to identify.
proxmenux-monitor.service systemd service and configures it to start automatically at boot.
8008.
What Localtonet changes
A Localtonet tunnel changes how an authorized remote browser reaches the dashboard. Our client establishes an outbound connection from a device on your network to a Localtonet relay server. The HTTP tunnel then connects that public entry point to the ProxMenux Monitor address reachable by the client device.
This approach does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The tunnel remains available only while the selected Localtonet client is connected and the tunnel is running. Creating a tunnel configuration alone does not make it active. It must also be started.
Do not begin tunnel troubleshooting until http://<your-proxmox-ip>:8008 works from the device that will run our client. Localtonet can provide a route to a reachable service, but it cannot correct a stopped Monitor service, an incorrect Proxmox address, or a local network path that does not work.
Prerequisites and decisions to make before installation
The official stable installation is intended to be run from the terminal of the Proxmox VE server. The installer is downloaded from the ProxMenux repository and passed to Bash. Because this executes code on a virtualization host, review the script and make sure you have an appropriate recovery plan before proceeding.
You also need the Proxmox host's LAN address for dashboard verification. The project documents the Monitor at port 8008, so the browser and any separate Localtonet client device must be able to reach that host and port across the local network.
| Requirement | Why it is needed | What to confirm |
|---|---|---|
| Proxmox VE server terminal | The official installation command runs directly from the Proxmox server terminal. | You can open a terminal session and perform the installation with sufficient administrative permissions. |
| Internet access from the host | The installation command retrieves the current stable installer from the project repository. | The host can resolve and reach the repository URL used by the command. |
| Proxmox LAN address | The Monitor is opened at the host address on port 8008. |
You know which host address is reachable from your browser and tunnel client. |
| Browser on the local network | Local browser testing separates application problems from remote-access problems. | The browser device has a route to the Proxmox host. |
| Localtonet client device | Remote access requires our client on a device that can reach the Monitor. | The selected device can remain connected while remote access is required. |
| Security plan | A remotely available administration dashboard should not rely on obscurity. | Login protection is active, credentials are strong, and TOTP 2FA is considered before exposure. |
Packages handled by the installer
ProxMenux documents that its setup automatically installs the Debian packages it needs. These include dialog for terminal menus, curl for downloads and connectivity checks, jq for JSON processing, git for repository cloning and updates, and python3 plus python3-pip for the Flask-based Monitor dashboard.
This means there is no documented requirement to preinstall those individual packages manually for the standard workflow. However, package installation still depends on the Proxmox host having working package repositories and network access. If setup stops during dependency installation, resolve the host's repository, DNS, or connectivity issue before rerunning the installer.
Monitor interface translations are distributed as pre-built JSON files. The documented languages are English, Spanish, French, German, Italian, and Portuguese. There is no runtime translation dependency to install.
The official command downloads a script and immediately executes it with Bash. ProxMenux itself warns users to check scripts copied from the internet. Review the current install_proxmenux.sh source, confirm that the URL points to the expected project and stable branch, and take any backup or recovery precautions appropriate for your Proxmox host.
Install ProxMenux on the Proxmox VE host
The steps below follow the project's documented stable installation flow. This article uses the stable installer from the main branch. ProxMenux also offers a beta installer from its development branch, but beta builds may contain incomplete features or bugs. A production or important homelab host should use the stable path unless you have deliberately chosen to test development builds.
Open the Proxmox server terminal and review the installer
Start a terminal session on the Proxmox VE server. Before execution, inspect the current install_proxmenux.sh file in the official ProxMenux repository. This is especially important because the installer runs on the hypervisor and may install packages and services.
Run the official stable installation command
Execute the documented command below in the Proxmox server terminal and follow any prompts presented by the installer.
bash -c " $( wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh ) "Launch the ProxMenux terminal menu
After installation completes, start the menu-driven toolkit with the documented menu command. Follow the on-screen options for the Proxmox management workflow you want to use. The standard installation also installs ProxMenux Monitor automatically, so a separate Monitor installation command is not required.
menuWhat a standard installation provides
The terminal menu and web Monitor serve related but different purposes. The menu command launches the interactive terminal toolkit when you need its guided management operations. The web dashboard runs independently as proxmenux-monitor.service, allowing it to start at boot and remain available without an open terminal session.
Do not assume that seeing the terminal menu proves the browser dashboard is working. Verify the systemd unit and HTTP endpoint separately. Likewise, a working dashboard does not prove every optional ProxMenux operation has been configured. Validate each feature you intend to use according to its own prompts and requirements.
Verify the systemd service and local dashboard
Verification should proceed from the service layer to the browser layer. First confirm that systemd considers the Monitor active. Then open the dashboard over the local network. Finally, test from the exact device that will run the Localtonet client, because that device's route to the Proxmox host determines whether the tunnel can reach the target.
Check the Monitor service
Run the documented status command on the Proxmox host. Review the active state and any recent messages shown by systemd.
systemctl status proxmenux-monitorOpen the documented local endpoint
From a browser on the local network, replace the placeholder with the reachable LAN address of the Proxmox host and open http://<your-proxmox-ip>:8008. A successful result should present the ProxMenux Monitor interface rather than a browser connection error.
Confirm dashboard data and login behavior
Sign in using the authentication configuration established by ProxMenux. Confirm that expected host resource information appears and that VM or LXC status indicators reflect your environment. If you plan to use TOTP 2FA, configure and test it while you still have reliable local access.
Test from the future tunnel client device
If our client will run on another machine, open the same LAN endpoint from that machine. A successful test confirms that its network path can reach the Proxmox host on port 8008. If it cannot, fix local routing or host access before creating the tunnel.
The documented ProxMenux Monitor endpoint is local HTTP on port 8008. A Localtonet HTTP tunnel can serve that content through its public HTTPS address. Keep the local target scheme and port aligned with the service that is actually running rather than assuming that the local Monitor itself listens with HTTPS.
Recognizing a complete local verification
A browser page loading is necessary, but it is not the only check. Confirm that authentication works, resource values populate, and the VM and LXC overview is usable. If the shell running the installation is closed, the Monitor should remain available because it is managed by systemd. You can also reboot during a suitable maintenance window and verify that the documented automatic boot behavior works in your environment.
If the service status is active but the browser cannot connect, do not immediately restart it repeatedly. Confirm that the URL contains the correct host address and port, that the browser device can reach the host, and that no local filtering policy blocks the connection. The service logs provide more useful evidence if the process starts but fails internally.
Operate and maintain ProxMenux Monitor
ProxMenux documents three systemd and journal commands for routine Monitor administration. These commands let you inspect service state, read recent logs, and restart the dashboard. Run them on the Proxmox host.
| Task | Command | When to use it |
|---|---|---|
| Check service status | systemctl status proxmenux-monitor |
Use this first when the dashboard is unavailable or after installation. |
| Read recent logs | journalctl -u proxmenux-monitor -n 50 |
Use this to inspect the latest 50 journal entries for startup or runtime errors. |
| Restart the Monitor | systemctl restart proxmenux-monitor |
Use this after identifying a reason to restart or when recovering from a transient service problem. |
| Launch the terminal toolkit | menu |
Use this when you need the separate menu-driven ProxMenux management interface. |
systemctl status proxmenux-monitor
journalctl -u proxmenux-monitor -n 50
systemctl restart proxmenux-monitorUse logs before restarting
When practical, capture the service status and recent logs before restarting. A restart can recover a process, but it may also remove useful context from the immediate screen or make an intermittent failure harder to understand. The documented 50-line journal command provides a concise starting point for reporting a problem.
If you need to report an issue to the ProxMenux project, include what you did, what you expected, any error messages shown, and relevant Monitor logs. Remove credentials, tokens, private URLs, hostnames, and other sensitive infrastructure details before sharing diagnostic output publicly.
Stable and beta installations
The project's beta program provides early access to features from the development branch, including newer Monitor builds. Those builds may contain bugs or incomplete features. The stable installation command in this guide is the appropriate baseline for a predictable setup and for troubleshooting against released behavior.
If you intentionally use the beta program, keep that fact in your troubleshooting notes. A problem present in a development build may not apply to the stable release. Do not mix stable and beta installation commands casually on an important Proxmox host.
Secure the dashboard before making it remotely reachable
A Proxmox monitoring dashboard reveals operational details about the host and its guests. Even if the dashboard does not expose every Proxmox administrative function, resource data, guest names, status information, and topology clues can still be sensitive. Remote availability should therefore be a deliberate security decision.
ProxMenux Monitor includes login authentication and TOTP-based 2FA support. Enable and test the protections suitable for your environment before publishing the endpoint. Use strong, unique credentials, protect TOTP enrollment material and recovery information, and avoid sharing accounts between unrelated users.
Do not disable ProxMenux authentication simply because the dashboard is reached through a hard-to-guess address. Public endpoints can be discovered or shared. Preserve application authentication, use least-privilege access practices, enable 2FA where appropriate, and follow your organization's network and security policies.
Reverse proxy support and this workflow
ProxMenux documents reverse proxy support for Nginx and Traefik. That can be useful in environments that already centralize local web services through a reverse proxy. It is not required for the direct Localtonet workflow described here, where the HTTP tunnel targets the reachable ProxMenux Monitor endpoint on port 8008.
If you already place ProxMenux behind Nginx or Traefik, decide whether our client should target that proxy or the Monitor directly. That decision depends on your existing hostname routing, certificates, authentication layers, and local network design. The supplied evidence does not define a universal reverse proxy configuration, so this guide does not invent one.
Expose the working ProxMenux Monitor with a Localtonet HTTP tunnel
Begin this stage only after the Monitor works locally from the device that will run our client. The target is the Proxmox host address on port 8008. The exact address depends on your network, so use the same reachable address that succeeded during local verification rather than copying an example address.
Our client may run on the device hosting the service or another device that can reach it. For this workflow, the essential condition is network reachability from the Localtonet client device to the ProxMenux Monitor endpoint. The client creates an outbound connection to our relay, so no inbound router forwarding is required.
Install and run the Localtonet client
Install our current client on a device that can reach the Proxmox host on port 8008. Use the current installation instructions presented by Localtonet for that device's operating system. Client commands can change between versions, so this guide does not guess a command that is not established by the supplied product documentation.
Authenticate or select the client device
Connect the intended device using its device-specific authentication token, then select that device for the tunnel. Treat the token as a credential. Never paste it into screenshots, logs, articles, support forums, or shared configuration examples.
Select an available relay server or region
Choose from the relay options currently available in your dashboard. Available server codes and regions can vary, so obtain the current value from the product rather than copying a hardcoded code from a tutorial.
Create an HTTP tunnel for the Monitor
Create an HTTP tunnel and set its local target to the reachable Proxmox host address with local port 8008. Use the address that worked from the Localtonet client device during local testing. HTTP tunnels can use a generated subdomain, a selected subdomain where supported, or a custom domain. Check the current dashboard and documentation for availability and any domain-specific requirements.
Start the tunnel
Use the Start button after saving the configuration. Creating the tunnel does not mean it is running. The public address is usable only while the selected client is connected and the tunnel itself is active.
Test the assigned public address
Open the assigned public HTTPS address from a network outside your LAN, then verify the ProxMenux login flow, TOTP challenge if enabled, and dashboard rendering. When remote access is no longer needed, stop or delete the tunnel from the dashboard.
For the current dashboard workflow and field names, consult the Localtonet HTTP tunnel documentation. Product options can vary by plan, client version, region, or deployment, so use the values shown in your account rather than assuming every option is universally available.
| Layer | Address or component | Expected behavior |
|---|---|---|
| Application service | proxmenux-monitor.service |
Runs the Monitor and starts automatically at boot after standard installation. |
| Local web endpoint | http://<your-proxmox-ip>:8008 |
Loads from a browser or Localtonet client device that can reach the Proxmox host. |
| Localtonet client connection | Outbound connection to a selected relay | Maintains the tunnel without inbound router port forwarding. |
| Public entry point | Assigned Localtonet HTTPS address | Forwards authorized browser requests to the configured local HTTP target while the tunnel is running. |
| Application access control | ProxMenux login and optional TOTP 2FA | Protects access at the Monitor application layer and should remain enabled. |
How to verify remote access safely
Test from a genuinely separate network, such as another trusted connection, rather than relying only on a browser still connected to the homelab LAN. Confirm that the public address leads to the expected ProxMenux login page and not to another service. Sign in, check that dashboard data appears, and sign out when finished.
Keep the local endpoint private to the extent your network design allows. Do not configure unrelated port forwarding in parallel, since that creates an additional route that is independent of the tunnel lifecycle. With Localtonet, stopping the tunnel removes the Localtonet public path, but it does not change any other firewall, router, reverse proxy, or application exposure you may have configured separately.
Troubleshoot installation, local access, and the tunnel
Troubleshooting is fastest when you identify the first failing layer. Start with the ProxMenux service, continue to local HTTP access, then verify reachability from the Localtonet client device, and only then inspect the public tunnel.
| Symptom | Likely layer | Recommended checks |
|---|---|---|
| The installation command cannot download the script | Host connectivity | Check DNS resolution, outbound internet access, and whether the repository URL is reachable from the Proxmox host. |
| The terminal menu does not launch | ProxMenux installation | Review installation output and confirm setup completed before running menu again. |
| The Monitor service is inactive or failed | systemd or application startup | Run the status command, then inspect the latest 50 journal entries for a specific error. |
| The service is active but the local page does not open | Address, port, or local network | Confirm the Proxmox LAN address, use port 8008, and test from a device with a valid route to the host. |
| The page opens locally but the tunnel reports an upstream failure | Tunnel target reachability | Open the local endpoint from the exact Localtonet client device and correct the configured target address if necessary. |
| The tunnel exists but the public address is unavailable | Tunnel lifecycle | Confirm the selected client is connected and that the tunnel was explicitly started. |
| The public page loads but login fails | ProxMenux authentication | Test the same credentials locally, verify TOTP time and enrollment, and avoid weakening authentication to work around the issue. |
| Remote access stops after a client shutdown | Localtonet client availability | Restore the selected client device and confirm both its connection and the tunnel's running state. |
Service fails immediately after installation
Start with the service status and journal output:
systemctl status proxmenux-monitor
journalctl -u proxmenux-monitor -n 50Look for a concrete startup error rather than assuming the tunnel is involved. The tunnel is not part of the Monitor process and cannot cause a local systemd unit to install correctly or start successfully. If package setup did not complete, review the earlier installer output and resolve repository or dependency failures.
The dashboard works on Proxmox but not from another LAN device
Confirm that you are using the Proxmox host's reachable LAN address rather than an address that only makes sense locally on the host. The official documentation establishes the endpoint pattern and port, but it does not define your LAN addressing or firewall policy. Check those environment-specific controls without broadly disabling security protections.
The same rule applies to a Localtonet client placed on another machine. If that machine cannot open the local Monitor address, our relay cannot make the upstream service reachable through it. Move the client to a suitable network location or correct the local route and filtering policy.
The public URL does not respond
Check the lifecycle state in order. The selected Localtonet device must be connected, the correct tunnel must be started, and its target must match the verified ProxMenux address and port. If any one of these conditions is false, the public route will not reach the Monitor.
Also verify that ProxMenux did not stop after your original local test. Running systemctl status proxmenux-monitor distinguishes an application outage from a tunnel configuration problem. Avoid changing multiple layers at once, since doing so makes the original cause harder to identify.
The dashboard appears, but data is incomplete
A visible login page proves only that the HTTP service responded. Sign in and check whether host metrics and guest status populate. Review the Monitor journal for application-level errors. If you report the issue, include the observed behavior and relevant sanitized logs, but do not publish private infrastructure details or authentication material.
Disabling authentication, opening broad firewall rules, or forwarding port 8008 directly from the router can create unnecessary exposure. Diagnose the failing layer, keep login protection active, and make only the narrow changes required by your approved network design.
Frequently asked questions
Does the standard ProxMenux installation include the web Monitor?
Yes. The standard installation automatically installs ProxMenux Monitor as proxmenux-monitor.service. The service is configured to start automatically when the Proxmox host boots, so there is no separate documented Monitor installation command for this workflow.
What address does ProxMenux Monitor use?
The documented local endpoint is http://<your-proxmox-ip>:8008. Replace the placeholder with the Proxmox host address reachable from your browser or Localtonet client device. The documented local scheme is HTTP and the port is 8008.
Must the Localtonet client run directly on the Proxmox host?
Not necessarily. The client must run on a device that can reach the ProxMenux Monitor address on port 8008. Test that local endpoint from the intended client device before configuring the tunnel. The exact supported installation method for that device should be taken from the current Localtonet dashboard or documentation.
Does Localtonet require router port forwarding for this dashboard?
No. Our client establishes an outbound connection to a Localtonet relay server. This provides the public route without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The tunnel is available only while the selected client is connected and the tunnel is running.
Should I disable the ProxMenux login when using a tunnel?
No. A tunnel provides connectivity and does not replace application authorization. Keep ProxMenux login protection enabled, use strong unique credentials, and consider its supported TOTP 2FA before making the dashboard remotely reachable.
Can I use Nginx or Traefik with ProxMenux Monitor?
ProxMenux documents reverse proxy support for Nginx and Traefik. A reverse proxy is optional for the direct workflow in this guide. If your environment already uses one, the correct target and hostname configuration depend on your existing proxy rules, certificates, and local network design.
Which command shows recent ProxMenux Monitor errors?
Run journalctl -u proxmenux-monitor -n 50 on the Proxmox host. It displays the latest 50 entries for the Monitor's systemd unit. Sanitize logs before sharing them so they do not reveal credentials, private endpoints, or sensitive infrastructure information.
Why did remote access stop even though the tunnel still exists in the dashboard?
A saved tunnel configuration is not the same as a running tunnel. Confirm that the selected client device is connected and that the tunnel has been started. Also verify that proxmenux-monitor.service is active and that the client device can still reach the Proxmox address on port 8008.
Access your verified ProxMenux Monitor with Localtonet
Once the dashboard works locally and its authentication is secured, create a Localtonet HTTP tunnel to the reachable Proxmox host address on port 8008. Keep the client connected while access is needed, and stop the tunnel when the remote route is no longer required.
Get Started Free →
