The Instant File Server Alternative: How to Turn Localhost into a Public Drive

The developer’s dilemma: You’ve just wrapped a critical Friday sprint and need to hand off a 50GB Docker image, a huge SQL dump, or a folder of uncompressed 4K assets to a client or QA team. You drag the folder into Google Drive, S3, or Dropbox, and watch the upload progress bar crawl. Your download speed is fast, but residential upload speed is usually a fraction of that — so before your client can download anything, you have to wait for the entire payload to finish uploading first.

What if you skipped the cloud middleman entirely and let the client pull the files straight off your machine?

Tunneling tools like LocalXpose and Localtonet ship built-in file-server modes that do exactly that: point them at a folder, and they publish it to a public URL instantly, with no separate web server and no upload wait. This piece walks through how to turn localhost into a file server, the mechanics behind it, and the real (verified) command syntax and feature set for both tools — including Localtonet’s WebDAV network-drive mode and its newer encrypted-backup features.

---

Why cloud storage is the wrong tool for a quick handoff

1. The double-transfer bottleneck. Cloud storage is asynchronous: device A has to finish uploading 100% of the file before device B can start downloading. On an asymmetric home connection, a 20GB file at a 20 Mbps upload speed means over two hours just to stage the transfer — before your client has touched a single byte.
2. Storage and bandwidth limits. A multi-gigabyte log bundle or a staging-environment snapshot can blow through a free-tier storage quota fast, forcing cleanup or an upgrade for what’s meant to be a one-time handoff.
3. Data sovereignty. Uploading proprietary source, unreleased media, or client data (even sanitized) to a third-party cloud means it now sits on infrastructure you don’t control.
4. Sync fragility. Zipping up huge directories of tiny files (a node_modules tree, a static-site build) and pushing them through a desktop sync client is a common source of file-locking issues and corrupted transfers.

The alternative is peer-to-peer, zero-upload sharing: the client pulls the file directly off your disk, using only your available upstream bandwidth.

---

How reverse-proxy directory sharing actually works

Self-hosting a file server used to mean fighting your network: static IPs, router port-forwarding, firewall rules, and hoping your ISP doesn’t sit you behind Carrier-Grade NAT (CGNAT), which blocks inbound connections outright.

Modern tunneling clients invert this. Instead of opening a port and waiting for inbound traffic, a lightweight agent on your machine makes an outbound connection to a tunneling provider’s edge server. Outbound connections pass through NAT, CGNAT, and most firewalls without any configuration. The edge server hands you a public HTTPS URL; when someone requests it, the edge server proxies that request back down the already-open tunnel to your machine.

Point that architecture at a folder instead of an app on a port, and you get reverse-proxy directory sharing: a specific path on your disk, exposed securely and temporarily, without deploying a web server or touching your router.

---

LocalXpose’s built-in file server

LocalXpose is a general-purpose tunneling client (HTTP, TLS, TCP, UDP) that also ships a file-server mode built directly into its http tunnel type — no separate web server required.

The actual command

LocalXpose’s own tutorial docs give this exact syntax for a protected file share:

loclx tunnel http --subdomain mypics --basic-auth user:pass --file-server /home/pics

--file-server takes the folder path directly; --basic-auth user:pass gates the whole directory behind HTTP Basic Auth before the listing even renders, so unauthenticated requests get dropped at the edge rather than reaching your machine. --subdomain is optional — omit it and LocalXpose assigns a random one.

On Windows, the equivalent looks like:

loclx tunnel http --basic-auth client:supersecretpassword --file-server C:\Users\Dev\Deliverables

(LocalXpose’s marketing pages also show an alternate form, --to /path --file-server with --file-server as a boolean flag — both appear in the company’s own materials, but the syntax above is the one documented in the dedicated file-sharing tutorial and is the safer one to copy.)

Installing the client

LocalXpose ships packages for every major platform:

# macOS (Homebrew)
brew install --cask localxpose

# Linux (Snap)
sudo snap install localxpose

# Any platform with Node
npm install -g loclx

# Windows (Chocolatey)
choco install localxpose

Log in once with loclx account login, or export ACCESS_TOKEN for non-interactive/CI use.

Locking it down further

Basic Auth is the minimum. LocalXpose also supports an ip_whitelist plugin and a reserved_domain for a stable, memorable file-server URL, configurable via config.yaml:

file-server:
  type: http
  region: us
  reserved_domain: mydomain.com
  plugins:
    ip_whitelist:
      - 203.0.113.0/24
  apps:
    file_server:
      path: ./deliverables

For a share that needs to stay up unattended, loclx service install registers LocalXpose as a background OS service so the tunnel survives a terminal close or reboot.

---

Localtonet: three file-server modes, not one

Localtonet takes a broader approach: its File Server tunnel type has a dedicated “Process Type” selector on the dashboard offering three distinct modes — Default (browser file manager), SFTP, and WebDAV — all pointed at the same local folder path, no separate SFTP daemon or web server required on your end.

1. Default — browser-based file manager

Per Localtonet’s own documentation, the Default mode’s confirmed feature set is: upload, download, rename, move, copy, delete, folder creation, search, preview, tagging, and archiving, plus sharing. Permissions are managed per tunnel with global Upload / Download / Delete / Create Folder / Move / Share flags, and per-path overrides where the most specific path wins — a more granular scheme than a simple “read/write/delete” toggle.

As of mid-2026, Localtonet also added real security and backup depth to this mode that’s worth knowing about if you’re using it for anything beyond a one-off handoff:

• AES-256-CBC folder encryption, with keys that never leave your machine.
• Immich-compatible mobile photo backup with deduplication, for using it as a self-hosted photo-backup target.
• Scheduled cloud backup to Amazon S3 (and S3-compatible stores like Backblaze B2, Wasabi, or MinIO), FTP, or SFTP remotes — configurable with multiple providers running in parallel (e.g., a primary S3 target and a secondary SFTP target on a home NAS).

Localtonet’s documentation doesn’t confirm whether every one of these Default-mode features (encryption, Immich backup, scheduled cloud backup) also applies when you’re using the SFTP or WebDAV mode instead — treat those as Default-mode-specific until Localtonet documents otherwise.

2. SFTP — for existing tooling and automation

Selecting SFTP as the Process Type gives you a standard SFTP endpoint backed by the same local folder, so FileZilla, WinSCP, rsync, or CI backup scripts can connect with zero changes to their own configuration. Because Localtonet’s own agent serves the SFTP endpoint, you don’t need to install or expose a separate SSH/SFTP daemon on the host machine.

3. WebDAV — mount the folder as a network drive

WebDAV is the mode that lets a client mount your shared folder as a native drive rather than browsing it in a web UI or a file-transfer client:

• Windows: File Explorer → “Map network drive,” paste the Localtonet WebDAV URL, enter credentials.
• macOS: Finder → Cmd+K (“Connect to Server”), enter the URL.

Once mounted, the client can open, edit, and save files with their native desktop apps (Word, VS Code, Photoshop) without a manual download/re-upload cycle, and can drag-and-drop large files directly into the mount.

Setting up any Localtonet file-server tunnel

1. Install the Localtonet app for your OS and sign in.
2. Copy your AuthToken from the dashboard and paste it into the app.
3. Go to the File Server page, choose a Process Type (Random Sub Domain / Custom Sub Domain / Custom Domain), pick Default, SFTP, or WebDAV, and select your AuthToken and server region.
4. Enter the local folder path (e.g. C:\Users\Work on Windows, /root or /usr/share on Linux).
5. Press Start. By default all features are publicly enabled the moment the tunnel starts — click Manage under Permissions immediately if you need to restrict Upload, Delete, or Move before sharing the link.

---

A general framework for either tool

1. Install the client — LocalXpose (snap, brew, npm, or choco) or Localtonet (platform installer from its dashboard).
2. Authenticate — loclx account login for LocalXpose; paste your AuthToken into the Localtonet app.
3. Pick a sandboxed folder. Share a dedicated Transfer directory, never your project root or home directory — this avoids accidentally exposing .env files, .git/ history, or build artifacts that shouldn’t leave the machine.
4. Start the tunnel with authentication on. For LocalXpose, always add --basic-auth. For Localtonet, set the Default mode to the minimum permission set the recipient actually needs, or use SFTP/WebDAV credentials.
5. Share the URL, then tear it down. Once the transfer is confirmed, Ctrl+C the LocalXpose tunnel or hit Stop on the Localtonet dashboard — the public URL goes dead immediately.

---

Security best practices

• Least privilege. If someone only needs to download, don’t grant Upload/Delete/Move on Localtonet, and don’t skip --basic-auth on LocalXpose.
• Ephemeral by default. Treat a file-server tunnel like a temporary password — spin it up for the handoff and tear it down right after, rather than leaving it running on a workstation.
• Isolate the shared folder. Copy files into a dedicated share directory instead of pointing the tunnel at an active working/project directory.
• Watch the logs. Both tools show real-time connection activity in the CLI or dashboard — unfamiliar IPs or a burst of rapid, repetitive requests (bot scanning) is your cue to stop the tunnel immediately.

---

Other ways to get there

• Python + ngrok / Pinggy. No dedicated file-server client? python3 -m http.server 8080 in the target folder, then tunnel port 8080 with ngrok http 8080 or Pinggy. It lacks the permissioning of a purpose-built file server, but it works anywhere Python does.
• Pinggy’s own --serve shortcut. Pinggy’s newer CLI (the cli-js package) added a one-line equivalent: pinggy --serve /path/to/files starts a tunnel and serves that directory directly, combinable with its other auth/IP-whitelist flags — narrowing the gap with LocalXpose and Localtonet’s dedicated file-server modes.
• Tailscale / ZeroTier. If both sides are comfortable installing a mesh VPN client, putting both machines on the same private network and using native OS file sharing (SMB/CIFS) is an option — at the cost of requiring the recipient to install and authenticate into the VPN first, which a plain URL doesn’t.

---

Current pricing (2026)

	LocalXpose	Localtonet
Free tier	2 active HTTP tunnels	1 tunnel, 1GB bandwidth/month, 30-minute timeout
Paid tier	Pro: $8/month ($96/year) — 10 active tunnels, unlimited bandwidth	Pay-as-you-go: ~$2 per tunnel while actively running (prorated; a stopped tunnel costs nothing)
File server included?	Yes, on the free tier’s HTTP tunnel allowance	Yes, billed the same per-active-tunnel way as other tunnel types

LocalXpose doesn’t currently publish a specific bandwidth cap for its free tier in its own documentation — if that matters for a large one-off transfer, check the current pricing page before relying on it.

---

FAQ

What does it mean to turn localhost into a file server? It means exposing a specific local folder over a public URL so someone else can download (or, depending on mode, upload) files directly to and from your machine — without routing them through a cloud storage intermediary.

Is this safe? It can be, if you follow the basics: use HTTPS (both tools provision it automatically), gate the share behind authentication (--basic-auth on LocalXpose, permission flags or SFTP/WebDAV credentials on Localtonet), share only a sandboxed folder, and tear the tunnel down when you’re done.

Do I need a public IP or port forwarding? No. Both tools work by making an outbound connection from your machine to the provider’s edge servers, which sidesteps NAT, CGNAT, and router configuration entirely.

What’s the practical difference between Localtonet’s SFTP and WebDAV modes? SFTP is for existing tools and automation — FileZilla, WinSCP, rsync, CI scripts — that already speak the SFTP protocol. WebDAV is for mounting the folder as a native drive so someone can open and save files with normal desktop apps, no separate client required.

---

Changelog

Verified against LocalXpose’s and Localtonet’s own documentation and blogs, checked September 7, 2026.

• Corrected LocalXpose’s file-server CLI syntax. The draft used loclx tunnel http --file-server /path --basic-auth user:pass; the tool’s own dedicated tutorial page documents the flag order as loclx tunnel http --subdomain X --basic-auth user:pass --file-server /path. Kept the draft’s basic approach but matched the documented flag order, and noted LocalXpose’s marketing pages inconsistently show a second, --to /path --file-server-as-boolean form.
• Replaced unconfirmed Localtonet Default-mode features. The draft claimed inline browser text editing of .json/.js/.css files and a “built-in recycle bin” for Localtonet’s Default file manager — neither appears in Localtonet’s current documentation or blog coverage of that feature. Replaced with the actual documented feature list (upload, download, rename, move, copy, delete, folder creation, search, preview, tagging, archiving, sharing).
• Corrected Localtonet’s permission model. The draft described “granular user permissions (Read, Write, Delete)”; Localtonet’s documentation specifies global Upload/Download/Delete/Create Folder/Move/Share flags with per-path overrides, not a simple read/write/delete scheme.
• Added Localtonet’s newer File Server capabilities, missing from the draft entirely: AES-256-CBC folder encryption, Immich-compatible mobile photo backup, and scheduled cloud backup to S3-compatible storage, FTP, or SFTP remotes (documented as of mid-2026). Flagged that these aren’t confirmed to extend to the SFTP/WebDAV modes.
• Clarified the Localtonet SFTP/WebDAV setup model. The draft implied a generic “expose a local SFTP server” workflow; Localtonet’s actual mechanism is a “Process Type” selector (Default/SFTP/WebDAV) on the File Server tunnel page, with Localtonet’s own agent serving the protocol directly — no separate local SFTP daemon needed.
• Added Pinggy’s --serve flag as an alternative the draft’s “Alternative Solutions” section didn’t cover, since it directly undercuts the draft’s framing that non-dedicated tools “lack the built-in ease” of a file server.
• Added current, sourced pricing for both tools — absent from the draft entirely: LocalXpose (free: 2 HTTP tunnels; Pro: $8/month, $96/year, 10 tunnels, unlimited bandwidth) and Localtonet (free: 1 tunnel/1GB/30-min timeout; pay-as-you-go: ~$2 per active tunnel/month).
• Added concrete LocalXpose install commands (Homebrew, Snap, npm, Chocolatey) and the config.yaml/reserved_domain/ip_whitelist/loclx service install options for a persistent, IP-restricted file-server tunnel — none of which were in the draft.
• Stripped non-standard scaffolding. Removed a failed Python code-generation transcript, tracebacks, and file-write wrapper code that had leaked into the draft body, along with front-matter metadata; normalized heading structure into standard Markdown.