Build a portable browser-based media server, verify it locally, and add optional remote access safely
Jcorp Nomad is an open-source offline media server that runs on an ESP32-S3, stores its content on an SD card, and serves movies, music, books, photos, games, maps, and other resources through a browser. This guide separates the project details confirmed by the current repository from installation values that are not present in the available official material. It explains firmware 4.6 storage requirements, SD card preparation, local validation, WiFi Mode, administration, and the correct Localtonet architecture. It also makes Nomad's access model explicit: guests are described as needing no account, while the admin login protects administrative settings rather than necessarily restricting access to ordinary media pages.
📋 What's in this guide
What this setup guide can verify
The current official Jcorp Nomad repository identifies the project as a portable offline media server powered by an ESP32-S3. Its main branch contains the firmware source, an SD_Card_Template directory, supporting documentation, tools, and optional case files. The project recommends the DIY route and directs builders to its Hardware Requirements and Quick Start sections.
Use the repository's Hardware Requirements and Quick Start for the revision-specific physical build and flashing procedure. Those are the official locations for the project's supported board variant, attached hardware, wiring, power arrangement, board-menu options, upload settings, first-use network values, and initial administration workflow.
The current official material supplied for this revision confirms the ESP32-S3 platform, SD card template, firmware 4.6 features, SdFat dependency, WiFi Mode behavior, and administration model. It does not expose the detailed text of the Hardware Requirements or Quick Start sections. Consequently, this article cannot responsibly reproduce an exact bill of materials, pin-by-pin wiring table, voltage and current requirement, Arduino core version, SdFat version, board-menu values, upload command, boot-button sequence, hotspot credentials, local URL, HTTP port, or default admin credentials. No substitute values are guessed below.
This limitation matters because the ESP32-S3 name alone does not identify one interchangeable board configuration. ESP32-S3 products can differ in flash capacity, PSRAM, USB implementation, pin routing, power design, display hardware, and SD card connections. A setting that works for one ESP32-S3 board can fail on another or conflict with attached peripherals.
The supported installation sequence is therefore the one in the repository's current Quick Start, not a reconstructed sequence assembled from general ESP32 knowledge. Before buying parts or connecting hardware, compare the repository instructions with the exact revision or release you plan to install. If the Hardware Requirements or Quick Start no longer supplies one of the values listed above, that item remains unresolved and should be raised with the project rather than inferred.
Understand the Jcorp Nomad architecture
Nomad runs its firmware and web server on an ESP32-S3 while media, browser assets, indexes, configuration data, and feature files are stored on an SD card. Users interact with the device through an ordinary browser. Its primary operating model is local and offline, so ordinary use does not require a cloud service, internet connection, dedicated application, or guest account.
In hotspot mode, Nomad creates a local Wi-Fi network. Phones, tablets, and laptops connect to that network and open the browser interface. The project describes multiple users accessing separate streams at the same time, which makes the system suitable for road trips, classrooms, camping, remote work, and other situations where internet access is unavailable or undesirable.
Firmware 4.6 adds WiFi Mode. Instead of operating only as its own hotspot, Nomad can join an existing Wi-Fi network and serve its browser interface and supported LAN services to that network. The admin panel's WiFi Mode control opens a popup with a network scanner, password field, and auto-reconnect option. After joining, Nomad's screen displays the IP address assigned by the router.
The captive portal disables itself in WiFi Mode. This is necessary because captive-portal DNS redirection would be inappropriate on an existing home or office network. Users must open the router-assigned address directly rather than relying on the hotspot's captive-portal behavior.
WiFi Mode creates the network arrangement needed for optional remote browser access. The available evidence does not establish that the Localtonet client runs directly on an ESP32-S3. Run our client on a separate supported computer or device that can reach Nomad's LAN address and establish an outbound connection to a Localtonet relay server.
Nomad's hotspot can operate without the internet. A public tunnel cannot. The device running our client needs internet access as well as a working route to Nomad. Putting Nomad and the Localtonet helper on the same internet-connected LAN through WiFi Mode is the clearest architecture.
Hardware, software, and files
Start by selecting one repository revision and keeping every part of the setup aligned with it. Firmware 4.6 changes both the embedded firmware and the SD card template. The project explicitly says that an upgrade to this version requires reflashing the device and refreshing the card files.
Confirmed requirements
- An ESP32-S3-based build that matches the current project's Hardware Requirements.
- The display, SD storage hardware, connections, and power arrangement specified for that supported build.
- A compatible SD card.
- A data-capable USB connection and a computer for the official flashing workflow.
- The firmware and
SD_Card_Templatecontent from the same repository revision. - The project-specified Arduino or other flashing environment.
- The SdFat library from Arduino Library Manager when compiling firmware 4.6 from source.
- A browser-capable phone, tablet, or computer for local testing.
- An existing Wi-Fi network if you plan to use WiFi Mode.
- A separate supported device on the same LAN if you plan to run the Localtonet client.
Values that must come from the current Quick Start
| Setup item | Status in available evidence | Safe action |
|---|---|---|
| Exact ESP32-S3 board variant | Not reproduced | Use the board named in the current Hardware Requirements |
| Display and SD wiring | Not reproduced | Follow the official pin table or assembly diagram exactly |
| Power input and capacity | Not reproduced | Use only the officially documented power arrangement |
| Arduino IDE and ESP32 core versions | Not reproduced | Install the versions listed by the current Quick Start |
| SdFat version | Library required, version not reproduced | Use the project-pinned version if the current documentation specifies one |
| Board-menu and partition settings | Not reproduced | Copy every official board-menu value without substitution |
| Upload and boot-button procedure | Not reproduced | Follow the current Quick Start sequence |
| Hotspot name and credentials | Not reproduced | Use the values documented by the project or shown by the device |
| Local URL and HTTP port | Not reproduced | Use the exact endpoint documented or observed during successful local access |
| Initial admin credentials | Not reproduced | Follow the current first-use instructions and change the password promptly |
Firmware 4.6 uses SdFat because the filesystem component bundled with the Arduino ESP32 core has exFAT support compiled out. SdFat provides the filesystem implementation needed by the current firmware. Install it through Arduino Library Manager before compiling from source. Do not replace it with another library merely because that library exposes similarly named filesystem APIs.
The project's Mk3 release information states that its bundled Arduino libraries were not present and that library versions had not yet been pinned. That historical source archive does not build on its own and should not be treated as the toolchain specification for firmware 4.6.
Install the firmware and prepare the SD card
Nomad installation has two coordinated outputs: firmware written to the ESP32-S3 and a prepared SD card containing the matching project files. Treat them as one release set. Mixing current firmware with an older card template can leave the browser interface or newer features without the assets and files they expect.
Follow the official Quick Start in its published order. Before starting, save a separate copy of all personal media and any configuration that you need to retain. A clean project template is not a backup of your existing content.
Compile and flash only with documented settings
If you compile firmware 4.6 from source, install the documented build environment and SdFat dependency first. Select the exact target board, flash size, PSRAM option, USB mode, partition layout, upload speed, and related values listed in the current Quick Start. Put the board into upload mode using the documented button or reset sequence, then use the project's supported upload action.
This article intentionally does not supply plausible-looking Arduino menu selections or an improvised command line. An incorrect flash or partition setting can produce compilation errors, failed uploads, boot loops, storage failures, or missing runtime memory. If the official Quick Start does not list a required setting for your board, stop and confirm it with the project rather than borrowing settings from an unrelated ESP32-S3 tutorial.
Prepare a matching SD card
Obtain the SD_Card_Template from the same current repository revision as the firmware. Preserve its directory names and hierarchy when copying it to the card. Do not rename system files or flatten the directory structure.
Firmware 4.6 detects exFAT, FAT32, and FAT16 automatically at boot. There is no filesystem selection that must be configured inside Nomad. Existing FAT32 cards remain supported, but FAT32 retains its single-file size restriction. ExFAT permits files larger than 4 GB and allows SDXC cards over 32 GB to be used without the FAT32 reformatting previously needed for those cards.
The project also states that some advanced features require exFAT. Use exFAT when you need large individual video files, a full-size ZIM archive stored as one file, or a feature whose current project instructions specify exFAT. Retaining FAT32 can be reasonable for a compatible existing library, but it does not remove FAT32's filesystem limits.
Add content only to documented locations
Preserve the template first, then add legally obtained media to the category locations identified by the current project files. The available repository evidence explicitly confirms /Maps for offline map regions and /Games for game ROMs. It does not provide a complete verified directory map for every media category in the extracted material, so this article does not invent paths for movies, television, music, books, comics, gallery items, files, or ZIM archives.
Nomad Tools prepares offline map regions on a computer, including the map image and road network used for search and Drive or Walk directions. Map data is read from a packed archive rather than being unpacked onto the card. The project identifies maps as one of the newer areas of firmware 4.6 and notes that large regions can be slow to draw.
Game ROMs placed in /Games can be presented through the browser using EmulatorJS. The project's current product description lists systems including GB, GBC, GBA, NES, SNES, and Genesis, while also noting other supported formats. Verify the current project's legal and format guidance before adding ROMs.
Firmware 4.6 requires both a reflash and refreshed card files. Copy personal media, configuration, and other irreplaceable content to separate storage before changing either side. Restore selectively after the new matching firmware and template work together locally.
Complete first use and enable WiFi Mode
After flashing through the official procedure, safely eject the prepared SD card, insert it only as directed by the hardware instructions, and start Nomad. Follow the Quick Start's first-use network sequence and open its documented local address from a connected browser.
The current evidence does not establish the default hotspot name, hotspot password, local hostname, numeric local address, HTTP port, or initial administrator credentials. These values must come from the current Quick Start or the device's own display. Do not substitute common ESP32 addresses such as 192.168.4.1, and do not assume that the service listens on port 80 or 443.
Set up administration
Nomad's admin settings are protected by an admin login. The current project description identifies administrative controls for restart, safe shutdown, USB mode, Wi-Fi settings, RGB, brightness, credentials, library indexing, and a live system console. Set a strong, unique admin password during the documented initial administration flow and keep it separate from any link shared with guests.
The browser file manager supports upload, rename, delete, download, and editing operations. The project notes that a computer remains easier for bulk file management. After loading content, run the project's required index scan. Do not repeatedly interrupt power while an administrative storage operation is active.
Join an existing Wi-Fi network
Open the WiFi Mode control in the top bar of the admin panel. Use the network scanner, select the intended network, enter its password, and choose the documented auto-reconnect behavior. Once the connection succeeds, read the router-assigned IP address from Nomad's screen.
Open that displayed address from another device on the same LAN. The captive portal is disabled in WiFi Mode, so direct address access is expected. If the address later changes, update bookmarks and any tunnel target that points to the old address.
A DHCP reservation configured on your router can help keep Nomad's LAN address stable. The exact procedure depends on the router and is not a Nomad or Localtonet setting.
| Operating mode | How clients connect | Suitable for a Localtonet HTTP tunnel |
|---|---|---|
| Nomad hotspot | Clients join the Wi-Fi network created by Nomad | Usually not, unless a separate client has both a route to Nomad and working internet access |
| WiFi Mode | Nomad joins an existing LAN and receives an IP from the router | Yes, when a separate Localtonet client can reach the verified browser endpoint |
| WiFi Mode with DLNA | Browser and compatible media-discovery clients use the LAN | Only the browser HTTP endpoint is relevant to this tunnel workflow |
Verify Nomad locally before tunneling
Local verification separates hardware, firmware, card, and Wi-Fi problems from tunnel problems. Localtonet forwards a reachable service. It cannot repair an incomplete card template, a failed network join, an unavailable web server, or an incorrect port.
Check the hotspot workflow first
- Confirm that Nomad powers on and reaches the normal screen described by the Quick Start.
- Join the documented hotspot using the project's current network details.
- Open the exact local URL supplied by the Quick Start or shown by the device.
- Confirm that the guest interface loads without requiring an ordinary viewer account.
- Open the admin login separately and confirm that your administrative credentials work.
- Check that expected storage information and library pages appear.
- Open at least one small, known-good media file and verify playback or download behavior.
Check the WiFi Mode endpoint
After enabling WiFi Mode, use the IP address shown on Nomad's screen. Open it from a second device on the same LAN. If the browser displays an explicit port, retain it. If no port is displayed, use the project's documented port or inspect the working local request using appropriate local network tools.
Repeat the test from the exact computer or device that will run the Localtonet client. This is the most important pre-tunnel check. If the helper device cannot open Nomad directly, it cannot forward requests to Nomad.
The currently available Nomad evidence does not state a universal HTTP port. Record the complete endpoint that works locally, including the scheme, LAN address, and port. Do not assume port 80, port 443, or HTTPS support.
Test representative content
A successful landing page proves only that a basic request works. Open the pages and media types you intend to use. Start with a small file, then test playback, seeking, navigation, and any required index results. Large files can expose limitations in the SD card, ESP32-S3, wireless link, helper device, upstream connection, or remote viewer's connection.
Keep DLNA separate from browser access. DLNA discovery is designed for a local network. An HTTP tunnel to Nomad's browser interface does not establish that DLNA discovery or television-device announcements will work across the public internet.
Expose the verified browser endpoint with Localtonet
With Localtonet, our client application makes an outbound connection to a Localtonet relay server. An HTTP tunnel provides a public HTTPS address and forwards browser requests to the configured local IP address and port. This workflow does not require inbound router port forwarding, a public IP address, VPN setup, or inbound firewall changes.
Run our client on a separate supported device connected to the same LAN as Nomad. That helper must be able to open Nomad's verified WiFi Mode endpoint and reach the internet. Do not assume that our client can be installed on the ESP32-S3 itself.
Install and run the Localtonet client
Install our current client on the LAN helper device. Keep that device awake, connected to the Nomad LAN, and connected to the internet while remote access is needed.
Select the authenticated helper device
Use the device-specific Localtonet authentication token assigned to the helper. Keep the token private and never publish it in screenshots, source files, or support messages.
Select an available relay server
Choose a currently available server or region in the dashboard. Obtain the available value from the live product rather than copying an old server code.
Create an HTTP tunnel
Set the local target to Nomad's verified LAN IP address and verified HTTP port. HTTP process types can provide a generated subdomain, a selected subdomain where supported, or a custom domain. Check current DNS instructions before using a custom domain.
Start and test the tunnel
Creating a tunnel does not start it. Press Start, wait for the selected client and tunnel to be connected, then open the assigned public HTTPS address from a device outside the Nomad LAN.
Stop or delete remote access
Stop the tunnel when public access is not required, or delete it when the configuration is no longer needed. The endpoint is available only while the selected client is connected and the tunnel is running.
Review the current Localtonet HTTP tunnel documentation while configuring the dashboard. Use the local endpoint that you already proved from the helper device rather than substituting an example IP address or port.
Remote availability depends on Nomad, its SD card, Wi-Fi, the LAN helper, the Localtonet client, and the running tunnel. If the helper sleeps, shuts down, changes networks, or loses internet access, the public endpoint becomes unavailable even if Nomad still works locally.
Understand the guest-access risk before publishing Nomad
Nomad is designed for convenient local sharing. The project describes its guest experience as requiring no account, while the admin login protects administrative settings. These are different controls. An admin password does not by itself establish that ordinary media pages require authentication.
If Nomad's ordinary browser interface is account-free on the local network, forwarding that interface through an HTTP tunnel may make the intended guest pages and media reachable without a Nomad viewer login. The admin password protects administrative settings, but it should not be treated as proof that all media requests are protected. Do not expose Nomad unless this access model is acceptable for every file available through the interface or a separately verified access-control layer is in place.
Localtonet's HTTP tunnel transports requests to the configured local service. This article does not claim that creating the tunnel automatically adds viewer authentication, Nomad user accounts, or media-level authorization. Do not share the public URL as though it were a private credential unless you have independently verified an appropriate access-control mechanism.
Review the entire SD card before starting the tunnel. Remove private documents, personal photographs, credentials, backups, licensed material that you are not permitted to distribute, and anything else that should not be internet-accessible. Check the guest interface itself rather than assuming that only indexed media can be reached.
Protect the admin account with a strong, unique password. Confirm that ordinary guest navigation cannot open administrative controls or file-management actions. Since the browser file manager supports upload, rename, deletion, download, and editing, test the effective separation between guest pages and the protected admin area using a fresh browser session.
Troubleshoot in the correct order
The firmware does not compile
Confirm that you are using the current repository revision and its documented toolchain. For firmware 4.6, verify that SdFat is installed through Arduino Library Manager. Compare the selected board and every board-menu option with the current Quick Start.
Do not use the historical Mk3 source archive as a self-contained current build environment. Its release notes say that the bundled Arduino libraries were absent and library versions were not pinned at that point. Resolve missing board definitions, library conflicts, and partition errors before editing Nomad application files.
The firmware compiles but does not upload
Recheck the exact USB connection, port selection, upload mode, and button sequence documented for the supported hardware. Try a known data-capable USB cable and avoid assuming that a cable used only for charging can carry serial or USB data. Do not change flash or USB settings randomly to force an upload.
The device starts but the interface is incomplete
Confirm that the firmware and SD_Card_Template came from the same revision. Recheck that the template hierarchy was copied without renaming or flattening directories. Missing pages, styles, or assets can result from an incomplete or mismatched card, but diagnose against the repository files rather than relying on one symptom as definitive proof.
Shut the device down safely before reseating the SD card. Verify that the card uses a filesystem recognized by firmware 4.6 and remains readable on the preparation computer. Restore from a backup rather than repeatedly modifying the only copy of important media.
The hotspot page does not open
Confirm that the client device joined Nomad's network rather than automatically returning to another saved Wi-Fi network. Use the exact local address in the current Quick Start or on the device display. If the project uses a captive portal, allow time for the operating system's network prompt, but also test the documented direct address.
Nomad works as a hotspot but not in WiFi Mode
Open the WiFi Mode popup, rescan, and verify the network password. Check Nomad's screen for a router-assigned IP address. If no address appears, resolve the network join before configuring Localtonet.
If an address appears but another LAN device cannot reach it, check whether both devices are on networks allowed to communicate. Guest Wi-Fi and wireless client isolation can block device-to-device traffic. Those controls belong to the router or access point, not the HTTP tunnel.
The local page works but the tunnel does not
Repeat the local browser test from the exact helper running our client. Confirm that the configured target contains Nomad's current LAN address and verified port. Then confirm that the selected Localtonet client is connected and the tunnel has been started.
Check whether the helper is sleeping or has lost internet access. Also check whether the router assigned Nomad a new address after a restart or Wi-Fi reconnection.
The public page opens but media does not play
Test the same small file locally and publicly. If local playback fails, troubleshoot Nomad, the card, indexing, or the file first. If local playback succeeds but remote playback fails, inspect the complete path, including the ESP32-S3 wireless link, helper connectivity, upstream internet capacity, and remote viewer connection.
This guide does not claim a specific streaming bitrate, concurrency level, latency, or performance result. Test the actual formats and file sizes required for your use case, beginning with a small known-good item.
The public endpoint stopped working
Check Nomad's displayed LAN address, its WiFi Mode connection, the helper's power and network status, the Localtonet client's connection, and the tunnel's running state. A portable Nomad that moves between networks may receive a different address and require its local target to be revalidated.
Frequently asked questions
Which exact ESP32-S3 board should I buy?
The available official extract confirms the ESP32-S3 platform but does not reproduce the exact supported board variant or attached hardware. Use the current repository's Hardware Requirements before purchasing parts. Do not assume that all ESP32-S3 boards are interchangeable.
What local URL and port does Nomad use?
The available evidence does not establish a universal local URL or HTTP port. Use the current Quick Start and the address shown by the device. In WiFi Mode, Nomad displays its router-assigned IP address. Record the complete endpoint that works from the future tunnel host.
Does every guest need a Nomad account?
No. The project describes the guest browser experience as requiring no account. The admin login protects administrative settings. Therefore, a public tunnel may expose guest media to anyone who obtains the public URL unless a separate verified access-control layer is present.
Do I need exFAT for firmware 4.6?
Not for every workflow. Firmware 4.6 automatically detects exFAT, FAT32, and FAT16, and existing FAT32 cards remain supported. ExFAT supports individual files larger than 4 GB and is required for some advanced features.
Why must the firmware and SD card template match?
Firmware 4.6 changes both the embedded firmware and the SD card files. Mixing revisions can leave the interface or features without matching assets. Back up personal content, then use firmware and template files from the same revision.
Can Localtonet run directly on the Nomad ESP32-S3?
The available evidence does not establish a Localtonet client for the ESP32-S3. Run our client on another supported device that can reach Nomad's WiFi Mode address and has internet access.
Does the Localtonet tunnel add a login to Nomad?
This guide makes no such claim. An HTTP tunnel forwards requests to Nomad's browser service. Nomad's admin login protects administrative settings, while guest browsing is described as account-free. Evaluate and test that access model before publishing the endpoint.
Does an HTTP tunnel make DLNA available remotely?
No such behavior should be assumed. DLNA discovery is LAN-oriented. This workflow forwards only Nomad's verified browser-based HTTP endpoint.
Will the public address work if the helper computer sleeps?
No. The tunnel is available only while the selected Localtonet client is connected and the tunnel is running. Sleep, shutdown, internet loss, or client disconnection makes the public endpoint unavailable.
Connect a locally verified Nomad with Localtonet
Once the supported Nomad hardware is assembled, the matching firmware and SD card template work locally, and the browser endpoint is reachable from a separate LAN helper, you can create an HTTP tunnel without opening an inbound router port. Review Nomad's account-free guest model first, expose only content intended for that access model, and stop the tunnel whenever public access is not required.
Get Started Free →
