The repository is currently private.

I'd also check the middlewares you're using (if any).

It's most likely a library in your app that's returning this response (an auth library maybe). Railway's edge simply passes the response and status it receives from your app, so it most likely isn't the issue here.

I’ve reviewed the current publication settings and middleware configuration.

Repository / App visibility

• App is publicly deployed: effective_publish_visibility: public
• URL: https://audio-script-suite.lovable.app
• “Repository is private” appears to refer to the source repository visibility within Lovable. This should not affect the Railway renderer unless the project is connected to GitHub and exposed there.

Relevant middleware (src/start.ts)

• errorMiddleware: handles server-side errors and renders HTTP 500 responses.
• attachSupabaseAuth: attaches Supabase Bearer tokens to createServerFn RPC calls.
• requireSupabaseAuth: protects specific server functions (Works, Episodes, Audio, Timeline, SFX, etc.).

Railway 401 diagnosis

These middlewares do not intercept or block the external fetch() request from the app to Railway. attachSupabaseAuth only applies to serverFn calls.

Therefore, the 401 Unauthorized is most likely being generated by Railway App/Deployment Protection, not by the application code.

Required Railway configuration

Please verify/disable:

Railway → Settings → Networking/Security → App/Deployment Protection

The following endpoints must be publicly accessible:

• /health
• /version
• Render endpoint

Repository privacy and the current application middleware configuration do not appear to be the cause of the 401.

Again, I'd test this locally and/or add logging every step of the way from when your application receives the request to responding to the request to help with the debug process.

Also, the reason I asked about repository visibility was so I could check the codebase.

Railway answers 502 when its edge cannot reach your app not 401.

The Server: railway-hikari header is stamped on every proxied response so it proves nothing.

Call the deployment over railway.internal from another service and check the 401 persists.

The consistent 401 {"error":"Unauthorized"} response from Server: railway-hikari is a strong indication that the request is being rejected at the Railway edge before it reaches the container.

A few details make this particularly notable:

• /health is implemented to return 200 OK with ok, but never reaches the application.
• / has no Express route and should therefore return the application's normal 404, but instead receives the identical edge-generated 401.
• /version also receives the same 401.
• Redeployment, regeneration of the public domain, environment-variable verification, and disabling Under Attack Mode did not change the behavior.
• The trial is active, so billing/expiration does not appear to explain the response.

The most useful next step would be to check the edge configuration associated with this specific service/domain for any access-control policy, authentication middleware, private-network restriction, inherited protection rule, or trial-project restriction that may not be exposed in the normal Networking UI.

If possible, please also confirm whether Railway can see the incoming requests at the edge and whether they are being rejected before proxying to port 8080.

If the edge is intentionally returning this 401, identifying the exact policy/rule responsible should distinguish an application issue from a Railway edge configuration issue.