Skip to content

Reaching Your RomM Server

Jump to bottom
lodordev edited this page Jul 1, 2026 · 3 revisions

Reaching your RomM server

On first boot, LodorOS runs an onboarding wizard: connect Wi-Fi → choose how you'll reach RomM → pair with your server. LodorOS never exposes RomM on the open internet; you pick one of three private paths.

Which to use:

Path Best for Device requirement
Tailscale Most devices — works anywhere, not just home ≥ ~512 MB RAM (runs a small tunnel daemon)
Cloudflare Access Low-RAM devices (Miyoo Mini Plus), or anyone who prefers a public endpoint with a machine token Any device (just two HTTP headers)
Home network (LAN) RomM reachable by IP on the same Wi-Fi RomM must be published on your LAN

First set up the server side once — see RomM server setup.

Option A — Tailscale (recommended for capable devices)

Your RomM is exposed inside your private Tailscale network via tailscale serve, reachable at a *.ts.net MagicDNS name. LodorOS bundles a userspace Tailscale client.

In onboarding, choose Tailscale, then:

  1. Sign in — a QR code appears; scan it (or open the shown login.tailscale.com URL on your phone) and approve the device on your tailnet.
  2. Enter your RomM's Tailscale address — its MagicDNS name, e.g. romm.your-tailnet.ts.net.
    • Use the name, not the 100.x IP — tailscale serve routes by hostname, so a bare IP won't reach it.
  3. Pair — in RomM's web UI, create a client token / pair code and enter it on the device.

That's it — the device now reaches RomM through the encrypted tunnel from anywhere.

Miyoo Mini Plus (miyoomini) cannot use Tailscale — 128 MB RAM is too little to run the tunnel. Use Cloudflare Access.

Option B — Cloudflare Access (service token)

Your RomM is behind a Cloudflare Tunnel at a public hostname, protected by Cloudflare Access. The device authenticates non-interactively with a service token — two headers on every request — so there's no browser login and (on the Mini Plus) no daemon.

You'll need, from your Cloudflare Zero Trust setup (server side here):

  • your public RomM URL, e.g. https://romm.example.com
  • a service-token Client ID and Client Secret

Setup today (0.9): the config file is the escape hatch. LodorOS reads its entire connection setup from config.json, so any transport you can express there works immediately — Cloudflare Access included — without waiting on a dedicated wizard screen. The onboarding wizard doesn't yet have a service-token field (its "Advanced" mode captures a public URL only, which suits a plain reverse proxy but not a Cloudflare-Access-gated endpoint — that alone would just hit the login page), so for CF Access you drop the cf_access block into the card's config before first boot, as shown below. A guided, QR-based onboarding for Cloudflare Access is planned; the hand-editable config stays the flexible path for this and any other custom setup.

Edit Tools/<platform>/Lodor.pak/config.json on the card (create it if absent) so the host carries cf_access:

{
  "hosts": [
    {
      "root_uri": "https://romm.example.com",
      "cf_access": {
        "client_id": "<CF-Access-Client-Id>",
        "client_secret": "<CF-Access-Client-Secret>"
      }
    }
  ]
}

Then boot and pair with a RomM client token (the pairing request goes through Cloudflare too). LodorOS sends CF-Access-Client-Id / CF-Access-Client-Secret on every request; Cloudflare validates them and forwards to RomM, which still authenticates with its own token independently (the two live in different headers and don't collide).

Keep this config.json private — the client secret and RomM token are credentials.

Option C — Home network (LAN)

If RomM is published on your LAN (a host IP:port), choose Home network, enter e.g. http://192.168.1.50:8080, and pair. Simplest, but only works on the same network, and requires you to actually expose RomM on the LAN (many private setups don't — see the server-setup notes).

Two layers, always

Whichever path you pick, there are two independent auth layers:

  1. Transport auth — Tailscale membership or the Cloudflare service token — proves the device is allowed to reach the endpoint.
  2. RomM auth — the RomM client token you pair — proves the device to RomM itself.

Both are stored on the card and treated as secrets. See Troubleshooting if pairing or sync fails.

Clone this wiki locally