Actually, the production deployment is still reporting the environment variables as undefined. Not sure how to proceed

The build definition also indicated the environment variables are defined, however, these are not being picked up at run time.

Unable to get this working. I did notice to build step for nix-env is cached. I don't know enough about nix but this is blocking deployments :(

It's worth noting that I'm using turbo pack and a bun runtime in my application. Bun does read environment variables differently than Node

Hey, there's nothing in these logs that would indicate that a variable isn't available, I'm seeing a "ECONNREFUSED: Failed to connect" error.

Howdy - the error in the logs is from our database connection process which uses process.env.DB_URL

console.log(
  '[DEBUG] This DB_URL_TEST should be defined:',
  process.env.DB_URL_TEST,
)
const client = postgres(process.env.DB_URL)

I've added a debug statement to the app, to demonstrate the issue in the logs without exposing our secrets.

Dev

> railway run bun run start:api

...
[DEBUG] This DB_URL_TEST should be defined: postgresql://postgres:password@localhost:5432/postgres
...

Production

> bun run start:api

...
[DEBUG] This DB_URL_TEST should be defined: undefined
...

I've validated the variable is defined in the details of the build.

Are both these commands being ran locally?

The second command is the start script used, for I'm assuming, the Dockerfile entrypoint in Railway. The debug output I'm capturing from the "Deploy Logs" panel

I would need to look into how you setup your Railway project in order to tell you if something was missconfigured in your Railway project or your code.

What info do I need to provide? I've attached the "Deploy log" but happy to provide any information to help!

What info do I need to provide? I've attached the "Deploy log" but happy to provide any information to help!

I'd be happy to hop on a call if that's more effective use of time

I'm sorry but we arent able to offer that level of support to Hobby at this time.

Yep you have the variable defined in your service and have deployed the changes.

Meaning this is a code issue, to help you debug this further I would need a minimal reproduceable example

I'm happy to upgrade to Pro if we can get this sorted as I'm evaluating a few different services for running our production APIs

That wont be necessary at this time, are you able to provide a minimal reproducible example?

Sure thing - let me put an app together real quick and I'll publish to a public Github repo

I was able to replicate the issue with using this example application: https://github.com/ByteSliceHQ/turbo-bun-app

In the Varibale definitions set:

TEST_ENV=world

Thank you, I will look into this when I'm at my computer.

This looks like what could be causing your issue -

https://turbo.build/repo/docs/crafting-your-repository/using-environment-variables#strict-mode

Completely missed that configuration! Specifying the env in the start script did the trick. Thanks for working through that with me

"start": {
  "cache": false,
  "persistent": true,
  "env": ["TEST_ENV"]
}

I'm a bit confused why it works when running turbo locally, but in the Railway runtime it behaves differently. I'll look into that (as I'm sure it's a global turbo configuration locally or something) and repost here for future people, but for now you've unblocked me. Cheers

Yeah global config or it's ran in loose mode locally.