Is there an option to access Apps *without* the "login with Umbrel"?

General Discussion
1

Hello world,

I have added some apps on my Umbrel that I want to access securely through the Internet from any device. So a VPN is not an option.

Hence I created an external service on my kubernetes cluster pointing to the App’s IP / port combination, and while this works like a charm for pi-hole, it fails for any other App I tried (say, FreshRSS, code-server, transmission, …). Each time I access the App through the public DNS automatically provisioned by my kubernetes ingress (e. g. https://freshrss.my.k8s.dns) it will redirect to port 2000 for the “login with Umbrel” functionality (even though I have set up my own Login in FreshRSS).

So, the question is, can the detour via Port 2000 be disabled?
Or what would be the proper route to expose singular Apps under their own DNS name … ?

It is quite evident that it is possible, after all pi-hole works perfectly with no detour whatsoever …

Thanks for any advice and greetings,
—Thomas

2

I think you can disable it per app. You will have to poke in the individual app docker config.

3

Umbrel Dreams is right:
Below a more detailed explanation:
Connect to the Umbrel with ssh (in my screenshot I used winscp)

image
image761×439 31.4 KB

1.) find App Directory
2.) find DockerCompose File
3.) add PROXY_AUTH_ADD: “false” in the App Proxy config

Restart the container (can be done in the umbrel webinterface).

Greetings
Thomas

Further informations(found the solution in this documentaion): umbrel-apps/README.md at master · getumbrel/umbrel-apps · GitHub

4

Reitti + OwnTracks on umbrelOS 1.7.4: allow the ingestion endpoint instead of disabling all proxy authentication

Adding a Reitti/OwnTracks example to this discussion. On umbrelOS 1.7.4 with the official Reitti 5.5.0 package, the browser UI worked after signing in, but an OwnTracks HTTP request without the browser’s Umbrel session was redirected (HTTP 302) to Umbrel’s authentication service on port 2000 before reaching Reitti.

The official Reitti package currently sets APP_HOST and APP_PORT under app_proxy, but does not exempt the OwnTracks ingestion endpoint:

The minimal package configuration change that worked in this setup was:

services:
  app_proxy:
    environment:
      APP_HOST: reitti_app_1
      APP_PORT: 8080
      PROXY_AUTH_WHITELIST: "/api/v1/ingest/owntracks"

Back up the existing Compose file before editing and apply the change by recreating the app proxy. A plain docker restart will not load a changed environment. Our setup recreated only Reitti’s app_proxy service with the Umbrel Compose fragments; the application and database were left running. Do not run the app’s standalone Compose file without the Umbrel environment/fragments.

This exempts only that endpoint from Umbrel’s browser login. Reitti still performs its own API-token authentication. In our verification, a request without a token was redirected to Reitti’s /login rather than being accepted, and actual iPhone points appeared in Reitti’s Data Quality Report after configuration. Background tracking with the phone locked had not yet been verified.

Separately, for remote access we used Tailscale Serve, not Funnel. With the host-networked Umbrel Tailscale container named tailscale_web_1, and after checking existing Serve settings and ensuring 8443 was free:

sudo docker exec tailscale_web_1 tailscale serve status
sudo docker exec tailscale_web_1 tailscale serve --bg --https=8443 http://127.0.0.1:8744

OwnTracks settings:

  • Mode: HTTP
  • URL: https://YOUR-UMBREL.YOUR-TAILNET.ts.net:8443/api/v1/ingest/owntracks?token=YOUR_REITTI_API_TOKEN
  • HTTP Basic Authentication: off (the URL token authenticates the request)
  • Payload encryption key: empty
  • Tailscale connected on the phone

8443 is just an example; this separate listener let us preserve an existing service on HTTPS/443. Tailscale HTTPS and the API whitelist solve different problems. Serve does not remove any existing LAN or Tor access supplied by the app package.

Local package edits may be replaced by an app update, so the durable fix would be for the Reitti package to include an appropriate ingestion allowlist. I did not find a matching Reitti/OwnTracks auth issue in the two upstream issue trackers when searching.

There is also a newer option: umbrelOS 2.0 beta has a per-app appProxyAuthEnabled setting. That disables/enables the extra Umbrel gate for the whole app and is broader than this one-endpoint exception. It is not a reason to upgrade an otherwise working server to beta solely for this fix.

Would the maintainers consider adding the OwnTracks endpoint exception to the official Reitti package, so mobile ingestion works without local package edits?