Docker port reassignment and reverse proxy access issues

[DaiLoDong]

This is more of a group troubleshooting effort / possibly suggestion

When you reassign ports in the default docker compose

services:
backend:
image: ghcr.io/adn8naiagent/f1replaytiming-backend:latest
ports:
- "8000:8000"
environment:
- FRONTEND_URL=http://localhost:3000
- DATA_DIR=/data
volumes:
- f1data:/data
- f1cache:/data/fastf1-cache

frontend:
image: ghcr.io/adn8naiagent/f1replaytiming-frontend:latest
ports:
- "3000:3000"
depends_on:
- backend

volumes:
f1data:
f1cache:

away from 3000:3000 and 8000:8000 issues arise as it requires a passphrase:
Enter passphrase to continue

Additionally, when you reverse proxy this (I am using cloudflare tunnels) it also has the same issues.
It continues to have the same issues even when I have moved other services off of 3000 and 8000 and leave this on default.
I have tried keeping default FRONTEND_URL=http://localhost:3000, does not work
I have tried changing the FRONTEND_URL=http://f1.domain.com, does not work
I have also tried to change the FRONTEND_URL=http://192.168.1.1:3000 for example, does not work

I have also tried assigning AUTH_PASSPHRASE=test and that also does not allow me to proceed
test

I have tried changing all of the above urls to https, does not make a difference

It does work locally on the machine when I remote in and access it via http://localhost:3000
No passphrase required and pops you into the correct screen

I am destroying the previous container and image each time to prevent any lingering configs, etc.
Curious if I am doing something wrong? or is this something hard coded that needs to be changed?

[Hyurt]

I guess public images are built with localhost

NEXT_PUBLIC_API_URL must be set on build as written on the documentation

[adn8naiagent]

Thanks for the detailed write-up. Others have raised similar issues so this was really helpful in identifying the scenarios causing issues.

There were two problems here:

1. The passphrase screen was showing even when Auth=false. This was poor error handling where users were bounced back to this screen when in fact there was a connection error with the backend.

2. NEXT_PUBLIC_API_URL was baked into the frontend at build time. The pre-built Docker images had
   http://localhost:8000 hardcoded into the JavaScript. Setting it as an environment variable in docker-compose did
   nothing because the value was already compiled in so only worked on a local machine.

FRONTEND_URL on the backend only controls CORS. It doesn't affect how the frontend connects to the backend. There's a separate variable, NEXT_PUBLIC_API_URL, that needs to be set on the frontend container. This was confusing and unhelpful.

In the latest release (1.2.1) have tried to address the above:

• The frontend now has better error handling and shows "Cannot connect to backend" error screen with the URL it's trying to reach, instead of the passphrase form. Should assist troubleshooting.
• NEXT_PUBLIC_API_URL is now a runtime environment variable. You set it on the frontend container in docker-compose and it just works (replaced the hardcoded string). No rebuilding needed.
• The README has been updated with examples for LAN access and reverse proxy setups.

For your Cloudflare Tunnel setup, your docker-compose would look something like:

backend:
environment:
- FRONTEND_URL=https://f1.yourdomain.com
frontend:
environment:
- NEXT_PUBLIC_API_URL=https://api.f1.yourdomain.com

Where your tunnel routes f1.yourdomain.com to the frontend container (port 3000) and api.f1.yourdomain.com to the
backend container (port 8000).

Both variables need to be set, and both need to be the URLs as your browser sees them, not internal Docker
addresses.

Let me know how you get on and any suggested improvements. Hope you enjoy using it!

[DaiLoDong]

Hey, thanks for the super quick turn around.

Follow up questions:
When I go to the reverse proxied f1-api.domain.com
or local version on local machine http://localhost:8000
or another local network computer using http://192.168.1.1:8000
it returns
{"detail":"Not Found"}

However, regardless what I set in the docker compose only the machine hosting it can access the main page using http://localhost:3000. even on the local machine using f1.domain.com does not work even though it correctly maps to that port.

I have the cloudflare tunnel set to
f1.domain.com -> http://localhost:3000
f1-api.domain.com -> http://localhost:8000
I have also tried the above but set to http://192.168.1.1:port as well for completeness

I think I understand the issue is that when accessing the main page via f1.domain.com it tries to resolve f1-api.domain.com into http://localhost:8000 but there is nothing on the device accessing it on port 8000?
Not 100% sure. Hopefully I have included enough details of my mistakes to help you possibly helping me and others that may face issues in the future.

Thanks again for the effort.

here is the compose for referece

services:
backend:
image: ghcr.io/adn8naiagent/f1replaytiming-backend:latest
ports:
- "8000:8000" # Change the left side to use a different host port
environment:
- FRONTEND_URL=https://f1.domain.com # Must match the URL you access the frontend on (for CORS)
- DATA_DIR=/data
# Optional - uncomment to enable features
# - OPENROUTER_API_KEY=your-key-here # enables photo/screenshot sync (manual entry sync works without this)
# - AUTH_ENABLED=true
# - AUTH_PASSPHRASE=test
volumes:
- f1data:/data
- f1cache:/data/fastf1-cache

frontend:
image: ghcr.io/adn8naiagent/f1replaytiming-frontend:latest
ports:
- "3000:3000" # Change the left side to use a different host port
environment:
- NEXT_PUBLIC_API_URL=https://f1-api.domain.com/ # Change to your backend URL if not using localhost
depends_on:
- backend

volumes:
f1data:
f1cache:

[adn8naiagent]

Not 100% sure either sorry. Confirming you have the latest build? May be worth trying to remove the trailing slash on - NEXT_PUBLIC_API_URL=https://f1-api.domain.com/ to https://f1-api.domain.com

Re, {"detail":"Not Found"} when browsing directly to f1-api.domain.com that's expected. The backend only serves under /api/ so the root has nothing there.

[5N4K3ii]

Here's a note for you. I set up F1Replay today via docker-compose with the latest tag. Because I'm running the docker on a headless machine, I changed the frontend and backend urls to be the internal IP address/ports I chose in my docker-compose file.

I am able to run it successfully on chromium-based browsers, but on FireFox I get an error about unable to connect to backend and it lists the url as http://localhost:port instead of http://ip-address:port that I have configured in the docker-compose.yml. I haven't taken the time to check, but I'm wondering if Firefox is being stricter about enforcing domain boundaries on an http URL. I will try putting a reverse proxy with a certificate on it so the URL is https and see if that makes any difference and report back.

[DaiLoDong]

Here's a note for you. I set up F1Replay today via docker-compose with the latest tag. Because I'm running the docker on a headless machine, I changed the frontend and backend urls to be the internal IP address/ports I chose in my docker-compose file.

I am able to run it successfully on chromium-based browsers, but on FireFox I get an error about unable to connect to backend and it lists the url as http://localhost:port instead of http://ip-address:port that I have configured in the docker-compose.yml. I haven't taken the time to check, but I'm wondering if Firefox is being stricter about enforcing domain boundaries on an http URL. I will try putting a reverse proxy with a certificate on it so the URL is https and see if that makes any difference and report back.

Hey thats a good call out. I am on brave and i see a similar thing when using the f1.domain.com link to access it. It says it cannot connect to http://localhost:8000 instead of what I set it to in the compose.yml

When accessing it from a local ip address like 192.168.1.1:3000 it shows the actual url that i configured in the compose.yml

Currently I have it working only via local ip access using that 192... ip address on both front and backend. I tried having both f1.domain.com -> localhost:3000 and f1-api.domain.com -> localhost:8000 mapped but it would not be able to connect to backend but displays as localhost:8000

Let me know if you end up figuring it out. I will tinker with it and see if I can get it to work properly with cloudflare tunnels.

[5N4K3ii]

I had some time to play around with it. Without changing the docker-compose (still ip addresses with ports for both frontend and backend) I put a reverse proxy with SSL and a domain name in front of the frontend. Chromium still worked if I hit the frontend via IP:Port, but Chromium would not connect to the backend if I accessed it via the secured domain name. Firefox still wouldn't work either way, but if I accessed it in FireFox via the secured domain name, the error message now correctly listed the backend URL I had in my docker-compose instead of http://localhost:port.

Next I put a name/cert in front of the backend and updated my docker-compose to reference these URLs. Both FF and Chromium work if I use the https://f1replay. that I set up in the docker-compose. Neither of them work if I go to the old http://IP:port (which makes sense). Just wanted to put it out there.

I don't know if there is a workaround so FF/Brave works without SSL/Certs, or if it just is worth mentioning in the README.md to help people avoid frustration.

Edit: I think the script running in the browser may save some connection information in browser cache. When I changed the backend URL in docker-compose and went right back to it in Firefox it still wanted to try to hit the old backend URL until I cleared recent history in the browser.

[DaiLoDong]

Interesting, this sounds like a cert + possible cache issue. I think this is not a tool I will rely on super hard. I think I can work around this using tailscale anyways for now.

Thanks a lot for the investigation. I am sure this will help others with similar issues.