Self-Host Fireshare and Share It with Localtonet

How the Fireshare and Localtonet setup works

Fireshare runs as a containerized web application on hardware you control. It scans mounted video and image directories, presents the media through a browser interface, and creates unique links that can be used to share individual files. Its documented features include public and private feeds, link-only private media, password-protected videos, folder sharing, uploads, tags, search, view counts, mobile support, optional transcoding, TOTP two-factor authentication, login IP whitelisting, LDAP support, RSS feeds, and webhook-compatible notifications.

Docker publishes the container's internal HTTP listener on a port belonging to the host. The documented configuration maps host port 8080 to container port 80, producing the local endpoint http://localhost:8080. This local endpoint should be tested before any tunnel is created. Separating installation from remote access makes troubleshooting much easier because it establishes whether a failure belongs to Fireshare, Docker, the host filesystem, or the remote connectivity layer.

After Fireshare responds locally, the Localtonet client on the same machine, or on another device that can reach that machine, establishes an outbound connection to one of our relay servers. An HTTP tunnel then points to the Fireshare host and port. The tunnel provides a public HTTPS address while it is running and while the selected Localtonet device remains connected.

Prerequisites for self-hosting Fireshare

Begin with a machine that can remain online whenever the library needs to be available. Fireshare's intended installation method is Docker. For the Compose workflow, the machine also needs a functioning Docker Compose command compatible with the documented docker-compose up -d invocation. The exact way to install Docker varies by operating system and distribution, so use the installation package or repository maintained for your host rather than copying an unrelated platform command.

You also need host storage for four distinct purposes: the internal database, generated metadata, source videos, and source images. The account represented by the configured PUID and PGID must be able to read and write the mounted locations. Storage requirements depend on the size of the source library and whether transcoding is enabled. Generated lower-quality copies and poster or metadata files consume additional space.

Prepare the following before creating the container:

• A working Docker installation.
• Docker Compose if using the recommended Compose workflow.
• A directory for Fireshare's persistent /data content.
• A directory for generated /processed content.
• Existing or newly created source directories for /videos and /images.
• A unique administrator username and a strong administrator password.
• A random, private value for SECRET_KEY when using the documented Compose configuration.
• The numeric user ID and group ID that should own files written through the mounts.
• The Localtonet client for the later remote-access stage.

On a Linux host, the Fireshare documentation instructs users to run id to find the current account's UID and GID. Use values that match the owner of the host directories rather than blindly retaining the example values. PUID and PGID affect which user and group own files written into the mounted volumes.

id

Confirm that the intended host port is available. The documented configuration uses port 8080. If another process already owns that port, Docker cannot publish the mapping as written. Fireshare documents that the host-side mapping is the normal place to change the externally accessible port. The internal FIRESHARE_PORT setting defaults to 80 and should normally be left alone unless host networking is deliberately being used.

Plan Fireshare's persistent storage

Container filesystems are disposable. Fireshare therefore requires four host-mounted directories so application state and media remain available when a container is recreated. Treat these mounts separately because each serves a different role.

Bind mounts connect a real host directory to a fixed path inside the container. For example, a host directory such as /srv/fireshare/data can be mounted at /data. Fireshare only sees the container path, while the administrator manages persistence and permissions through the host path.

The examples below intentionally retain descriptive path placeholders. Replace every /path/to/... value with an absolute path appropriate for your machine. Avoid selecting temporary directories or locations that may be removed by routine cleanup. If your videos and images are already organized elsewhere, mount those existing directories rather than duplicating the media solely for the container.

The documented examples use read-write mounts. That supports Fireshare features that may write to mounted storage, including optional uploads. If you change a mount's access mode, evaluate the consequences for scanning, uploads, cropping, generated content, and any other operation that needs to modify files. The available evidence does not establish a universal read-only configuration for every Fireshare feature, so test any hardening change against the exact operations you plan to allow.

Install Fireshare with Docker

Docker Compose is the clearer long-term approach because the service definition, volume mappings, credentials, image selection, and port mapping remain in one declarative file. Docker Run is also documented and is useful when a single command better fits the host's management workflow. Choose one installation method rather than starting duplicate containers with both.

Option 1: Docker Compose with the Lite image

The documented Compose example uses shaneisrael/fireshare:latest-lite. The Lite image uses the system-provided FFmpeg instead of the CUDA-enabled build included in the standard image. It is smaller and is a good fit for users who do not require NVIDIA GPU transcoding. CPU transcoding remains supported.

Create a working directory for the deployment, then place a Compose file in that directory using the following structure. Replace all host paths, credentials, the secret key, and identity values before starting it.

services:
  fireshare:
    container_name: fireshare
    image: shaneisrael/fireshare:latest-lite
    ports:
      - "8080:80"
    volumes:
      - /path/to/data:/data
      - /path/to/processed:/processed
      - /path/to/videos:/videos
      - /path/to/images:/images
    environment:
      - ADMIN_USERNAME=your-admin-username
      - ADMIN_PASSWORD=your-admin-password
      - SECRET_KEY=replace-with-a-private-random-value
      - DOMAIN=
      - PUID=1000
      - PGID=1000

The example values 1000 for PUID and PGID are not universal. Replace them with the IDs that match the owner of your host directories. Also replace the administrator placeholders and secret key. Leaving DOMAIN empty allows you to finish local verification first. The setting should later represent the domain where the instance is hosted because Fireshare requires it for Open Graph metadata to work correctly on shared links.

From the directory containing the Compose file, run the documented startup command:

docker-compose up -d

Detached mode returns control to the terminal while the container continues running. Docker may need to download the selected image before the application becomes available.

Option 2: Docker Run with the standard image

The documented Docker Run example uses the standard shaneisrael/fireshare:latest image. Run the following from the parent location where you want the relative fireshare/data and fireshare/processed directories to reside. Replace the video and image paths, administrator credentials, PUID, and PGID.

docker run --name fireshare \
  -v $(pwd)/fireshare/data:/data:rw \
  -v $(pwd)/fireshare/processed:/processed:rw \
  -v /path/to/my/videos:/videos:rw \
  -v /path/to/my/images:/images:rw \
  -p 8080:80 \
  -e ADMIN_USERNAME=your-admin-username \
  -e ADMIN_PASSWORD=your-admin-password \
  -e PUID=user-id-with-read-write-permissions \
  -e PGID=group-id-with-read-write-permissions \
  -d shaneisrael/fireshare:latest

This command creates a container named fireshare, mounts the four required storage locations, maps host port 8080 to container port 80, sets the initial administrator identity, and runs the standard image in detached mode.

Choose the appropriate Fireshare image

Transcoding is disabled by default. When enabled, Fireshare creates lower-quality versions of supported original videos for adaptive playback. It does not modify the original file, and the original is still served directly to viewers. Because of that behavior, the source file itself must use a supported container and encoding.

Documented video containers are MP4 with .mp4, Apple MP4 with .m4v, QuickTime with .mov, and WebM with .webm. Documented encodings include H.264, H.265, AV1, and VP9. Browser playback capabilities still matter, which is one reason optional lower-quality transcoded versions can be useful.

To enable CPU transcoding, add the documented environment setting to the selected container configuration:

ENABLE_TRANSCODING=true

The standard image can also use GPU mode with:

ENABLE_TRANSCODING=true
TRANSCODE_GPU=true

GPU mode requires an NVIDIA GPU with NVENC support. Fireshare automatically selects an available encoder and can fall back to CPU processing if GPU encoding fails. Hardware capabilities differ, so verify support for the intended codec on the actual GPU rather than assuming every NVIDIA model can encode every format.

Verify Fireshare before remote exposure

Open the documented local address on the Docker host:

http://localhost:8080

If the browser is running on a different device on the same LAN, localhost refers to that other device, not the Docker host. In that case, use the Docker host's LAN address with port 8080, provided the host networking and local policy allow it. The exact LAN address depends on your environment and should not be guessed.

Use the administrator username and password configured for the container. Confirm that the interface loads, authentication succeeds, and the expected mounted media can be discovered. Test with a supported media file and verify that its page and playback behavior work locally.

Useful generic Docker checks include listing containers and reading the Fireshare container logs:

docker ps -a
docker logs fireshare

Look for clear startup, binding, database, scanning, and permission errors. Do not publish complete logs without reviewing them for usernames, internal paths, addresses, or other sensitive information.

Configure Fireshare for practical sharing

A successful home page is only the beginning. Before making the service public, decide how media should be organized, who may sign in, whether uploads are allowed, and which items should be public, link-only, or password-protected.

Understand public, private, and password-protected media

Fireshare supports public and private feeds. Private media is link-only, meaning it is intended to be reached through its direct link rather than displayed in the public feed. A secret-looking URL is not equivalent to strong authentication because anyone who receives or discovers the URL may be able to pass it onward. Use Fireshare's password protection when an individual video needs an additional access check.

Test the chosen visibility mode in a private browser window before distributing a link. This reveals whether an unauthenticated viewer sees the intended result. Also test the behavior from a mobile browser if mobile viewing matters to the audience.

Set the public domain for rich previews

Fireshare documents the DOMAIN environment setting as the domain where the instance is hosted and states that it is required for Open Graph metadata to work correctly for shared links. Open Graph metadata is what allows compatible chat and social applications to build a rich preview instead of showing only a raw URL.

Complete the Localtonet HTTP tunnel first so you know the actual assigned public HTTPS address. Then set DOMAIN to the public host used for the Fireshare instance and recreate or restart the container through your established Docker management workflow. The supplied Fireshare evidence does not define whether this value should include a scheme in every release, so confirm the expected formatting in the current Fireshare environment-variable documentation before committing the production value.

Enable optional account protections

Fireshare supports TOTP two-factor authentication using authenticator applications. It also supports login IP whitelisting with individual addresses or CIDR ranges. These controls protect login attempts, but they require careful planning when traffic arrives through a reverse proxy or tunnel. The application may observe a proxy-related address depending on how request information is conveyed and interpreted.

Expose the working Fireshare server with Localtonet

Once http://localhost:8080 works, Fireshare is an appropriate HTTP tunnel target. With Localtonet, the client device establishes an outbound connection to our relay infrastructure. This avoids opening an inbound router port or requiring a public IP address.

Install and run the Localtonet client on the Docker host or on another device that can reach the Fireshare host. If the client runs on the same host, the target can use the local service address and port. If it runs elsewhere, use an address that is reachable from that client device. Do not use localhost on a different machine because it would refer back to the Localtonet client machine itself.

The currently available authentication tokens, relay servers, regions, and process types must be selected from the current Localtonet dashboard. We do not hardcode those values because availability can vary by plan, client version, region, and deployment.

HTTP and File Server tunnels can use a generated subdomain, a selected subdomain where supported, or a custom domain. For this Fireshare workflow, all HTTP process types serve the configured local content through a public HTTPS address. Exact custom-domain DNS instructions are intentionally not included because they must be checked against the current Localtonet documentation and dashboard.

For the current interface and supported options, consult the Localtonet HTTP tunnel documentation .

Routine operation and troubleshooting

Starting and stopping the container

If the container was created by Docker Run and retained under the documented name, Docker can start and stop it by name:

docker stop fireshare
docker start fireshare

For Compose deployments, perform lifecycle operations from the directory containing the Compose file using the Compose tooling installed on the host. Keep a protected copy of the deployment definition so the same mounts, identity values, credentials, image choice, and port mapping can be reproduced.

Before changing images or recreating containers, back up the persistent data required by your recovery plan. A container image is replaceable, but the database and your media library may not be. The evidence supplied for this guide does not define an application-specific backup and restore command, so do not assume that copying live files without considering consistency is sufficient for every deployment.

Fireshare does not open at localhost:8080

First check whether the container is running. If it exited, inspect its logs. Common categories include an unavailable host port, an invalid mount path, a missing directory, or inadequate permissions. Verify that the port mapping is exactly the one intended and that another process is not already using host port 8080.

If you changed the host-side port mapping, the browser URL and Localtonet target must use the new host port. Leave the container-side listener at its documented default unless you have a specific host-networking reason to change FIRESHARE_PORT.

The interface opens, but media is missing

Confirm that the host source directories are mounted to /videos and /images, not accidentally reversed or mounted to unrelated paths. Verify that the selected PUID and PGID can traverse the parent directories and read the files. Also confirm that the files use documented formats and encodings.

Fireshare scans its library, so newly added content may not appear at precisely the same instant it is copied. Current Fireshare releases also support on-demand scanning from the administration interface. A documented setting of MINUTES_BETWEEN_VIDEO_SCANS=0 disables automatic scans, so check that setting if content appears only after a manual scan.

Fireshare works locally but not through Localtonet

Confirm that the Localtonet client is connected and that the HTTP tunnel has been started. Then verify the local target from the client device itself. If Localtonet runs on the Docker host, test the same local endpoint used by the tunnel. If it runs on another machine, verify that machine can reach the Docker host's LAN address and selected host port.

A target of 127.0.0.1:8080 or localhost:8080 is correct only when the Localtonet client and Fireshare service are reachable through the same machine's loopback interface. It is incorrect when the client runs on another device.

The page loads remotely, but video playback fails

Test the same file locally. If local playback also fails, investigate the file container, encoding, permissions, and Fireshare logs before changing the tunnel. Fireshare serves original files directly, even when transcoding is enabled, while lower-quality generated versions supplement the original. Browser codec support and the viewer's connection can therefore affect playback.

If local playback works, test the public URL in a clean browser session and compare multiple supported files. Check whether the problem affects the player page, only a particular rendition, or only a rich preview. These distinctions separate media compatibility from public-domain metadata configuration.

Shared links produce incorrect previews

Verify the DOMAIN setting against the public address actually used by viewers. A local hostname or obsolete tunnel address cannot generate correct public links. Preview providers may also cache prior metadata, so a corrected configuration may not immediately replace an old preview everywhere.

Security checklist before sharing the public URL

Remote access changes the audience that can send requests to Fireshare. Review the application and host as an internet-reachable service, even if most individual items are intended to be private.

Keep Docker, the host operating system, Fireshare, and the Localtonet client maintained. Review release notes before upgrades, particularly when authentication, LDAP, environment parsing, or database behavior changes. Test significant changes locally before depending on the public tunnel.

Frequently asked questions