Today, the Django backend went live. Real URL, real PostgreSQL database, real API responses. Everything that was only accessible at localhost:8000 is now on the internet. It took longer than expected, it always does, but by the end of today, every endpoint was tested and working against the live Railway URL.
Why Railway
Railway is the simplest Django deployment option available right now. It handles the server infrastructure, lets you provision a PostgreSQL database with one click, reads your environment variables from a dashboard, and deploys directly from GitHub. No Dockerfile needed, no Nginx configuration, no server management. For a portfolio project this size, it's the right tool.
The free tier has usage limits, but it is more than enough for demonstrating a project. If DevCollab ever needed to handle real traffic, the deployment would need revisiting, but for portfolio purposes, Railway is exactly what's needed.
Preparing Django for Production
Before touching Railway, the codebase needed a few changes to be production-ready.
The settings file was split into base, development, and production. Everything shared between environments lives in the base. Development has DEBUG=True, SQLite, and local CORS origins. Production has DEBUG=False, PostgreSQL via DATABASE_URL, the proper ALLOWED_HOSTS and CORS_ALLOWED_ORIGINS from environment variables, and all the security settings Django's deployment check recommends.
WhiteNoise was added to serve static files directly from Django without a separate web server. In production, Django can't serve static files itself; WhiteNoise middleware handles that job cleanly without any additional infrastructure. It sits in the middleware stack just after Django's SecurityMiddleware, and the storage backend is set to WhiteNoise's compressed manifest version, which fingerprints file names for cache busting.
A Procfile was added to tell Railway what command to run to start the server. It runs gunicorn, a production WSGI server that handles concurrent requests properly, unlike Django's built-in development server, which should never be used in production.
gunicorn and whitenoise were both added to requirements.txt.
python-decouple already handled all the sensitive configuration, so no hardcoded secrets needed to be removed; they were already in .env, which is in .gitignore.
The Railway Setup
The Railway deployment process has a specific order that matters.
The PostgreSQL database gets provisioned first, before the Django service, because Django needs the DATABASE_URL environment variable to exist before it can run migrations. Railway generates this URL automatically when you create a PostgreSQL instance, and it appears in the database's variables tab, ready to copy into the Django service's environment.
The Django service is connected to the GitHub repository. Railway detects the Procfile and uses it as the start command. The build command runs pip install -r requirements.txt and python manage.py collectstatic --noinput automatically.
All environment variables are added in Railway's dashboard: SECRET_KEY, DATABASE_URL copied from the PostgreSQL instance, DEBUG=False, ALLOWED_HOSTS set to the Railway-generated domain, CORS_ALLOWED_ORIGINS set to a placeholder for now since the Vercel URL isn't known yet, and DJANGO_SETTINGS_MODULE pointing to the production settings file.
The first deploy takes a few minutes. Railway shows the build logs in real time, which makes debugging straightforward when something goes wrong.
Running Migrations on Production
After the first successful deploy, migrations need to be run on the production database. Railway provides a way to run one-off commands directly from the dashboard, the equivalent of python manage.py migrate but running against the live PostgreSQL database on Railway's servers.
This is also where a superuser gets created for the production admin panel. The admin panel isn't for public use, but it's useful for inspecting data and managing the database without writing raw SQL.
What Broke and How It Was Fixed
Three things broke during deployment.
The first was a missing DJANGO_SETTINGS_MODULE environment variable. Railway was using Django's default settings discovery, which found the base settings file instead of production. The settings module path wasn't being passed correctly. Explicitly setting DJANGO_SETTINGS_MODULE=devcollab.settings.production in Railway's environment variables fixed it immediately.
The second was ALLOWED_HOSTS. The Railway-generated domain for the Django service looked different from what I expected; it includes a subdomain and the .railway.app suffix. The ALLOWED_HOSTS environment variable needed to include the exact domain Railway assigned, not a guess at what it would be.
The third was collectstatic failing because the STATIC_ROOT directory didn't exist. Railway's build environment doesn't pre-create directories. Adding STATIC_ROOT = BASE_DIR / 'staticfiles' to the production settings and running mkdir -p staticfiles in the build command fixed it.
Testing the Live API
With the backend deployed, the entire API was tested in Postman against the live Railway URL, not localhost. Every endpoint, in the same order as the original backend testing: register, login, token refresh, logout, profile, projects CRUD, collaboration requests.
The live URL test caught one thing that local testing had missed: media file URLs. Profile avatars uploaded locally had URLs pointing to localhost:8000/media/, fine for development. In production, the MEDIA_URL needs to point to wherever media files are actually served. For now, media files are stored on Railway's filesystem, which gets wiped on each deploy. This is a known limitation: a proper production app would use something like AWS S3 or Cloudinary. For portfolio demonstration purposes, it's acceptable, and the profile still works if no avatar is uploaded.
Everything else passed. Authentication, project CRUD with permissions enforced correctly, collaboration requests with the right 400 and 403 responses on invalid operations. The live API behaves identically to the local one.
Where Things Stand After Day 97
The Django backend is live on Railway. PostgreSQL is running. All migrations are applied. Every endpoint is tested and working. The live URL is ready for the Next.js frontend to connect to.
Thanks for reading. Feel free to share your thoughts!