Hi there, quick suggestion, could you try to use Railpack as a builder? https://railpack.com/languages/python/#django

Hi - we (Claude and I) tried, but are running into some problems. After deploying with Railpack we get an error. here is the description:

Railway Deployment Issue Summary

Project Overview

• Project Structure: A Django application in a directory named TetraltoDjango (recently renamed from liftoff)

• Project Structure Type: The Django app has nested directories (TetraltoDjango/liftoff/)

• Deployment Method: Using Railway with Nixpacks builder (default) and Railpack builder (causing issues)

Steps Taken and Results

1. Initial Deployment with Directory Rename

• Renamed liftoff directory to TetraltoDjango for better organization

• Ran railway link to reconnect the project to the new directory

• Deployed using railway up without any custom configuration files

• Result: Deployment successful with Railway's default Nixpacks builder

1. Adding Railpack Configuration

• Created explicit configuration files:

• railpack.yaml: Defined Python version, environment variables including RAILPACK_DJANGO_APP_NAME, explicit build and deploy steps

• railway.json: Changed builder from default Nixpacks to Railpack

• .python-version: Set Python version to 3.12.0

• Result: Deployment failed with /bin/sh: 1: manage.py: not found error

1. Environment Variables

• Added RAILPACK_DJANGO_APP_NAME: liftoff.wsgi at the service level in Railway dashboard

• Result: Same error persisted

Current Error

/bin/sh: 1: manage.py: not found

Technical Details

• Project Structure:

    TetraltoRail/

    └── TetraltoDjango/

        ├── manage.py

        ├── requirements.txt

        ├── liftoff/          # Django settings directory

        │   ├── settings.py

        │   ├── wsgi.py

        │   └── ...

        ├── core/             # Django app

        └── ...

• Railpack Configuration (railpack.yaml):

    build:

      python:

        version: "3.12"

    environment:

      PYTHONUNBUFFERED: "1"

      PYTHONDONTWRITEBYTECODE: "1"

      RAILPACK_DJANGO_APP_NAME: "liftoff.wsgi"

      PORT: "8000"

    steps:

      - name: "install"

        command: "pip install -r requirements.txt"

      - name: "collectstatic"

        command: "python manage.py collectstatic --noinput"

        runInDeploy: true

      - name: "migrate"

        command: "python manage.py migrate"

        runInDeploy: true

      - name: "start"

        command: "gunicorn liftoff.wsgi:application"

        runInDeploy: true

Key Observations

1. The application deploys successfully with Railway's default Nixpacks builder

1. The error only occurs when switching to the Railpack builder

1. Despite specifying RAILPACK_DJANGO_APP_NAME both in railpack.yaml and as a service environment variable, Railpack is unable to locate the manage.py file

1. The error suggests Railpack is looking for manage.py in the wrong directory, potentially at the root of the deployed container rather than in the correct application directory

Questions for Support

1. Why does Railpack fail to find manage.py when Nixpacks succeeds with the same directory structure?

1. What additional configuration is needed for Railpack to properly handle Django applications with this directory structure?

1. Is there a way to specify the working directory for commands in Railpack deployments?

1. Are there any known limitations or differences in how Railpack handles file paths compared to Nixpacks?

Hey there, could you please check the Railpack docs for deploying Django? https://railpack.com/languages/python/#django

I did - I don't see what we did wrong.

Here's the build log:
Mar 31 22:51:34

[Region: us-west1]

Mar 31 22:51:34

Mar 31 22:51:34

╭─────────────────╮

Mar 31 22:51:34

│ Railpack 0.0.60 │

Mar 31 22:51:34

╰─────────────────╯

Mar 31 22:51:34

Mar 31 22:51:34

↳ Detected Python

Mar 31 22:51:34

↳ Using pip

Mar 31 22:51:34

↳ Using Django app: liftoff.wsgi

Mar 31 22:51:34

Mar 31 22:51:34

Packages

Mar 31 22:51:34

──────────

Mar 31 22:51:34

python │ 3.12.0 │ .python-version (3.12.0)

Mar 31 22:51:34

Mar 31 22:51:34

Steps

Mar 31 22:51:34

──────────

Mar 31 22:51:34

▸ install

Mar 31 22:51:34

$ python -m venv /app/.venv

Mar 31 22:51:34

$ pip install -r requirements.txt

Mar 31 22:51:34

Mar 31 22:51:34

Deploy

Mar 31 22:51:34

──────────

Mar 31 22:51:34

$ python manage.py migrate && gunicorn liftoff.wsgi:application

Mar 31 22:51:34

Mar 31 22:51:34

Mar 31 22:51:34

Successfully prepared Railpack plan for build

Mar 31 22:51:34

Mar 31 22:51:34

Mar 31 22:51:34

context: mkpk-KSE2

Mar 31 22:51:34

[internal] load build definition from railpack-plan.json

0s

Mar 31 22:51:34

resolve image config for docker-image://ghcr.io/railwayapp/railpack-frontend:v0.0.60

0s

Mar 31 22:51:35

docker-image://ghcr.io/railwayapp/railpack-frontend:v0.0.60@sha256:d5ae4bf44d7e141e17d4cd902a9aa546a96a246f7b78a240f844a0f02ee99934

Cached

Mar 31 22:51:35

load build definition from railpack-plan.json

0s

Mar 31 22:51:35

docker-image://ghcr.io/railwayapp/railpack-builder:latest

0s

Mar 31 22:51:35

docker-image://ghcr.io/railwayapp/railpack-runtime:latest

0s

Mar 31 22:51:35

loading .

0s

Mar 31 22:51:36

install apt packages: libpq5

Cached

Mar 31 22:51:36

install apt packages: libpq-dev python3-dev

Cached

Mar 31 22:51:36

copy .python-version

Cached

Mar 31 22:51:36

mkdir /etc/mise

Cached

Mar 31 22:51:36

create mise config

Cached

Mar 31 22:51:36

install mise packages: python

Cached

Mar 31 22:51:36

copy /mise/shims, /mise/installs, /usr/local/bin/mise, /etc/mise/config.toml, /root/.local/state/mise, /app/.python-version

Cached

Mar 31 22:51:36

python -m venv /app/.venv

Cached

Mar 31 22:51:36

copy requirements.txt

Cached

Mar 31 22:51:36

pip install -r requirements.txt

Cached

Mar 31 22:51:36

copy ., /app/.venv, /app

Cached

Mar 31 22:51:36

[railpack] merge $packages:python-runtime-deps, $packages:mise, $build, $build

Cached

Mar 31 22:51:36

[auth] sharing credentials for us-west1.registry.rlwy.net

0s

Mar 31 22:51:37

Build time: 2.92 seconds

Any help here?

1. Both our project and the Django service have the identical name: "TetraltoProject". Could this naming collision might be contributing to the issue with SSH connectivity?

Could you try renaming one of them? This is likely it

it wasn't that, but I found the problem: Basically, my pre-deploy command was not compatible with Railpack
Subject: Issue Resolved - SSH Working with Railpack after Removing Pre-Deploy Command

Hello Railway Support Team,

I wanted to provide an update on my previous ticket regarding SSH connectivity issues with my Django application.

After following your suggestion to switch from Nixpacks to Railpack, I've successfully resolved both my deployment and SSH access issues. Here's what worked:

1. Main issue identified: The pre-deploy command (manage.py loaddata data.json --exclude core.lead) was failing because it was being executed before the Python environment was fully set up by Railpack.

1. Solution implemented:

• Switched from Nixpacks to Railpack using railway.json configuration

• Created a minimal railpack.yaml file with just essential settings

• Removed the pre-deploy command that was causing failures

• Kept the Root Directory setting as "/"

1. Results:

• The application now deploys successfully

• SSH connectivity works perfectly - I can connect to the container and see all my files

• The application is running correctly with Gunicorn

This confirms that Railpack does indeed provide better SSH support compared to Nixpacks, as you suggested. The key insight was understanding that the pre-deploy command runs in a context where the Python environment isn't yet fully configured (I think), making Django commands fail at that stage.

For anyone else experiencing similar issues, I recommend checking if pre-deploy commands are compatible with Railpack's deployment process, and using SSH to debug deployment environments once connectivity is established.

Thank you for your assistance in resolving this issue!

I decided to revert to pre-Railpack because I had mucked up the code so much. In doing so, I found that ssh works now. SO, the issue was most likely the project and service name collision, but since we never deployed successfully after changing that (due to Railpack and pre-deploy command incompatibility), the change hadn't really been deployed. So - SSH is affected by the name collision, and pre-deploy commands are not compatible with railpack.

Thank you for the report, we appreciate it!