Self-Host Nixflix with Localtonet Remote Access

What Nixflix configures on NixOS

Nixflix is a declarative media server configuration manager for NixOS. Its purpose is to automate the connective configuration required by a media stack rather than leaving every integration to be completed manually through separate web interfaces. The project supports a Starr stack containing Sonarr, Radarr, Lidarr, and Prowlarr, along with user-facing and supporting services such as Jellyfin, Seerr, Navidrome, SABnzbd, qBittorrent, and Maintainerr.

The project uses the official REST APIs of supported services, with a small number of documented exceptions, to apply configuration represented through NixOS options. Its design is idempotent, so the declared configuration remains the source of truth and can be applied repeatedly. Nixflix can also create media and state directories, configure relationships between services, establish root folders, and manage custom service dependencies.

This architecture is important for remote access. Nixflix does not represent one universal web application with one guaranteed port. It can configure several independent services, and each service has a different role. Jellyfin is typically the interface used to browse and stream a personal media library, while Seerr provides media request management and integrates with Jellyfin libraries and Starr services. Administrative tools such as Sonarr, Radarr, and Prowlarr have powerful management interfaces that generally deserve more restrictive access than a user-facing media or request interface.

Plan the installation before changing the server

Start with the current Nixflix documentation and its Installation Guide. Nixflix is an actively developed NixOS project, and the exact method used to add it to a system can change between releases. The available evidence establishes that users should begin with the Installation Guide, then use the examples and complete option reference. It does not establish a universal flake input, import expression, channel requirement, or compatibility matrix that can safely be copied into every NixOS installation.

For that reason, this guide does not invent a flake URL, module import path, release pin, or NixOS version requirement. Follow the installation syntax shown by the documentation for the Nixflix release you actually select. If upgrading from an earlier deployment, read the relevant release notes before rebuilding. Nixflix v3.0.0 included a breaking change related to where the Jellyfin manifest is obtained, so an older configuration should not be assumed to migrate without review.

Install and configure Nixflix

The Nixflix quick example demonstrates the shape of a small configuration with Sonarr, Prowlarr, SABnzbd, and Jellyfin enabled. It also demonstrates secret-file references rather than embedding API key values directly in the Nix expression:

{ nixflix = {
  enable = true;
  mediaDir = "/data/media";
  stateDir = "/var/lib";

  sonarr = {
    enable = true;
    config.apiKey = {
      _secret = "/run/secrets/sonarr-api-key";
    };
  };

  prowlarr = {
    enable = true;
    config.apiKey = {
      _secret = "/run/secrets/prowlarr-api-key";
    };
  };

  sabnzbd = {
    enable = true;
    settings.misc.api_key = {
      _secret = "/run/secrets/sabnzbd-api-key";
    };
  };

  jellyfin.enable = true;
}; }

Treat this as a starting structure, not a complete production policy. The referenced secret files must exist through a secret-management approach appropriate for the system, and their contents must never be committed to a public repository. The media directory must be mounted and readable by the relevant services. The complete Nixflix reference should be used for service-specific options, users, libraries, quality profiles, download clients, reverse proxies, and other integrations.

Rebuild and verify local operation

After the Nixflix module has been installed and configured according to its documentation, apply the NixOS configuration:

sudo nixos-rebuild switch

A successful rebuild is only the first verification checkpoint. Check the systemd status of every service you intend to use. For a Jellyfin deployment, the documented status command is:

sudo systemctl status jellyfin

The standard NixOS Jellyfin service uses port 8096 by default, and a standalone local installation can normally be tested at http://localhost:8096. However, Nixflix supports nginx and Caddy reverse-proxy integration, and your Nixflix options can produce a different effective endpoint. Do not assume that port when a proxy, custom network configuration, or service-specific override is active.

Test the exact endpoint from the machine that will run the Localtonet client. If the client runs directly on the NixOS server, a loopback address may be suitable. If it runs on another device, the service must be reachable from that device over the local network. Complete Jellyfin’s application setup, confirm that its web interface loads, and verify that authentication works before making it remotely reachable.

Choose the right endpoint to expose

Expose the smallest useful surface. Jellyfin is appropriate when remote users need to browse or stream an authorized personal library. Seerr is appropriate when users should submit and manage media requests without receiving access to the broader administration stack. An nginx or Caddy endpoint can be appropriate when Nixflix already places the service behind a configured reverse proxy.

Add Localtonet remote HTTP access

Once the Nixflix service is working locally, an HTTP tunnel is the natural fit for a browser-based Jellyfin, Seerr, nginx, or Caddy endpoint. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The resulting tunnel provides a public address while the selected client is connected and the tunnel is running.

For current dashboard details, consult our Localtonet HTTP tunnel documentation. Recheck the application after every significant Nixflix or reverse-proxy change. A declarative rebuild can alter service listeners, proxy behavior, or enabled components, so the public endpoint should be retested rather than assumed to remain correct.

Frequently asked questions