Anyone seen this? Spent most of today on it and I'm stuck.

I have two services in the same project, both deploying from the same GitHub repo on the same Dockerfile (Alpine 3.19, runs as root). Inside the container there's wireproxy doing a small TCP forward on localhost so go2rtc can read camera streams from it.

One service has been running fine for weeks. The other one was created today and refuses to bind anything:

listen tcp 127.0.0.1:27441: bind: permission denied

Port's well above 1024. Running as root. Localhost. Just won't bind. Wireproxy crash-loops, my watchdog restarts it, repeat. Same error on 0.0.0.0, on [::1], on other unprivileged ports above 27000. Anything I tell wireproxy to listen on gets EACCES.

The weird part is the older service in the same project doing the exact same thing works fine. wg handshakes coming through, traffic flowing, etc. Then today I redeployed it (just a variable change) and it broke the same way. Like the bind permission goes away after the first redeploy.

What I've tried:

• different ports (27441, 27442, 30000+ range, etc)
• 0.0.0.0 vs 127.0.0.1 vs [::1]
• delete and recreate the service from the dashboard
• railway up from the CLI
• pushing a fresh commit and letting GitHub auto-deploy
• with PORT env var set, without it
• rolled back the broken service to the older deployment via the dashboard - actually came back to life briefly, then died on the next redeploy

It really does seem deploy-related. The first run after a fresh service create sometimes succeeds. Anything that triggers another deploy after that and bind permissions disappear.

Anyone know if there's a per-service flag I'm missing? Or did something change recently with how containers get launched? Is there a way to keep the same network capabilities a long-running service has when you spin up new ones? Running wireproxy on Railway used to work fine so I'm pretty sure I'm not crazy.

Happy to share logs if useful.