3 months ago
## Description
Cross-service variable references using the ${{ServiceName.VARIABLE}} syntax work correctly in persistent environments (production) but fail to resolve in PR environments. The reference is stored as a literal string instead of being evaluated.
## Environment
- Project: trader (contains multiple services + PostgreSQL)
- Affected: All PR environments
- Working: Production environment
## Steps to Reproduce
1. Create a project with a PostgreSQL service named "Postgres"
2. In another service set environment variable:
```
DATABASE_URL=${{Postgres.DATABASE_URL}}
```
3. Verify this works in production environment (variable resolves to connection string)
4. Open a Pull Request to trigger PR environment creation
5. Check the DATABASE_URL variable in the PR environment's trader-api service
## Expected Behavior
DATABASE_URL should resolve to the PostgreSQL connection string, e.g.:
```
postgresql://postgres:xxx@postgres.railway.internal:5432/railway
```
## Actual Behavior
DATABASE_URL contains the literal unresolved reference:
```
${{Postgres.DATABASE_URL}}
```
## Investigation Findings
- The Postgres service DOES exist in the PR environment
- The Postgres service's DATABASE_URL IS correctly resolved when viewed directly
- Only the cross-service reference from trader-api → Postgres fails to resolve
- This affects all services referencing ${{Postgres.DATABASE_URL}}
## Workaround
Currently manually hardcoding the PostgreSQL connection string in each PR environment after creation.
## Impact
Every PR environment requires manual intervention to set database connection strings, breaking the automated PR preview workflow.
4 Replies
3 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open brody • 3 months ago
3 months ago
Hey, I'm unable to reproduce your issue as we use PR environments daily in our company. Are you sure that they're not being resolved? For example, is your service unable to connect to your Postgres database?
Also, be aware that if you use the Raw Editor or click too fast on the view button of the variable, the variable might appear as non-referenced. This is merely a visual bug of the dashboard taking a little time to load.
passos
Hey, I'm unable to reproduce your issue as we use PR environments daily in our company. Are you sure that they're not being resolved? For example, is your service unable to connect to your Postgres database?Also, be aware that if you use the Raw Editor or click too fast on the view button of the variable, the variable might appear as non-referenced. This is merely a visual bug of the dashboard taking a little time to load.
3 months ago
Positive, I activated the option to share the environment variables from production to PR environments; this includes the variable used to connect to the Postgres database in production. The shared variable in the PR environments resolves to the production database connection string, not the PR environment connection string. This results in all services crashing [that utilize that variable], until I go into the PR environments shared variables and change its value to the Postgres connection string for that particular PR environment. Happens with each PR environment created.
haighd
Positive, I activated the option to share the environment variables from production to PR environments; this includes the variable used to connect to the Postgres database in production. The shared variable in the PR environments resolves to the production database connection string, not the PR environment connection string. This results in all services crashing [that utilize that variable], until I go into the PR environments shared variables and change its value to the Postgres connection string for that particular PR environment. Happens with each PR environment created.
3 months ago
So it's getting an environment variable but from production? And by shared variable, do you mean these: https://docs.railway.com/guides/variables#shared-variables?
3 months ago
I'm referring to the following being enabled:
Project Settings > Environments > Base Environment: Variables from this environment will be used in the PR Environment.
Shared Variable DATABASE_URL, from production, ${{Postgres.DATABASE_URL}}, is shared to PR-XXX, upon creation.
The Shared Variable, in PR-XXX, shared [from production environment] is ${{Postgres.DATABASE_URL}}.
expected behavior = ${{Postgres.DATABASE_URL}} in PR-XXX Shared Variables --resolves to--> PR-XXX Postgres URL
actual behavior = ${{Postgres.DATABASE_URL}} in PR-XXX Shared Variables --resolves to--> production Postgres URL
Actual behavior is confirmed by viewing DATABASE_URL in Service Variables for each affected service; service variable displays production DATABASE_URL value, not PR-XXX DATABASE_URL.
This results in PR-XXX's affected services always crashing, upon initial deployment; only remedy I've found is to overwrite PR-XXX Shared Variable DATABASE_URL with the actual DATABASE_URL value from PR-XXX Postgres instance.