Bug Reports

While getting started with Railway I tried to deploy go-httpbin the build step failed with the following in the Build logs: Cache mount ID is not prefixed with cache key I'm able to build and deploy to my local docker using this build script: export CGO_ENABLED=0 export NIXPACKS_BUILD_CMD='go build -ldflags="-s -w" -o dist/go-httpbin ./cmd/go-httpbin' export NIXPACKS_START_CMD='./dist/go-httpbin -port $PORT' nixpacks build . --name go-httpbin --env NIXPACKS_BUILD_CMD NIXPACKS_START_CMD CGO_ENABLED This is an attempt to recreate the same variables defined in the service, but deployment still fails. Curious if this is a known issue with the go nixpacks provider and if there's a known workaround. If you try and reproduce, I ran it locally with: export PORT=8080 docker run -p $PORT:$PORT -e PORT go-httpbin

There is a bug with the first digit being dropped when 1Password pastes in one time code on login.

When you do a deployment rollback it says "This will restore both the build and variables". Currently all my variables remain untouched

If you open the RAW editor and insert variables with a : and save, you lose all of them. The : symbol is used in C# .NET Core for adding hierarchical configuration variables.

Jumping to the bottom while viewing logs, does not work. The buttons remains disabled. Note that jumping to the top works.

As in the title. They work locally and on the other platform but they are not working in Railway. What should I do in order to expose several env vars to the client side?

after click choose plan in developer and team pricing, show modals/popup for register but when i click the back button modals keep show up

After the "build" step the binary is supposed to be in ./target/<target triple>/release/forum and ./bin/forum but it attempts to start from ./target/release/forum

We canceled our plan due to a lack of features and went into manage stripe and payed the rest but that doesn't reflect on our dashboard.

The docs mention a 3-day grace period, but I received a notice of being "over" yesterday, and then today my deployment was removed. At the very least, I think it'd be good to indicate _why_ the deployment was removed.