How to deploy Django and PostgreSQL on Railway: practical guide

Published on 2026-10-26 by frfrand

A human guide to publishing Django with PostgreSQL on Railway, reviewing common failures, and understanding how to do it also on a VPS with ArduMaker.

You have a Django project, it works perfectly on localhost and now you want someone else to use it. Railway is one of the options to publish it without having to install and configure a Linux server manually. The detail that often surprises is that publishing the code is not enough: you also need PostgreSQL, variables, migrations, and a way to find errors.

Let's go with a concrete case: a reservation application made in Django, with users, appointments, and notifications. The idea is to understand the real path, not to make a demo that works for five minutes and then breaks.

Before uploading anything

Your project should run local tests correctly and have dependencies declared. If you use PostgreSQL, install a driver compatible with the Django version, such as psycopg. To serve Django in production, you can use Gunicorn, and for static files review a configuration like WhiteNoise or a specialized server. Do not confuse project static files with photos uploaded by users: the latter need persistent storage.

In settings.py review three things: DEBUG=False in production, ALLOWED_HOSTS with the correct domains and a SECRET_KEY that comes from an environment variable, never from the repository. Keep a requirements.txt or an equivalent dependencies file.

Step 1. Connect the GitHub repository to Railway

Create a project in Railway, choose to deploy from GitHub and select the Django repository. Railway also supports CLI and templates, but GitHub is practical if you want it to be clear which commit corresponds to each deployment.

If the build fails, do not modify five things at once. Look in the logs for the first dependency that could not be installed. Also confirm the Python version your project needs.

Step 2. Add PostgreSQL

From the same project, add the PostgreSQL service. Railway exposes connection variables that you can reference from the web service. Depending on how your Django is configured, you will use a DATABASE_URL interpreted by the application or separate variables, such as PGHOST, PGPORT, PGDATABASE, PGUSER and PGPASSWORD.

An example of explicit configuration is:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["PGDATABASE"],
        "USER": os.environ["PGUSER"],
        "PASSWORD": os.environ["PGPASSWORD"],
        "HOST": os.environ["PGHOST"],
        "PORT": os.environ.get("PGPORT", "5432"),
    }
}

It is important that the API connects to the correct service and that PostgreSQL is not left unnecessarily open to the public. Do not copy real credentials into screenshots or tutorials.

Step 3. Choose how to start the application

For a traditional project, a start command can be:

gunicorn config.wsgi:application --bind 0.0.0.0:$PORT

Change config to the real name of your Django module. Railway assigns the port via the environment, so it is not advisable to hardcode a fixed one. If you use ASGI, WebSockets or another architecture, the appropriate process may be different.

Run the Django migrations using a controlled procedure, for example python manage.py migrate, before considering an update incompatible with the previous schema as complete. Also review collectstatic when appropriate.

Step 4. Publish the domain and test something real

In the web service network configuration you can generate a public domain or link your own. Verify HTTPS, log in with a test user and create a reservation. Restart the service and verify that the reservation continues in PostgreSQL. If it disappears, you were probably saving data in the wrong place.

Then test a controlled failure: where do you see the error? Can you recognize which version was published? Do you know how to revert to the previous one? Those three questions differentiate a demo from a deployment you can maintain.

What if the application has Celery, Redis and scheduled tasks?

Then we are no longer talking only about Django and a database. A web API must respond quickly; emails, reports and long tasks can go to Celery workers, with a broker like Redis when your architecture requires it. In Railway you can distribute those processes among independent services and configure their variables, startup and consumption.

That is why comparing the web service price is not enough. You have to look at the entire application, including storage, workers, databases, traffic and backups.

How I would do the same project with ArduMaker

ArduMaker's approach is different: you create a VPS, link the GitHub repository to deploy Django, configure PostgreSQL, and run the application as a service. You can place Nginx in front of Gunicorn, associate a domain with HTTPS, and manage workers as separate processes.

For a reservation system with FastAPI or Django, PostgreSQL, Redis, and Celery, having these components within a VPS can simplify operational control: you see the server, its processes, and its resources from the same environment. You also have to take care of sizing it, updating it, and testing backups. It is not a magic shortcut.

If you want to delegate administration and your software fits the managed model, Railway makes a lot of sense. If you need to configure system services, combine several pieces on one server, or work with MCP tools, it is worth comparing ArduMaker.

Three mistakes I would avoid from day one

First: publishing Django with DEBUG=True or secrets in Git. Second: believing that a file written inside the running container will survive any recreation. Third: leaving migrations, backups, and workers "for later." In an application with customer data, that later arrives quickly.

To continue researching

Read the official Django guide on Railway, our article on what is Railway and the detailed comparison of Railway with ArduMaker. Plans and limits change: check their current terms before migrating an application.

In one sentence: publishing Django is easy to demonstrate; leaving it ready for real users implies thinking about data, processes, security, and recovery. Choose the platform that helps you sustain those four things.