CI Deployment Fails for NestJS App on Railway – Connection Refused Error

studiobo

HOBBYOP

a month ago

Hi, I’m trying to deploy my NestJS app using CI to Railway, but the deployment is failing with a connection error.

This is the command being executed in CI:

railway up --service $SERVICE_ID --environment $RAILWAY_ENV

Environment variables:

RAILWAY_ENV=develop
SERVICE_ID=2012127f-6c5a-4bc1-afe0-b3c9c2aada26
RAILWAY_TOKEN=***

Error output:

Failed to fetch: error sending request for url (https://backboard.railway-develop.com/graphql/v2)

Caused by:
    0: error sending request for url (https://backboard.railway-develop.com/graphql/v2)
    1: client error (Connect)
    2: tcp connect error
    3: Connection refused (os error 111)

Error: Process completed with exit code 1.

Has anyone encountered this issue before or knows what might be causing it? Any help would be appreciated.

Solved$10 Bounty

Pinned Solution

tnewaz84

FREE

a month ago

The cleanest fix is Option 1 — rename the variable entirely.

Your updated deploy step should look like this:

- name: 🚀 Deploy

shell: bash

run: railway up --service ${{ vars.RAILWAY_SERVICE_ID_DEV }} --environment ${{ vars.TARGET_ENVIRONMENT }}

env:

RAILWAY_TOKEN: ${{ secrets.RAILWAY_TOKEN }}

TARGET_ENVIRONMENT=development

TARGET_ENVIRONMENT=production

depending on your workflow.

A couple of important details:

--environment expects the Railway environment name, not necessarily "develop".
Most projects use:
- production
- staging
- development

If you use Option 2 (RAILWAY_ENV: ""), it works as a workaround, but it’s brittle because:

another step could still inherit the bad variable,
future Railway CLI changes could behave differently,
it creates hidden configuration debt.

So structurally:

RAILWAY_ENV → reserved/internal
TARGET_ENVIRONMENT → safe custom variable
explicit --environment flag → best practice

I hope this helps.

5 Replies

Status changed to Open Railway • about 1 month ago

brody

EMPLOYEE

a month ago

Please remove RAILWAY_ENV=develop, as that is only used internally to test the CLI against different backends. It has no use for anyone not employed at Railway.

Status changed to Awaiting User Response Railway • about 1 month ago

statgod6

HOBBY

a month ago

do not use RAILWAY_ENV as your project environment variable name. Rename it to RAILWAY_TARGET_ENV, DEPLOY_ENV, or similar

Status changed to Awaiting Railway Response Railway • about 1 month ago

Status changed to Awaiting User Response Railway • about 1 month ago

studiobo

HOBBYOP

a month ago

I have removed environment and tried still getting same error

      - name: 🚀 Deploy
        run: RAILWAY_TOKEN=${{ secrets.RAILWAY_TOKEN }} railway up --service ${{ vars.RAILWAY_SERVICE_ID_DEV }}

Attachments

image.png

Status changed to Awaiting Railway Response Railway • about 1 month ago

tnewaz84

FREE

a month ago

The cleanest fix is Option 1 — rename the variable entirely.

Your updated deploy step should look like this:

- name: 🚀 Deploy

shell: bash

run: railway up --service ${{ vars.RAILWAY_SERVICE_ID_DEV }} --environment ${{ vars.TARGET_ENVIRONMENT }}

env:

RAILWAY_TOKEN: ${{ secrets.RAILWAY_TOKEN }}

TARGET_ENVIRONMENT=development

TARGET_ENVIRONMENT=production

depending on your workflow.

A couple of important details:

--environment expects the Railway environment name, not necessarily "develop".
Most projects use:
- production
- staging
- development

If you use Option 2 (RAILWAY_ENV: ""), it works as a workaround, but it’s brittle because:

another step could still inherit the bad variable,
future Railway CLI changes could behave differently,
it creates hidden configuration debt.

So structurally:

RAILWAY_ENV → reserved/internal
TARGET_ENVIRONMENT → safe custom variable
explicit --environment flag → best practice

I hope this helps.

studiobo

HOBBYOP

15 days ago

This solution works, created a new env development and used TARGET_ENVIRONMENT.

It worked

Status changed to Solved chandrika • 15 days ago

Welcome!