Hey there! We've found the following might help you get unblocked faster:

• 🧵 Unable to Deploy w/ Prisma

• 🧵 blocked request with 403 Forbidden

• 🧵 Failed to upload code with status code 403 Forbidden with CLI

If you find the answer from one of these, please let us know by solving the thread!

Hi there, could you try re-authenticating your CLI?

I ran

railway logout

railway login --browserless
(visited URL and authorized the login)
railway link
railway up

Indexed Compressed [====================] 100% Failed Failed to upload code with status code 403 Forbidden

By the way, the problem is unique to a single service within this project (the rails api). I can deploy to another service with railway up just fine.

If I clone my Github repo to another directory on my Mac, I can deploy from that directory without a problem. This bug seems to be in the railway command itself. It persists even if I wipe out ~/.railway/config.json and re-authenticate and re-link.

As an example: Original directory -> ~/Code/repo-name/myproject
railway up

This fails

git clone repo-name ~/Downloads

cd ~/Downloads/repo-name/myproject

railway link
railway up

This works

So, it's specific to the local path somehow. Either credentials are getting cached somewhere other than ~/.railway or a server side auth check is comparing credentials with the local project path and rejecting the upload.

Ok, I was able to resolve this issue, though I'm not sure the exact cause.

After cloning my repo to a second folder and verifying I could deploy from that folder, I compared the contents of the two folder to see what files existed in the original that wasn't in the clone.

diff -rq api~old api

I deleted some logs and tmp files but that didn't fix the issue.

Finally, after deleting log files and a .ruby-lsp folder, I was able to deploy again from the original directory.

So the issue is somewhere in the railway up command, it's not happy with certain files.

Glad you got it working!

A hunch is that the log, temp, dot folder had data that couldn't be pushed because they were just too large or had certain permissions that prevent the push.

That was my guess as well. I wonder if the "403 Forbidden" text is from an actual HTTP error or rather a default error message. If it's the latter, an initial improvement to the CLI would be to improve the error messaging.