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

• 🧵 Dockerfile Issue

• 🧵 Environment variable seems to be cached or not updating

• 🧵 [Settings.py](Settings.py) not updating despite new deployments - Caching issue?

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

I keep getting the same issue - it retrieves a docker file that I have removed - this is a cache issue

It fails during healthcheck -You reached the start of the range

Oct 15, 2025, 4:32 PM

[Region: asia-southeast1]

=========================

Using Detected Dockerfile

=========================

context: nvj7-kIbq

internal

load build definition from Dockerfile

0ms

internal

load metadata for docker.io/library/python:3.11-slim

1s

auth

library/python:pull token for registry-1.docker.io

0ms

internal

load .dockerignore

1ms

1

FROM docker.io/library/python:3.11-slim@sha256:ff8533f48e12b705fc20d339fde2ec61d0b234dd9366bab3bc84d7b70a45c8c0

6ms

internal

load build context

1ms

2

WORKDIR /app cached

0ms

3

RUN apt-get update && apt-get install -y gcc curl && rm -rf /var/lib/apt/lists/*

9s

Processing triggers for libc-bin (2.41-12) ...

4

COPY requirements.txt .

43ms

5

RUN pip install --no-cache-dir -r requirements.txt

2m 33s

[notice] To update, run: pip install --upgrade pip

6

RUN pip install --no-cache-dir gunicorn==21.2.0 flask-limiter==3.5.0 sentry-sdk[flask]==1.40.0

2s

[notice] To update, run: pip install --upgrade pip

7

COPY . .

39ms

8

RUN useradd -m -u 1000 appuser && chown -R appuser:appuser /app

153ms

auth

sharing credentials for production-asia-southeast1-eqsg3a.railway-registry.com

0ms

Build time: 504.62 seconds

==================== Starting Healthcheck ====================

Path: /health

Retry window: 5m0s

Attempt #1 failed with service unavailable. Continuing to retry for 4m49s

Attempt #2 failed with service unavailable. Continuing to retry for 4m45s

Attempt #3 failed with service unavailable. Continuing to retry for 4m43s

Attempt #4 failed with service unavailable. Continuing to retry for 4m39s

Attempt #5 failed with service unavailable. Continuing to retry for 4m31s

Attempt #6 failed with service unavailable. Continuing to retry for 4m14s

Attempt #7 failed with service unavailable. Continuing to retry for 3m44s

Attempt #8 failed with service unavailable. Continuing to retry for 3m14s

Attempt #9 failed with service unavailable. Continuing to retry for 2m44s

Attempt #10 failed with service unavailable. Continuing to retry for 2m13s

Attempt #11 failed with service unavailable. Continuing to retry for 1m43s

Attempt #12 failed with service unavailable. Continuing to retry for 1m13s

Attempt #13 failed with service unavailable. Continuing to retry for 43s

Attempt #14 failed with service unavailable. Continuing to retry for 13s

1/1 replicas never became healthy!

Healthcheck failed!

Build LOG
Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number.

Error: '$PORT' is not a valid port number

Here is a summary

Expected vs Actual Deployment Process

Let me break down what we expected to happen versus what actually happened:

Expected Deployment Process

What We Planned:

1. Delete Dockerfile from repository

1. Create railway.toml with nixpacks builder

1. Create Procfile for auto-detection

1. Push to GitHub

1. Railway auto-detects Python and uses nixpacks

1. Railway handles PORT automatically

1. Deploy successfully with health check passing

Expected Railway Behavior:

=========================

Using Nixpacks Auto-Detection

=========================

Detected Python application

Installing dependencies...

Starting application with Procfile...

 Health check passed

 Deployment successful

Actual Deployment Process

What Actually Happened:

1. Deleted Dockerfile from repository

1. Created railway.toml with nixpacks builder

1. Created Procfile for auto-detection

1. Pushed to GitHub

1. Railway IGNORED everything and used cached Dockerfile

1. Railway used old Dockerfile with hardcoded PORT issues

1. Deployment failed with PORT errors

Actual Railway Behavior:

=========================

Using Detected Dockerfile  ← WRONG!

=========================

FROM python:3.11-slim

WORKDIR /app

RUN apt-get update...

RUN pip install...

COPY . .

RUN useradd...

CMD ["sh", "-c", "gunicorn --bind 0.0.0.0:${PORT:-5000}..."]

 Error: '$PORT' is not a valid port number

 Health check failed

 Deployment failed

The Problem: Railway's Broken Caching

What Should Have Happened:

• Railway should have detected no Dockerfile

• Railway should have used nixpacks auto-detection

• Railway should have used our Procfile

• Railway should have handled PORT automatically

What Actually Happened:

• Railway ignored the deleted Dockerfile

• Railway used a cached version from somewhere

• Railway ignored our railway.toml

• Railway ignored our Procfile

• Railway used the old Dockerfile with PORT issues

This is a Railway Platform Bug

Evidence:

1. Dockerfile deleted - but Railway still uses it

1. .dockerignore added - but Railway ignores it

1. railway.toml created - but Railway ignores it

1. New project created - but Railway still caches globally

1. Same issue reported in Railway support (resolved by environment sync)

Railway will always use a Dockerfile if there is a Dockerfile, you'll need to rename the Dockerfile or move it to somewhere that isnt root if you dont want Railway to use the Dockerfile, or alternatively just delete it