Build a dependable UPS monitoring workflow first, then make the dashboard available when you are away
Eneru is a self-hosted monitoring and shutdown orchestration layer for Network UPS Tools. It can monitor one or more UPS devices, evaluate independent shutdown policies, coordinate local and remote resources, and present operational data through a browser dashboard. This guide covers the installation choices documented by Eneru, a practical container deployment, native package installation, configuration validation, startup, local verification, and safe operational practices. After the local service works, we connect its HTTP dashboard to a Localtonet HTTP tunnel as a separate remote-access step.
📋 What's in this guide
Understand the Eneru and NUT architecture
Eneru does not replace Network UPS Tools, commonly called NUT. NUT remains responsible for UPS drivers, communication with the physical hardware, and the upsc data model. Eneru sits above that layer. It reads the UPS information supplied by NUT, evaluates policy, records events, presents status to operators, and decides which shutdown actions should run.
This distinction matters during setup and troubleshooting. If NUT cannot communicate with a UPS, installing Eneru will not repair the underlying driver or hardware connection. Establish NUT communication first. Eneru can then consume a local or network-accessible NUT endpoint and coordinate the systems protected by each UPS.
A basic NUT deployment may be sufficient for a single workstation with one UPS and no dependent services. Eneru becomes more relevant when a power event has an ordered operational impact. Examples include stopping virtual machines before their hypervisor, releasing network storage before shutting down a NAS, stopping containers before powering off their host, or applying separate policies to UPS devices protecting different racks.
A typical policy sequence is: detect a power event, evaluate the configured triggers, stop local virtual machines, stop compose stacks, stop remaining containers, synchronize and unmount filesystems, shut down remote servers by phase, and finally power off the local host. Every phase is optional. Multi-UPS deployments apply the resource sequence per UPS group, while redundancy groups wait until the configured quorum is lost.
The browser interface shows information collected by Eneru, but the underlying UPS data still comes from NUT. When the dashboard reports an unavailable UPS, investigate the NUT endpoint, UPS name, network path, and credentials before treating the issue as an HTTP dashboard problem.
Prepare the host, NUT service, and deployment plan
Before installing Eneru, decide which machine will run it and what that instance is allowed to control. The answer affects whether a native package, a remote-only container, or a container with local-host ownership is appropriate.
Confirm that NUT already exposes the UPS data
Eneru expects a working NUT installation. At minimum, identify the NUT UPS name and the host that serves it. The documented configuration format represents this as a value such as UPS@192.168.1.100. For a multi-UPS deployment, collect one NUT name and address for each device.
Do not continue to shutdown automation based only on an assumed UPS name. Verify the identifiers in the existing NUT environment. Also confirm that the Eneru host can reach every NUT server over the local network. Exact NUT driver configuration, authentication, and hardware support depend on the UPS and the existing NUT deployment, so they are outside the scope of commands that can safely be generalized here.
Inventory every resource affected by a power event
Write down which UPS powers each host, storage system, network device, VM, and container group. Then identify dependencies. A compute node may need to stop before a storage appliance, while a hypervisor must remain available until its guests are down. A dual-power-supply server may belong to a redundancy group instead of a single UPS shutdown group.
Assign only one local-shutdown owner. Eneru supports multiple UPS groups, but the host running Eneru must not receive conflicting local power-off decisions from unrelated groups. The project documentation describes one local-shutdown owner for the instance.
Choose an installation method
| Installation method | Best fit | Important behavior |
|---|---|---|
| OCI container with Docker or Podman | Remote monitoring, remote shutdown orchestration, and an isolated deployment | The documented image publishes the dashboard and API on host TCP port 9191. Full ownership of the container host requires additional SSH loopback configuration and mounts. |
| Debian or Ubuntu package | A native systemd-managed installation | The package exposes the eneru command on PATH and installs the native application under /opt/ups-monitor/. |
| RHEL or Fedora package | A native RPM-based systemd deployment | The package is installed from the documented Eneru repository after enabling EPEL. |
| PyPI | User-managed or developer-managed Python environments | The documented package installs the eneru command. Python environment creation and service supervision remain the operator's responsibility. |
This guide provides a complete remote-only container workflow because it has an explicitly documented HTTP endpoint and published port. It also includes the official native package and PyPI installation commands. Full local-host control from a container is a different security profile because the container must be able to initiate actions against its own host through the project's SSH loopback delegate.
Begin with monitoring and non-destructive verification. A syntax-valid configuration can still describe the wrong server, UPS, shutdown order, or threshold. Confirm live UPS identity and resource assignments before enabling local shutdown, remote SSH actions, VM teardown, container stops, filesystem unmounting, or NUT control operations.
Install Eneru using the appropriate supported method
Option 1: Docker or Podman remote-only deployment
The official OCI image is suitable for both remote-only and local-host deployments. The following documented quick start creates a persistent Eneru container, publishes the HTTP dashboard and API on port 9191, mounts the configuration read-only, and provides persistent locations for state, runtime data, and SSH material.
Before running it, create the host directories represented by /srv/eneru/state, /srv/eneru/run, and /srv/eneru/ssh. Create /srv/eneru/config.yaml as a file, not a directory. Adjust the parent location if your storage layout differs, then update every corresponding mount consistently.
docker pull ghcr.io/m4r1k/eneru:latest
docker run -d --name eneru \
--restart unless-stopped \
-p 9191:9191 \
-v /srv/eneru/config.yaml:/etc/ups-monitor/config.yaml:ro \
-v /srv/eneru/state:/var/lib/eneru \
-v /srv/eneru/run:/var/run/eneru \
-v /srv/eneru/ssh:/var/lib/eneru/ssh \
ghcr.io/m4r1k/eneru:latest \
run --config /etc/ups-monitor/config.yaml \
--api --api-bind 0.0.0.0 --api-port 9191Podman can use the same OCI image and Eneru entry point, but container-specific host integration can differ. Do not translate Docker options mechanically if the host has different volume-labeling, rootless-networking, or service-management requirements. Verify the resulting mount access and published port in the selected runtime.
If remote server shutdown uses private keys, private key files under /srv/eneru/ssh must use mode 0400. The directory itself needs to remain writable because Eneru persists learned SSH host keys in known_hosts. Never place an SSH private key in the public dashboard, in a Localtonet token field, or directly inside a command that will be stored in shell history.
Monitoring a NUT endpoint and coordinating remote servers does not give the container safe control of its own host. Full local-host ownership requires the project's SSH loopback delegate, host networking, a read-only machine identity mount, an SSH key, and the associated security model. The documented additions include --network host and -v /etc/machine-id:/etc/machine-id:ro. Hosts without systemd may not have /etc/machine-id and use a marker file instead. Because the supplied evidence does not include the complete loopback key procedure, this guide does not invent it. Keep the deployment remote-only unless you have implemented and reviewed the complete documented delegate workflow.
Option 2: Debian or Ubuntu package
The native package method adds the Eneru signing key and APT repository, refreshes package metadata, and installs Eneru:
curl -fsSL https://m4r1k.github.io/Eneru/KEY.gpg | sudo gpg --dearmor -o /usr/share/keyrings/eneru.gpg
echo "deb [arch=all signed-by=/usr/share/keyrings/eneru.gpg] https://m4r1k.github.io/Eneru/deb stable main" | sudo tee /etc/apt/sources.list.d/eneru.list
sudo apt update
sudo apt install eneru
The native package uses /etc/ups-monitor/config.yaml for the documented configuration workflow. Package installations expose eneru on PATH even though the package itself is installed under /opt/ups-monitor/. The systemd unit uses the package wrapper internally.
Option 3: RHEL or Fedora package
On the documented RPM-family path, enable EPEL, install the Eneru repository definition, and install the package:
sudo dnf install -y epel-release
sudo curl -o /etc/yum.repos.d/eneru.repo https://m4r1k.github.io/Eneru/rpm/eneru.repo
sudo dnf install eneru
As with the Debian and Ubuntu package, use the native systemd workflow after preparing and validating /etc/ups-monitor/config.yaml.
Option 4: PyPI
Eneru can also be installed from PyPI with notification support:
pip install eneru[notifications]
This installs the eneru command in the selected Python environment. The official extracted material does not establish a universal Python version, virtual-environment command, privilege model, or operating-system package list, so none should be guessed. Confirm that the active environment places eneru on PATH and choose an appropriate process supervisor if this is intended to run continuously.
Configure single-UPS or multi-UPS monitoring
Native package users edit /etc/ups-monitor/config.yaml. Container users edit the host file mounted at /srv/eneru/config.yaml in the example above. Because the container mount is read-only, make changes on the host rather than trying to edit the file from inside the container.
Start with a single UPS
The documented single-UPS example identifies one NUT UPS, gives it a readable dashboard name, sets battery and runtime thresholds, and enables local shutdown:
ups:
name: "UPS@192.168.1.100"
display_name: "Main UPS"
triggers:
low_battery_threshold: 20
critical_runtime_threshold: 600
local_shutdown:
enabled: true
Replace the UPS name and address with the verified values from your NUT environment. The values 20 and 600 are examples, not universal recommendations. Threshold selection depends on battery condition, actual load, shutdown duration, service dependencies, and the time needed to leave a safety margin.
For an initial monitoring test, do not copy local_shutdown.enabled: true without understanding its effect. Enabling it means the policy can eventually power off the Eneru host when its trigger conditions are met. Build and verify the non-destructive monitoring path first, then deliberately enable local ownership when the host and shutdown sequence have been tested.
Define multiple UPS groups
A multi-UPS configuration uses a list. The documented example assigns a local UPS to Rack A and associates a Proxmox node with it. A second UPS protects Rack B and has a NAS as its remote server:
ups:
- name: "UPS1@192.168.1.10"
display_name: "Rack A UPS"
is_local: true
remote_servers:
- name: "Proxmox Node"
enabled: true
host: "192.168.1.20"
user: "root"
- name: "UPS2@192.168.1.11"
display_name: "Rack B UPS"
remote_servers:
- name: "NAS"
enabled: true
host: "192.168.1.30"
user: "admin"Treat every address and account in that sample as a placeholder. Match each resource to the UPS that actually supplies it. If a server has redundant power feeds, model the intended quorum behavior rather than assigning it casually to whichever UPS appears first.
The remote account must have only the authority required for the planned operation. Avoid broad administrative access where a narrower shutdown mechanism is possible. SSH host verification and private-key permissions are part of the safety boundary. A successful TCP connection alone does not prove that Eneru can safely identify and stop the intended system.
Plan triggers around measured shutdown time
Eneru supports six trigger paths: battery level, remaining runtime, observed depletion rate, extended time on battery, a forced shutdown signal, and a connection-loss failsafe. Independent triggers address different failure modes, but more triggers do not automatically make a policy safer. A poorly chosen value can produce an early shutdown or leave too little time to complete the sequence.
Measure how long each phase takes under normal conditions. Include guest shutdown timeouts, storage flushes, unmounting, remote-host phases, and the final local shutdown. Then compare the total with observed battery behavior under realistic load. UPS-provided runtime estimates can change as load changes, which is one reason Eneru can also calculate depletion from observed battery data.
Eneru 6.1 added battery-health scoring from 0 to 100, replacement prediction, energy and optional cost tracking, scheduled NUT self-tests, periodic reports, and a read-only shutdown-plan view. The battery_health, energy, self_test, and reports subsystems are opt-in. Do not add guessed YAML keys from feature names alone. Use configuration syntax that matches the installed release.
Validate the configuration and start Eneru
Native package workflow
Edit the native configuration file
Open /etc/ups-monitor/config.yaml with an editor that has permission to save the file. Enter the verified NUT names, addresses, display names, UPS groups, and only the resource actions you are ready to test.
Validate the YAML and Eneru configuration
Run eneru validate --config /etc/ups-monitor/config.yaml. Resolve every reported validation error before starting or restarting the service.
Enable and start the systemd service
Run sudo systemctl enable --now eneru.service. This starts the service now and configures it to start through systemd on future boots.
Observe monitoring in real time
Run eneru monitor --config /etc/ups-monitor/config.yaml and confirm that the expected UPS devices appear with plausible live values.
sudo nano /etc/ups-monitor/config.yaml
eneru validate --config /etc/ups-monitor/config.yaml
sudo systemctl enable --now eneru.service
eneru monitor --config /etc/ups-monitor/config.yamlThe commands above establish the documented native validation and service workflow. Enabling the embedded browser dashboard for a native service may require release-specific configuration. The available evidence does not establish the complete native API configuration block, so this article does not invent one. Confirm the dashboard settings for the installed Eneru version before expecting port 9191 to listen on a package deployment.
Container workflow
For the container deployment, validate the host configuration before relying on automated actions. The published quick-start command starts Eneru with run, points it at the mounted configuration, enables the API, binds it to 0.0.0.0 inside the container, and listens on port 9191. Docker publishes that port to the host through -p 9191:9191.
If the container exits immediately, do not repeatedly restart it without inspecting the cause. Common categories include invalid YAML, an invalid Eneru setting, a host path that was created as the wrong type, unreadable mounted files, or an unavailable NUT endpoint.
Verify monitoring and the dashboard locally
Remote access should be the last verification step, not the first. A Localtonet tunnel can expose a working local service, but it cannot correct an invalid Eneru policy, failed NUT connection, stopped container, or HTTP server that is not listening.
Check the process and UPS data
Confirm that the systemd service or container remains running. Then use the documented monitor command on a native installation and verify that every configured UPS appears. Check the UPS name, online or battery state, charge, runtime, and any other available values against the existing NUT output and the physical device.
In a multi-UPS deployment, verify each group separately. A dashboard containing two devices is not sufficient if their resource assignments are reversed. Confirm that Rack A shows Rack A's UPS and resources, Rack B shows Rack B's, and any redundancy group reflects the actual power-feed topology.
Open the local HTTP dashboard
The documented container command exposes the embedded HTTP dashboard and API on TCP port 9191. From the Eneru host, open:
http://127.0.0.1:9191
If testing from another machine on the same LAN, use the Eneru host's reachable LAN address instead of 127.0.0.1. That test also depends on the host firewall and container port publication. Do not change firewall policy merely to make remote internet access work. Localtonet uses an outbound client connection and does not require inbound router port forwarding or a public IP.
Confirm that HTTP is the correct local protocol
The documented command enables an HTTP service with --api-port 9191. The supplied Eneru evidence does not establish HTTPS on that local endpoint. Therefore, configure the Localtonet side as an HTTP tunnel pointing to the local HTTP service rather than assuming that Eneru provides local TLS.
Configuration validation checks whether Eneru accepts the configuration. It does not prove that an IP address belongs to the intended server, that a threshold leaves enough battery time, or that an SSH command affects only the expected host. Test the project's dry-run behavior and review the shutdown-plan view before relying on a live outage. The exact dry-run command is not present in the supplied evidence, so it is intentionally not guessed here.
Securely reach the Eneru dashboard with Localtonet
Once http://127.0.0.1:9191 works locally, an HTTP tunnel can provide a public HTTPS address for remote browser access. Our client runs on the Eneru host, or on another device that can reach it, and establishes an outbound connection to a Localtonet relay server. This removes the need for inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
The tunnel is available only while the selected Localtonet client device is connected and the tunnel is running. Creating a tunnel configuration does not start it automatically. It must be started from the dashboard, and it can later be stopped or deleted.
Install and run our client on a device that can reach Eneru
The simplest topology places the Localtonet client on the same host that publishes port 9191. If it runs elsewhere, first verify that the client device can reach Eneru through the LAN address and port.
Authenticate the correct client device
Select the device using its Localtonet authentication token. Tokens are device-specific. Obtain the token from the current dashboard, keep it secret, and never place it in an article, screenshot, repository, Eneru YAML file, or shared command history.
Open the HTTP tunnel configuration
Create an HTTP tunnel because the documented Eneru endpoint is HTTP. Choose the appropriate HTTP process type for a generated random subdomain, a supported custom subdomain, or a custom domain.
Select an available relay server
Choose a currently available server or region from our dashboard. Do not copy a server code from an old tutorial because availability can vary by account, plan, region, and product version.
Set the local Eneru target
When our client is on the Eneru host, use local IP address 127.0.0.1 and local port 9191. When it is on another LAN device, use an address through which that client can already reach the Eneru host.
Start the tunnel and test the assigned address
Press Start, wait for the tunnel to run, and open the assigned public HTTPS URL. Confirm that the expected Eneru dashboard loads and that stopping the tunnel removes public reachability.
For current dashboard details, see our HTTP tunnel documentation. HTTP and File Server process types can provide a random subdomain, a supported custom subdomain, or a custom domain. Exact custom-domain DNS requirements must be checked against the current documentation instead of being inferred.
| Client location | Local target | What to verify first |
|---|---|---|
| Same host as the Eneru container | 127.0.0.1:9191 |
The dashboard opens locally on the host and the container publishes port 9191. |
| Another device on the same LAN | Eneru host LAN address with port 9191 |
The Localtonet client device can open the dashboard over the LAN before a tunnel is created. |
| Native Eneru package host | The address and port configured for its embedded HTTP service | The installed release is explicitly configured to enable the dashboard and is listening locally. |
Eneru provides authenticated API write paths, but that does not justify assuming that every dashboard route, read operation, or deployment is protected exactly as required for internet exposure. Configure Eneru authentication for the installed release, protect credentials, review any enabled UPS control actions, and apply least privilege before starting a public tunnel. Stop the tunnel when remote access is not needed.
Operate and maintain the deployment safely
Use a deliberate change workflow
Treat power automation as production infrastructure even in a homelab. Keep a backup of the last known-good configuration, change one policy area at a time, validate the result, and observe the live status before enabling new destructive actions. Config hot-reload is available in recent Eneru releases, but only documented safe reloads should be assumed. A successful reload still requires operational verification.
When changing a UPS address or resource assignment, verify it immediately against live data. When changing a threshold, review whether the full shutdown sequence still fits inside the available battery window. When adding a remote server, verify SSH identity and permissions without waiting for a real outage.
Protect persistent state and SSH material
The container layout stores state in /srv/eneru/state, runtime material in /srv/eneru/run, and SSH information in /srv/eneru/ssh. Include persistent state and the configuration in an appropriate backup policy. Protect SSH private keys more strictly than ordinary application state, retain file mode 0400, and avoid copying them into images or public repositories.
Eneru records historical information and events in SQLite. Recent releases also expose battery-health, energy, self-test, reporting, API, MQTT, and Prometheus surfaces when configured. Monitor storage consumption and back up the information that matters to your operating history.
Review updates before rollout
Eneru v6.1 introduced battery-health scoring, projected replacement information, energy and cost tracking, scheduled self-tests, reports, and a rebuilt dashboard. The release information also notes that later 6.1 updates support the official OCI image on AMD64 and ARM64. Package and latest image channels can move to newer builds, so review changes and preserve a rollback path before updating an installation that controls shutdown.
A v6.0 to v6.1 upgrade is described as drop-in, with the statistics database migrating to schema version 7 on first start. Even when a migration is automatic, back up the configuration and persistent state first. Do not assume that a database changed by a newer release can be opened safely by an older image during rollback.
Control the Localtonet tunnel lifecycle
Keep remote access separate from service availability. Eneru can continue monitoring locally when the Localtonet tunnel is stopped. Start the tunnel when remote browser access is needed, verify the assigned address, and stop or delete it when the access path should no longer exist.
If the tunnel must be monitored centrally, Localtonet platform-wide Token/Tunnel webhooks can report Connected and Disconnected changes for a selected Token Group. These are lifecycle events, not Eneru UPS events. They post a body containing the relevant identifier, action date, type, and status. Do not confuse a disconnected tunnel notification with a NUT power event or an Eneru shutdown trigger.
Troubleshoot installation, monitoring, and remote access
Eneru rejects the YAML configuration
Run the documented validation command and address the first reported error:
eneru validate --config /etc/ups-monitor/config.yaml
Check indentation, whether ups is represented as a mapping for the single-UPS example or a list for multiple UPS devices, and whether fields belong at the expected level. Do not add feature names as guessed configuration keys. Configuration syntax can evolve between releases.
The container starts and then exits
Confirm that /srv/eneru/config.yaml is a readable file and not a directory accidentally created by the container runtime. Confirm that each mounted host directory exists with suitable access. Then check whether Eneru can parse the configuration and reach the configured NUT server. A restart policy can repeatedly launch a broken container, but it cannot correct its configuration.
The dashboard does not open on port 9191
For the documented container command, verify that it includes -p 9191:9191 and the Eneru arguments --api --api-bind 0.0.0.0 --api-port 9191. Test http://127.0.0.1:9191 from the host first. If the same host test fails, troubleshoot the container and Eneru API before Localtonet.
On a native package installation, do not assume the API is enabled simply because the service is running. The extracted evidence does not provide a universal native API configuration block. Use settings that match the installed Eneru release, then verify the listening address and port locally.
The dashboard opens, but a UPS is unavailable
This normally separates into a NUT-side issue, a name mismatch, or a network-reachability issue. Confirm that the configured value such as UPS1@192.168.1.10 matches the actual NUT name and host. Verify that the NUT service is running and that the Eneru environment can reach it. Container networking can differ from host networking, so a NUT address reachable from the host is not automatically proof that the container has the same path.
Local access works, but the public URL does not
Confirm that the selected Localtonet client device is connected and that the tunnel has been started. Check that the tunnel type is HTTP and that its target matches the address reachable from that client. Use 127.0.0.1:9191 only when our client shares the Eneru host. A client on another machine needs a reachable LAN target.
Also verify that the selected relay server is currently available in the dashboard. Do not hardcode a server code from another account or region. Remember that creating the tunnel is separate from starting it.
Remote server shutdown fails
Review the remote host address, SSH user, key permissions, host identity, and granted command authority. Private key files in the documented container SSH directory must use mode 0400, while the directory remains writable for known_hosts. Do not disable host identity checks merely to make the first connection succeed. A shutdown system must be certain which machine it is controlling.
The public dashboard is reachable without the expected protection
Stop the Localtonet tunnel immediately while reviewing Eneru authentication and control settings. Do not rely on an unguessable URL as the only control. Authentication behavior can depend on the Eneru release and enabled dashboard/API settings. Reopen the tunnel only after testing the intended access restrictions from a separate browser session.
Frequently asked questions
Does Eneru replace Network UPS Tools?
No. NUT communicates with the UPS hardware, manages drivers, and supplies the UPS data model. Eneru consumes that data and adds monitoring, policy evaluation, multi-UPS grouping, ordered shutdown orchestration, history, notifications, dashboards, and related observability.
Can one Eneru instance monitor several UPS devices?
Yes. Eneru supports multiple UPS groups with independent resources, triggers, and shutdown policies. The configuration uses a list under ups. Carefully map each server and dependent resource to its actual power source, and use redundancy groups for systems that depend on a quorum of power feeds.
Which Eneru installation method should I use?
Use the method that matches the ownership model. A remote-only OCI container is suitable for monitoring and remote orchestration with isolation. Native Debian, Ubuntu, RHEL, or Fedora packages fit systemd-managed host integration. PyPI fits user-managed Python environments. A container that must shut down its own host requires the project's complete SSH loopback delegate setup and should not be treated as an ordinary remote-only container.
What port does the documented Eneru container dashboard use?
The documented container command enables the embedded API and dashboard on TCP port 9191, binds it to 0.0.0.0 inside the container, and publishes host port 9191. Test it locally at http://127.0.0.1:9191 from the container host.
Should I use an HTTP or TLS tunnel for Eneru?
Use an HTTP tunnel for the documented local endpoint because the published Eneru command serves HTTP on port 9191 and the supplied evidence does not establish local HTTPS. With Localtonet, the HTTP tunnel provides a public HTTPS address while forwarding to the local HTTP service.
Does Localtonet require router port forwarding?
No. Our client establishes an outbound connection to a Localtonet relay server. You do not need inbound router port forwarding, a public IP address, VPN setup, or firewall changes for the tunnel itself. The client device must still be able to reach the local Eneru HTTP target.
Does creating a Localtonet tunnel make it active immediately?
No. Creating the configuration and running it are separate lifecycle actions. Select the correct client device, create the HTTP tunnel, and press Start. The public address remains available only while the selected client is connected and the tunnel is running.
Can a containerized Eneru instance shut down its own host?
Eneru supports full local-host ownership from a container through its SSH loopback delegate, including local VM, container, compose, filesystem, and host actions. That deployment requires additional mounts, host networking, a loopback SSH key, and a reviewed security model. A standard remote-only container should not be assumed to have those capabilities.
Is configuration validation enough before relying on automatic shutdown?
No. Validation confirms that Eneru accepts the configuration. It cannot confirm physical power topology, server identity, real battery duration, SSH permissions, or the time required by each shutdown phase. Use non-destructive monitoring, dry-run testing, and the read-only shutdown-plan view before enabling live destructive actions.
Reach your verified Eneru dashboard with Localtonet
Install and validate Eneru, confirm that its HTTP dashboard works locally on port 9191, then create a Localtonet HTTP tunnel from a connected device that can reach the service. Keep the device token private, review Eneru authentication, and start the tunnel only when remote access is appropriate.
Get Started Free →
