Reach your stack from anywhere.
Tillarr talks to each service straight from your iPhone, iPad or Mac. At home that's its local address. Away from home it needs a second way in. Here are the three that work, in the order we recommend them.
How Tillarr picks an address
Each service can have a home address and a remote one. Tillarr tries home first and gives it 3 seconds to answer, then uses the remote address. It remembers the last one that worked, so the next check starts there. You never switch by hand.
A change, such as removing a download or shutting down a guest, is never sent twice. If the first address took it, Tillarr reads the result again rather than repeat it on the other address.
1. Tailscale: the simplest
With Tailscale on your server and your device, your services are reachable wherever you are, and nothing is open to the internet. Add the Tailscale name as the remote address, for example http://media-server.tail1234.ts.net:8989.
For HTTPS without warnings, run tailscale cert on the server. It issues a real certificate for the machine's .ts.net name, so there's no fingerprint to accept. Certificates last 90 days, and the names appear in public certificate logs.
2. A Cloudflare Tunnel with Access
A tunnel gives each service a public hostname without opening a port. If Cloudflare Access protects it, a browser gets a sign-in page, but an app can't sign in that way. Use a service token instead:
- In Cloudflare Zero Trust, create a service token and copy its client ID and secret.
- In the application's Access policy, add a rule with the Service Auth action that includes the token. Without it, Access keeps showing the sign-in page.
- In Tillarr, open the remote address and add two headers: CF-Access-Client-Id and CF-Access-Client-Secret. Their values are kept in the Keychain.
Tokens expire, often after a year. When one does, Access refuses requests with 401 or 403: make a new token and update the two headers. Cloudflare also ends any request after 125 seconds, so a long manual search can time out on the tunnel while the arr keeps searching; Tillarr tells you it's still working.
3. Your reverse proxy, with or without a sign-in page
Behind Traefik, Caddy, Nginx Proxy Manager or SWAG, add the proxy's HTTPS address as the remote one. If a sign-in page such as Authelia or authentik guards it, Tillarr can't get through on its own: it uses each service's key, not your password. The best fix is to let the service's API paths skip the sign-in page, since the key still protects them.
- Authelia: a bypass rule for the API paths, placed first, for example resources: ['^/api([/?].*)?$']. You can limit it to your Tailscale network with networks.
- authentik: list the paths under Unauthenticated Paths on the proxy provider, one regular expression per line, such as ^/api/.*.
- Anything else: if your proxy accepts a header instead, add it to the remote address in Tillarr, just like the Cloudflare headers.
| Service | Paths to let through |
|---|---|
| Sonarr, Radarr, Prowlarr, Lidarr | ^/api/, ^/ping$ |
| Bazarr | ^/api/ |
| qBittorrent | ^/api/v2/ |
| Seerr | ^/api/v1/, ^/imageproxy/ |
| Proxmox VE | ^/api2/ |
| Jellyfin | The whole host: give it its own hostname, or bypass by network |
| SABnzbd | ^/api |
| NZBGet | ^/jsonrpc |
| Transmission | ^/transmission/rpc |
| Deluge | ^/json |
| Unraid | ^/graphql |
| Portainer | ^/api/ |
If you set a URL base such as /sonarr, put it in front of each path.
Self-signed certificates
Proxmox VE, Portainer and Unraid use their own certificates out of the box. The first time Tillarr meets one, it shows the certificate's fingerprint so you can compare it with the one on your server. Once you trust it, Tillarr checks that same certificate on every visit, the way SSH does, and stops if it ever changes.
If you run your own certificate authority, install it on your device as a profile and turn it on under Settings → General → About → Certificate Trust Settings. Then there's nothing to accept.
When it doesn't connect
Network activity, in Settings, lists the last 500 requests Tillarr made: which address each one went to, what came back and how long it took, with keys and tokens hidden. A web page where an answer from the service should be usually means a sign-in page is in the way.
Still stuck? Write to support@tillarr.com. Settings → Support can attach a diagnostics file, and you see everything in it before it's sent.