Deploy the Go control panel locally, verify its proxy path, and optionally reach the administration interface through Localtonet
nginx-reverse-emby is a self-hosted control panel for HTTP and HTTPS reverse proxies, TCP and UDP forwarding, certificates, agents, and relay connections. This guide covers its Docker Compose deployment, required tokens, local verification, first proxy rule, remote-agent onboarding, and routine operations. Only after the panel works locally at http://127.0.0.1:8080 do we add an optional Localtonet HTTP tunnel for remote administration. Localtonet is not required to host nginx-reverse-emby or publish the services managed by it.
📋 What's in this guide
What nginx-reverse-emby does and where Localtonet fits
Despite its historical name, nginx-reverse-emby is not limited to Emby and its current default runtime does not depend on Nginx. The project uses a Go control plane and Go agents. A standard Docker Compose deployment starts the control panel together with a local agent, giving one server a browser-based interface for defining and managing network forwarding rules.
HTTP and HTTPS rules route requests by hostname to backend web services. HTTPS rules can use ACME certificate issuance and renewal through HTTP-01 or Cloudflare DNS-01, and administrators can also upload public certificates manually. Layer 4 rules forward TCP or UDP ports, can use multiple backends, and support PROXY Protocol when every component in the path is configured compatibly.
A new single-server installation includes a node named local. Rules assigned to that node are synchronized to the agent running beside the control plane. Additional agents can be enrolled on other machines, including machines behind NAT, because the agents initiate their connections to the panel. The project also includes its own relay mode for cases in which an entry node cannot directly reach a backend.
You can review the current source, Compose definition, deployment script, and release history in the official nginx-reverse-emby repository. The official nginx-reverse-emby documentation site contains the maintained deployment, environment-variable, agent, certificate, backup, recovery, upgrade, revision, and troubleshooting guidance. Check those pages before applying a production upgrade because project-specific procedures can change after this article is published.
127.0.0.1:8080 by default instead of listening on every host interface.
Localtonet is a separate, optional access layer
nginx-reverse-emby and Localtonet have some overlapping networking use cases, but they are separate systems in this tutorial. nginx-reverse-emby manages its own HTTP, HTTPS, TCP, UDP, agent, and relay configurations. Localtonet provides an optional browser path to the locally bound management panel after the project has been installed and verified.
With Localtonet, our client on the server establishes an outbound connection to a Localtonet relay server. An HTTP tunnel can then connect a public HTTPS address to the panel's local HTTP endpoint. This does not require inbound router port forwarding, a VPN setup, or a public IP address. The public route remains available only while the selected Localtonet client is connected and the tunnel is running.
nginx-reverse-emby has its own agents and relay functionality for forwarding managed services. The Localtonet HTTP tunnel described here is a separate path to 127.0.0.1:8080. Do not enter Localtonet device credentials into the project or use the project's registration token as a Localtonet token.
Prerequisites and deployment decisions
The project's documented quick-start target is a Linux VPS that can run Docker. The manual path also requires Docker Compose through the docker compose command. The recommended deployment script can offer to install Docker Compose if it is missing, but allowing a downloaded script to install system software is an administrative decision. Review the script and understand the changes before approving them.
You do not need a public domain merely to start the panel and verify it through loopback or SSH forwarding. A domain becomes necessary when you want nginx-reverse-emby itself to publish an HTTP or HTTPS rule by hostname. For the documented public HTTPS example, DNS must resolve to the entry server and the relevant firewall must allow ports 80 and 443.
Those public proxy requirements are distinct from Localtonet panel access. A Localtonet tunnel targets the already running panel at 127.0.0.1:8080 through an outbound client connection. Do not open inbound port 8080 simply to use that workflow.
Verify backend reachability before creating a rule
Determine the actual backend address before adding a proxy rule. A backend can be an HTTPS service such as https://origin.example.net or a private service such as http://192.168.1.100:8096. Use an address from your environment rather than copying an example.
curl -I https://origin.example.netRun that request from the VPS or from the agent machine that will handle the rule. If the selected agent cannot resolve or connect to the backend, the reverse-proxy rule cannot make it reachable. An HTTP response confirms basic DNS resolution, routing, and application reachability, although it does not prove that every application feature will work through a proxy.
| Requirement | Needed for | Important detail |
|---|---|---|
| Linux host with Docker | Running the documented deployment | The project recommends a Linux VPS for its quick-start workflow. |
| Docker Compose | Manual installation and operations | The documented startup command is docker compose up -d. |
| Two separate random tokens | Panel login and remote-agent enrollment | API_TOKEN and MASTER_REGISTER_TOKEN must each contain at least 32 characters and must not match. |
| Reachable backend | Creating a functional proxy rule | Test it from the agent machine before adding the rule. |
| Domain and suitable DNS | Public hostname rules managed by the project | DNS must resolve to the entry server for the documented HTTP and HTTPS workflow. |
| Ports 80 and 443 | Documented public HTTP/HTTPS and certificate flow | The entry server's firewall and upstream network must permit the required traffic. |
| Localtonet client and device token | Optional Localtonet panel access | Run the client where it can reach 127.0.0.1:8080, and never publish the token. |
Choose an installation path
The project documents two primary paths. Its recommended deployment script creates the directory, generates random tokens, and starts the service. The manual Docker Compose route gives you direct control over the downloaded Compose file and environment values. Both create a control-plane and local-agent deployment, but the manual path makes configuration review and backup planning more explicit.
The recommended command downloads a script and passes it directly to a shell. Review the current script and repository state first. Use a controlled host, confirm the download origin, and do not run unfamiliar code with elevated permissions without understanding its effects.
Install nginx-reverse-emby
Option A: use the recommended deployment script
The project's recommended workflow uses its deployment script. The script creates the required directory, generates random token values, and starts the services. If Docker Compose is not installed, the script asks before attempting to install it.
curl -fsSL https://raw.githubusercontent.com/sakullla/nginx-reverse-emby/main/scripts/deploy-compose.sh | shThe normal interactive flow asks for a panel domain. If DNS for a domain already resolves to the server, enter that domain. Pressing Enter without a domain selects the project's temporary HTTP workflow. The script can also ask for an optional Cloudflare token. Supplying one enables the DNS-01 path, while leaving it empty uses HTTP-01 when the surrounding DNS and inbound network configuration can satisfy that challenge.
A Cloudflare API token used for DNS-01 must have Zone Read, DNS Read, and DNS Edit permissions for the relevant zone. The project explicitly warns against using a Global API Key. Keep the token out of terminal recordings, screenshots, shell history shared with other people, public issue reports, and unprotected configuration archives.
When installation finishes, the script prints an access address and a panel token. Save the token in an approved password manager or secret store. A new deployment does not use a conventional username and password. The panel token is the login credential.
Option B: perform a manual Docker Compose installation
Use the manual route when you need to inspect the Compose configuration before deployment or manage its environment values through your existing configuration process. The following sequence matches the current repository quick start.
Create and enter the deployment directory
Keep the Compose definition, environment configuration, and persistent data in a dedicated directory.
mkdir -p nginx-reverse-emby && cd nginx-reverse-embyDownload the project-maintained Compose file
Retrieve the current docker-compose.yaml, then inspect its image, ports, volumes, networks, and environment definitions before starting it.
curl -O https://raw.githubusercontent.com/sakullla/nginx-reverse-emby/main/docker-compose.yamlCreate the persistent data directory
The Compose deployment stores runtime state under the local data directory. Protect it as sensitive application data.
mkdir -p dataConfigure separate login and registration tokens
Edit docker-compose.yaml, or use an environment file based on the repository's .env.example. Set API_TOKEN for panel login and MASTER_REGISTER_TOKEN for remote-agent enrollment. Each must be a different random string containing at least 32 characters. Set NRE_TIMEZONE for your deployment.
environment:
API_TOKEN: <panel-login-token>
MASTER_REGISTER_TOKEN: <remote-node-registration-token>
NRE_TIMEZONE: Asia/ShanghaiStart the Compose deployment
Run the documented startup command from the directory containing docker-compose.yaml.
docker compose up -d
Asia/Shanghai is the value shown in the project's example, not a universal recommendation. Replace it when another timezone is appropriate for your server, users, logs, or operating procedures.
Configure an explicit Secret Vault master key when needed
If PANEL_VAULT_MASTER_KEY is empty, the project derives the Secret Vault key from API_TOKEN. If you may rotate the panel login token later, the project recommends setting an explicit master key in advance so the vault master key is not coupled to the login credential.
openssl rand -hex 32Store the generated value securely, then configure it together with the documented key identifier:
environment:
PANEL_VAULT_MASTER_KEY: <generated-secret-value>
PANEL_VAULT_KEY_ID: primary
If secrets are stored in a .env file, restrict its permissions as directed by the project:
chmod 0600 .env
Do not commit real tokens, Cloudflare credentials, certificates, private keys, the .env file, or the data directory to Git. Do not reuse the panel login token, agent registration token, Localtonet device token, Cloudflare token, or vault key for another purpose.
Verify the local control panel before publishing anything
In the documented manual deployment, the panel listens on the host's loopback interface at http://127.0.0.1:8080. Loopback binding prevents an arbitrary remote machine from directly connecting to that socket through the server's public interface. It also means that opening http://server-address:8080 from your workstation is not the correct first test.
Check the endpoint on the server
curl -I http://127.0.0.1:8080The exact status can depend on the application's handling of a HEAD request and its authentication flow. The important first result is an HTTP response rather than a connection-refused or timeout error. If no service responds, inspect the Compose status and logs before introducing DNS, certificates, public rules, or Localtonet.
Open the panel through SSH local forwarding
The project recommends SSH local forwarding for initial access when no public panel domain has been configured. Run this from your workstation, replacing the placeholders with the real SSH account and server address:
ssh -L 8080:127.0.0.1:8080 root@<server-ip>
Keep the SSH session open and visit http://127.0.0.1:8080 in a browser on the workstation. The browser connects to local port 8080, SSH forwards the connection to the server, and the server delivers it to its own loopback-bound panel.
Log in with the value configured as API_TOKEN, or with the panel token printed by the deployment script. A new installation has no separate username and password. Successful login confirms the panel endpoint, token, browser path, and control-plane service are working.
Do not use Localtonet to diagnose a panel that does not already respond at 127.0.0.1:8080. Local verification separates project deployment failures from tunnel configuration failures.
Create and verify the first reverse-proxy rule
Logging in proves that the control panel is available, but it does not prove that the local agent can apply and serve a forwarding rule. The project's quick start uses an HTTP rule assigned to the built-in local node.
Confirm the backend is reachable
From the VPS, request the actual backend address. Resolve DNS, routing, certificate, or firewall failures before creating the rule.
Open HTTP Rules
In the panel, open Traffic Management, then HTTP Rules. Select the existing local node for a single-server deployment.
Enter the public hostname and backend URL
Set the entry hostname, such as https://emby.example.com, and the complete backend address, such as https://origin.example.net. Include the backend protocol and any nonstandard port.
Enable and save the rule
The rule must be enabled to take effect. Save it so the control plane can synchronize the new configuration to the local agent.
Test the entry hostname
Confirm DNS points to the VPS and that ports 80 and 443 are allowed for the documented HTTP/HTTPS workflow. Open the entry hostname and verify that the backend application responds.
Configuration synchronization is asynchronous. Saving a rule initiates the configuration process, but it should not be treated as proof that the agent has already applied the new revision. Confirm the node remains connected, allow the configuration to synchronize, and test the actual entry hostname before considering the change complete.
Understand the certificate requirements
An HTTPS rule can trigger automatic certificate issuance, but issuance still depends on the selected challenge being able to validate the domain. HTTP-01 requires the public domain and network route to reach the entry server. Cloudflare DNS-01 requires control of the correct DNS zone and a properly scoped Cloudflare API token.
The project's managed-certificate system scans for renewal work every 24 hours by default. One ACME issuance or renewal operation can run for up to 60 minutes by default. If it times out, the project records the failure and continues processing other certificates. The documented environment variables NRE_MANAGED_CERT_RENEW_INTERVAL and NRE_MANAGED_CERT_ACME_TIMEOUT can adjust those behaviors when an operator has a specific reason to do so.
Join additional nginx-reverse-emby agents
A single-server installation does not require remote-agent enrollment. Its built-in local node is sufficient when the control plane and forwarding entry point run on the same machine. Add another agent only when another server must run proxy rules, reach a different private network, or participate in the project's relay topology.
Open node management
Log in to the panel and open its node-management area.
Choose Join Node
Select the option to join another node. Do not manually invent an enrollment command or copy one from an unrelated deployment.
Select the target operating system
Choose Linux or macOS and copy the generated one-command installation procedure. For Windows, follow the project's Agent Guide from the official documentation site.
Run the generated procedure on the target machine
Execute the panel-generated onboarding procedure on the server that will become the agent. The agent initiates its connection to the panel and pulls configuration, which allows nodes behind NAT to participate when their outbound path is available.
Treat MASTER_REGISTER_TOKEN as an enrollment secret. It is not the panel login token and should not be entered into the Localtonet client. If the registration token is exposed, rotate it according to the current project documentation and verify which pending or existing enrollment paths are affected.
An onboarding command installs and configures software on the target machine. Confirm that the command was generated by your intended panel, check the destination address, and avoid sharing the command because it can contain registration material.
Access the control panel with an optional Localtonet tunnel
Once http://127.0.0.1:8080 works, you can create a Localtonet HTTP tunnel to that endpoint. This provides remote browser access without publishing host port 8080 through a router or opening a direct inbound firewall rule. It also works without a public IP because our client establishes the relay connection outbound.
Install the Localtonet client on the nginx-reverse-emby server. Placement matters because 127.0.0.1 always identifies the machine on which the connecting client runs. A Localtonet client running on your laptop would target the laptop's loopback interface, not the panel on the server.
Client installation details can vary by operating system and version. Use the current Localtonet download and dashboard instructions rather than copying an unverified command. The device authentication token identifies the client machine and must remain private.
Install and run the Localtonet client on the panel host
Run our client on the server where nginx-reverse-emby responds at 127.0.0.1:8080. The client must remain connected for the tunnel to stay available.
Authenticate or select the server device
Use the device-specific Localtonet token through the current supported client workflow, then select that connected device in our dashboard. Never publish or guess the token.
Select an available relay server
Choose from the relay servers or regions currently shown in the dashboard. Available values can vary, so do not hardcode a server code from another account or article.
Create an HTTP tunnel to the local panel
Set the local IP address to 127.0.0.1 and the local port to 8080. Select the appropriate process type available in your account, such as Random Sub Domain, Custom Sub Domain, or Custom Domain.
Start the tunnel
Creating a tunnel does not start it. Use the Start control and confirm that both the selected client and tunnel are connected.
Open and verify the public HTTPS address
Open the address assigned to the tunnel and log in with the nginx-reverse-emby API_TOKEN. Stop or delete the tunnel when remote administration is no longer required.
Consult the Localtonet HTTP tunnel documentation for the current dashboard workflow. Exact custom-domain DNS records are not included here because they must match the current Localtonet instructions and the configuration displayed for your account.
| Access method | Best fit | Operational behavior |
|---|---|---|
| Server-local browser or HTTP client | Basic endpoint testing | Uses 127.0.0.1:8080 directly and does not provide access from another machine. |
| SSH local forwarding | Temporary administrator access | Requires SSH access and remains available while the forwarding session is active. |
| Localtonet HTTP tunnel | Public HTTPS access without inbound router forwarding | Requires a connected Localtonet client and a running tunnel. The project token remains the panel login credential. |
| Project self-proxy rule | A panel domain managed by nginx-reverse-emby | Uses a rule targeting http://127.0.0.1:8080 and requires the project's DNS, firewall, certificate, and forwarded-header configuration. |
Localtonet removes the need for inbound router port forwarding, but the assigned URL remains a public route while the tunnel is running. Keep the panel token long, random, and private. Share the URL only with intended administrators, apply appropriate access restrictions available in your current configuration, and stop the tunnel when it is not needed. An unguessable-looking URL is not a substitute for authentication.
Routine operations, updates, backup, and recovery
Run Compose commands from the directory containing the active docker-compose.yaml. If you operate the deployment through another automation system, use that system consistently rather than mixing procedures without understanding which configuration is authoritative.
Review service status
docker compose psReview whether the expected Compose services are running and whether any service is repeatedly restarting or has exited. Do not rely only on container state. Follow the status check with the local endpoint request and a panel login because a running container can still contain an unavailable application.
curl -I http://127.0.0.1:8080Review recent and live logs
docker compose logs --tail=200To follow new output while reproducing a problem, use:
docker compose logs -f
Stop following with Ctrl+C. Before sharing output, redact panel tokens, registration tokens, Cloudflare credentials, private URLs, certificates, keys, and other identifying values. Logs are diagnostic material, not automatically safe public data.
Stop or restart the deployment
Stop the running services without deleting the deployment's persistent directory:
docker compose stopStart or reconcile the configured services again with the project's documented startup command:
docker compose up -dIf the configuration has not changed and you only need to restart the current Compose services, use:
docker compose restart
After a restart, verify the Compose state, request 127.0.0.1:8080, log in, and test at least one representative rule. Also verify any Localtonet client separately because restarting the project does not prove that the Localtonet client or tunnel is connected.
Apply environment changes carefully
After editing the Compose environment, validate the rendered configuration before applying it:
docker compose configThe rendered output can contain resolved secret values. Review it only in a protected terminal and do not paste it into a public issue. If validation succeeds, apply the configuration:
docker compose up -d
Token changes require extra planning. Rotating API_TOKEN changes the login credential. If the Secret Vault key is implicitly derived from that token, the key relationship is also involved. Establishing an explicit PANEL_VAULT_MASTER_KEY before routine login-token rotation avoids coupling the vault master key to the panel token.
Prepare a consistent backup
The project's persistent data directory, Compose definition, environment file, and externally referenced certificate or key files are part of the recoverable deployment. Because the environment and data may contain sensitive material, store the backup in an access-controlled location with suitable encryption and retention rules.
The project maintains dedicated backup and restore guidance on its documentation site. Check that guidance before production backup or migration, especially when a newer version introduces schema or Secret Vault changes. The following file-level procedure is a conservative Compose snapshot for the repository layout shown in the current quick start.
Record the current state
Record the current project version or image reference, retain the active Compose file, and note whether secrets are stored directly in the Compose file, in .env, or in another secret system.
docker compose config --images
docker compose psStop writes for a consistent file snapshot
Schedule an interruption and stop the Compose services before copying the persistent directory.
docker compose stopCopy configuration and persistent data
Create a protected backup directory outside the live deployment, copy the Compose file and data directory, and include .env when it exists.
backup_dir="../nre-backup-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"
cp -p docker-compose.yaml "$backup_dir"/
[ ! -f .env ] || cp -p .env "$backup_dir"/
cp -a data "$backup_dir"/
chmod -R go-rwx "$backup_dir"Restart and verify the live deployment
Bring the services back, check their state, request the local panel, and confirm that a representative rule still works.
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:8080A copied directory is not a proven backup until it has been restored successfully in a controlled environment. Protect the snapshot because it may contain login credentials, agent registration material, certificates, private keys, rule configuration, and other operational data.
Restore a file-level snapshot
Perform a restore during a planned interruption. Use a snapshot created for the deployment version you intend to run, and keep the current failed or damaged state available until verification is complete. The project documentation remains authoritative if its current backup page requires an application-specific step beyond this Compose-level process.
Stop the active services
Prevent further writes before replacing persistent state.
docker compose stopPreserve the current state for rollback
Move the current data directory aside instead of deleting it immediately.
mv data "data.before-restore-$(date +%Y%m%d-%H%M%S)"Restore matching data and configuration
Copy the selected snapshot's data directory into the deployment. Restore its matching Compose and environment configuration when those files are part of the recovery, taking care not to overwrite newer secrets unintentionally.
cp -a <backup-directory>/data ./data
cp -p <backup-directory>/docker-compose.yaml ./docker-compose.yaml
[ ! -f <backup-directory>/.env ] || cp -p <backup-directory>/.env ./.env
[ ! -f .env ] || chmod 0600 .envStart the restored deployment
Validate the Compose configuration, then start the services.
docker compose config
docker compose up -dValidate the restore
Check service state and logs, request the loopback endpoint, log in with the restored credential, verify expected nodes and rules, test a representative backend, and confirm certificate and Secret Vault behavior relevant to your deployment.
docker compose ps
docker compose logs --tail=200
curl -I http://127.0.0.1:8080Do not remove the pre-restore data until functional validation and your retention policy permit it. A successful HTTP response alone does not prove that rules, agents, certificates, vault material, and asynchronous configuration revisions are correct.
Update without losing the rollback path
The repository points operators to its documentation for upgrades and hot-update behavior. Read the current upgrade page before changing a production deployment. Exact migrations and compatibility requirements can vary by release, so a generic image pull must not replace project-specific release instructions.
A cautious Compose update sequence is:
- Read the current repository changes and project upgrade documentation.
- Record the current image reference with
docker compose config --images. - Create and test a backup of the Compose configuration, environment, persistent data, and required secrets.
- Download any revised Compose file to a temporary filename and compare it with the active file before replacing anything.
- Apply the exact migration or environment changes required by the project documentation.
- Pull the approved image and reconcile the deployment.
- Run the full post-update verification sequence.
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200
curl -I http://127.0.0.1:8080These Compose commands update and restart the configured services, but they do not prove application compatibility. Complete the browser login, node connectivity, rule, backend, certificate, and remote-access checks before closing the maintenance window.
Recover from a failed update
If the new deployment does not pass verification, stop making additional changes. Capture redacted logs, preserve the failed state for diagnosis, and use the pre-update image reference, configuration, secrets, and data snapshot to return to the last verified combination. Restoring data while continuing to run an incompatible new image can make the incident harder to recover from.
The rollback order is:
- Stop the failing Compose services.
- Restore the previous Compose and environment configuration.
- Restore the matching pre-update persistent data if the update modified it.
- Ensure the previous recorded image reference is available rather than unintentionally pulling a newer image again.
- Start the restored deployment with
docker compose up -d. - Repeat status, log, local endpoint, login, node, rule, certificate, and backend verification.
If the project release requires an irreversible migration or a special rollback utility, follow that release's documentation instead of improvising. Keep the failed-update snapshot until the incident has been resolved and any useful diagnostic evidence has been retained securely.
Troubleshoot in dependency order
If the local panel does not respond, check docker compose ps, inspect recent logs, validate the Compose configuration, and confirm that another process has not taken the local binding. Do not troubleshoot DNS or Localtonet until 127.0.0.1:8080 responds.
If the SSH path opens but login fails, confirm that you entered API_TOKEN, not MASTER_REGISTER_TOKEN, a Cloudflare token, a vault key, or a Localtonet device token. Check for accidental whitespace and verify that the running Compose environment received the intended value.
If a proxy rule fails, check DNS, ports 80 and 443, backend reachability from the selected agent, node selection, and whether the rule is enabled. Allow for asynchronous revision application, then distinguish an application proxy failure from a certificate challenge failure by reviewing the panel state and redacted logs.
If the Localtonet URL does not load, test the panel from the same machine running the Localtonet client. Confirm the target is 127.0.0.1:8080, the intended device is connected, an available relay server is selected, and the tunnel was started. Creating a tunnel configuration is not the same as running it.
Security and exposure checklist
This panel can change forwarding rules, enroll infrastructure, and handle certificate-related material. Treat its URL, tokens, data directory, backups, and logs as administrative assets rather than ordinary website content.
Keep every credential separate
API_TOKEN authorizes panel login. MASTER_REGISTER_TOKEN enrolls remote agents. Each must contain at least 32 random characters, and the values must not match. Do not reuse either as a Localtonet device token, Cloudflare API token, Secret Vault key, or unrelated service password.
Prefer HTTPS for ongoing browser access
The project's temporary HTTP path and random location can reduce casual discovery, but they do not replace HTTPS and a strong token. A Localtonet HTTP tunnel presents the local service at a public HTTPS address. If you instead publish the panel through nginx-reverse-emby itself, follow the project's self-proxy and certificate workflow.
The documented manual self-proxy method uses a public panel hostname and the backend http://127.0.0.1:8080. After certificate issuance, the Compose environment can identify the public URL and enable trusted forwarded headers:
environment:
NRE_PUBLIC_URL: https://panel.example.com
NRE_TRUST_FORWARDED_HEADERS: "true"
Enable NRE_TRUST_FORWARDED_HEADERS only when the trusted upstream proxy cleans and rewrites X-Forwarded-* headers. The project's documented example relies on its local agent doing so. Do not copy this setting into an unrelated proxy topology without validating that trust boundary.
Use least privilege for DNS automation
A Cloudflare API token used for DNS-01 should have only Zone Read, DNS Read, and DNS Edit permissions for the necessary zone. Do not use a Global API Key. If DNS-01 is unnecessary, do not configure a Cloudflare credential merely because the installer offers the option.
Protect backups and diagnostic output
Backup media can be as sensitive as the live server because it can contain tokens, private keys, certificates, rule definitions, and runtime state. Restrict access, use appropriate encryption, maintain a retention policy, and test restores without exposing production credentials. Redact logs and screenshots before sharing them.
Limit the Localtonet tunnel lifecycle
A Localtonet tunnel is available only while its selected client is connected and the tunnel is running. Use that lifecycle deliberately. Start remote access when required, verify the assigned endpoint, and stop or delete the tunnel when the administrative session or ongoing need has ended.
Frequently asked questions
Does nginx-reverse-emby require Nginx?
No. The current default runtime described by the project uses a Go control plane and Go agents and does not depend on Nginx. The repository retains its historical name.
Is the project limited to Emby?
No. Emby and Jellyfin are example use cases. The rule model supports general HTTP services and TCP or UDP ports when the selected agent can reach the configured backend.
Does Localtonet host nginx-reverse-emby?
No. nginx-reverse-emby runs on your Docker host. In this workflow, Localtonet only provides an optional remote HTTP path to the control panel after the application is already running locally.
What is the default local panel address?
The documented manual deployment exposes the panel at http://127.0.0.1:8080. Access it on the server, through SSH local forwarding, or through a separately configured access path such as a Localtonet HTTP tunnel.
Which token is used to log in?
Use API_TOKEN. A new deployment has no separate username and password. MASTER_REGISTER_TOKEN is for remote-agent enrollment and must be a different random value.
Must I forward port 8080 on my router?
No. The documented panel is bound to loopback. A Localtonet client on the same server can reach that endpoint through an outbound connection, so you should not create an inbound router rule for port 8080 merely to use this workflow.
Does Localtonet replace the project's agents or relay?
No. nginx-reverse-emby continues to manage its own local and remote agents, proxy rules, and relay functions. Localtonet is only the optional administration-panel access path described here.
Is the Localtonet URL private?
It is a public route while the tunnel is running, so the panel's authentication remains essential. Keep the URL and token within the intended administrative group, apply suitable access restrictions, and stop or delete the tunnel when remote access is not required.
Can I run the Localtonet client on another computer?
The client must run on a device that can reach the target. For 127.0.0.1:8080, run it on the nginx-reverse-emby host because loopback refers to the client device itself. A client on another machine would require a different reachable target address.
How should I verify a backup or update?
Check Compose status and logs, request the loopback endpoint, log in, confirm nodes and rules, test a representative backend, and verify certificate and vault behavior relevant to your deployment. A container marked as running is not sufficient proof by itself.
Connect your verified control panel with Localtonet
After nginx-reverse-emby responds locally at 127.0.0.1:8080, create a Localtonet HTTP tunnel for optional browser-based administration without opening an inbound router port. Keep every credential private and run the tunnel only for as long as remote access is needed.
