Reach your self-hosted video archive through a controlled public HTTPS address
Tube Archivist provides a browser-based interface for organizing, searching, managing, and playing an archived YouTube collection. That interface normally runs inside a home or private network, which makes remote access difficult without additional networking work. With Localtonet, you can publish the web interface through an HTTP tunnel created by an outbound client connection, without configuring inbound router port forwarding, changing firewall rules, setting up a VPN, or requiring a public IP address. This guide explains the recommended architecture, the configuration workflow, and the security decisions to review before giving authorized users remote access.
What remote Tube Archivist access involves
Tube Archivist is a self-hosted media server designed around an archived YouTube collection. It can subscribe to channels, download videos, index video metadata, make the archive searchable, play stored media, and track viewed or unviewed items. Its main user experience is a web interface, so a browser on the local network can connect to the application using the host name or IP address and port assigned to the deployment.
Local network access is usually straightforward because the browser and the Tube Archivist host can communicate directly. Remote access is different. A private address such as a LAN IP is not normally routable from the public internet, and many residential connections are behind a router, carrier-grade NAT, or another network boundary. Traditional publishing methods may require an inbound port-forwarding rule, a public IP address, firewall changes, and careful reverse-proxy configuration.
With Localtonet, the client application on a device that can reach Tube Archivist establishes an outbound connection to one of our relay servers. An HTTP tunnel then connects an assigned public HTTPS address to the local Tube Archivist web endpoint. The tunnel is available only while the selected Localtonet client is connected and the tunnel is running.
Tube Archivist depends on supporting services such as Elasticsearch and Redis, but remote users do not need direct public access to those internal components. Point the Localtonet HTTP tunnel at the Tube Archivist browser interface only. Keep database, search, cache, container-management, and administrative infrastructure private unless a separate and carefully reviewed requirement exists.
How the connection is structured
The important design decision is where to run our client. Install and run the Localtonet client on the Tube Archivist host or on another trusted device that can reach the Tube Archivist web interface over the private network. The local target can therefore be a loopback address when both applications share a host, or a private LAN address when the client runs elsewhere.
A remote browser connects to the public HTTPS address assigned to the HTTP tunnel. Our relay receives that web traffic and carries it through the established tunnel to the connected client. The client forwards the request to the configured local IP address and port. Responses return through the same path. The router does not need to accept a new unsolicited inbound connection because the Localtonet client establishes the relay connection outbound.
Prepare Tube Archivist before publishing it
Confirm that Tube Archivist works locally before introducing the tunnel. From the device that will run our client, open the exact local address you plan to use as the target. Sign in, navigate through the archive, open a video page, and test playback. A successful local test separates application or container problems from tunnel configuration problems.
Tube Archivist deployments commonly use Docker and require several environment variables. One particularly relevant setting is TA_HOST. Tube Archivist documentation and release guidance indicate that this value should include the protocol and port exactly as documented for the deployment. An incorrect value can contribute to host validation or unexpected logout redirect behavior. Do not guess the appropriate public-facing value or alter authentication-related settings solely to make remote access work. Review the documentation for the Tube Archivist version you are actually running and test changes locally before exposing the service.
Also verify that the configured target is the user-facing Tube Archivist port rather than an Elasticsearch, Redis, Docker daemon, or other infrastructure port. If the Localtonet client runs in a different container or on a different machine, remember that 127.0.0.1 refers to that client environment itself. Use an address that is genuinely reachable from the client while avoiding unnecessary exposure on the rest of the LAN.
A public tunnel address can be reached from outside your private network. Keep Tube Archivist authentication enabled, use strong credentials, review account access, and disclose the address only to authorized users. Do not publish Elasticsearch, Redis, container APIs, or administrative ports. Apply least privilege and any available application access controls.
How to configure the Localtonet HTTP tunnel
The workflow below follows the established Localtonet tunnel lifecycle. Dashboard details, available relay servers, and options can vary over time, so select values shown in your current dashboard rather than copying a server code or region from an old guide. For current interface details, consult our HTTP tunnel documentation.
Install and run the Localtonet client
Install our client on the Tube Archivist host or another trusted device that can reach its web interface. Keep the client running throughout the remote session because the tunnel depends on its outbound connection.
Authenticate and select the client device
Use the device-specific authentication token associated with the client that will run the tunnel. Treat the token as a secret. Never place it in screenshots, shared instructions, source repositories, or public configuration examples.
Select an available relay server
Choose from the relay servers or regions currently available in your Localtonet dashboard. Do not hardcode a server code from another deployment because availability can differ by account, plan, region, or product version.
Create the HTTP tunnel configuration
Select the HTTP tunnel family and enter the local IP address and port for the Tube Archivist web interface. Choose the available Process Type appropriate to your deployment: Random Sub Domain, Custom Sub Domain, or Custom Domain. These process types serve the configured content through a public HTTPS address. Check current documentation before configuring custom-domain DNS.
Start the tunnel and test the assigned address
Creating the configuration does not make it active. Press Start, then open the assigned public URL in a separate browser session. Confirm that the Tube Archivist login page appears, authentication succeeds, navigation works, and a representative video can be played.
Stop or delete access when it is no longer needed
Stop the tunnel when temporary remote access is complete. Delete the configuration if it should not be reused. The public endpoint also becomes unavailable when the selected client disconnects, but intentional lifecycle management is preferable to relying on an accidental disconnection.
Choose the correct public-address option
HTTP tunnels and File Server tunnels can use different Process Types for their public HTTPS addresses. For Tube Archivist, the selected option changes how users reach the interface, not which application content is forwarded. Availability may depend on the current dashboard and subscription, so do not assume every option is included in every plan.
| Process Type | Useful when | Important consideration |
|---|---|---|
| Random Sub Domain | You want to test the integration or create an address without selecting a specific name. | Use the generated HTTPS address assigned to the tunnel and share it only with authorized users. |
| Custom Sub Domain | You want a selected subdomain where that option is supported. | Confirm availability in the current dashboard rather than assuming it is available for every account. |
| Custom Domain | You want users to access Tube Archivist through a domain you control. | Review current Localtonet documentation for exact DNS requirements before making changes. |
Security and operational checks
Remote publishing changes the trust boundary around a self-hosted application. On a private LAN, the router may previously have prevented outside clients from reaching Tube Archivist at all. Once the tunnel starts, the public address becomes an internet-reachable entry point. The first protection should therefore be Tube Archivist authentication, supported by strong passwords, limited account distribution, and prompt credential changes if access details are disclosed.
Keep Tube Archivist and its deployment dependencies maintained according to the project’s release guidance. Review release notes before updating, especially when changes involve environment variables, authentication, host validation, or supported dependency versions. Confirm the running application version after an update and repeat the local and remote tests. Avoid enabling debug behavior in an internet-accessible production deployment because detailed errors may reveal information that ordinary users do not need.
Test from a genuinely external network rather than only from the same LAN. A mobile connection can help verify that the assigned HTTPS address works independently of local DNS or private routing. Confirm login and logout behavior, image loading, search, playback, and any browser-specific media format requirements relevant to your users. Remote playback quality will depend on the archive’s media format, the host’s available upload capacity, and the viewer’s connection. We do not claim a universal throughput or latency result.
Finally, monitor the practical lifecycle. If Tube Archivist is restarted, its container address or port changes, or the Localtonet client stops, the endpoint may cease working. A configured tunnel is not evidence that the local target is healthy. Troubleshooting should proceed from the inside outward: verify Tube Archivist locally, verify reachability from the client device, confirm the selected device is connected, confirm the tunnel is running, and then test the public URL.
Localtonet supplies the connectivity path to the configured local service. Tube Archivist remains responsible for its login behavior and application permissions. A successful tunnel does not prove that authentication, host settings, media formats, or user access policies are configured correctly.
Frequently asked questions
Do I need to forward a port on my router?
No. The Localtonet client establishes an outbound connection to our relay, so this workflow does not require inbound router port forwarding, a public IP address, firewall changes, or VPN setup.
Which Tube Archivist service should the tunnel target?
Target the local IP address and port of the Tube Archivist browser interface. Do not point the public tunnel at Elasticsearch, Redis, the Docker daemon, or another supporting infrastructure service.
Does creating the tunnel immediately make it available?
No. Creating a tunnel stores its configuration, but you must press Start before the assigned public endpoint becomes active. The selected client must also be connected and able to reach Tube Archivist.
Should I disable Tube Archivist authentication behind the tunnel?
No. Keep application authentication enabled and use strong, unique credentials. The tunnel provides public network reachability, so application authorization remains an essential security layer.
Can the Localtonet client run on a different device?
Yes. It can run on another trusted device as long as that device can reach the Tube Archivist web address and port. Use a private address reachable from the client rather than assuming that a loopback address points to the Tube Archivist host.
Is this the same as using Localtonet VPN Manager?
No. This guide uses a standard HTTP tunnel to publish one web application. VPN Manager is our separate private mesh VPN feature and should not be confused with HTTP, TCP, UDP, TLS, or File Server tunneling.
Why does the public address stop working when the client disconnects?
The client maintains the outbound connection that carries requests to the local service. If the client disconnects, the tunnel stops running, or Tube Archivist becomes unreachable from that device, the public endpoint cannot forward traffic to the application.
Open your Tube Archivist interface to authorized remote users
Run our client on a device that can reach Tube Archivist, create an HTTP tunnel for the web interface, keep application authentication enabled, and start the tunnel when remote access is needed.
Get Started Free →
