Cómo desplegar Django y PostgreSQL en Railway: guía práctica

Publicado el 2026-10-26 por frfrand

Una guía humana para publicar Django con PostgreSQL en Railway, revisar los fallos habituales y entender cómo hacerlo también en un VPS con ArduMaker.

Tenés un proyecto Django, anda perfecto en localhost y ahora querés que lo use alguien más. Railway es una de las opciones para publicarlo sin tener que instalar y configurar un servidor Linux a mano. El detalle que suele sorprender es que publicar el código no alcanza: también necesitás PostgreSQL, variables, migraciones y una forma de encontrar errores.

Vamos con un caso concreto: una aplicación de reservas hecha en Django, con usuarios, turnos y notificaciones. La idea es entender el camino real, no hacer una demo que funciona cinco minutos y luego se rompe.

Antes de subir nada

Tu proyecto debería ejecutar correctamente las pruebas locales y tener dependencias declaradas. Si usás PostgreSQL, instalá un driver compatible con la versión de Django, como psycopg. Para servir Django en producción, podés utilizar Gunicorn, y para los archivos estáticos revisar una configuración como WhiteNoise o un servidor especializado. No confundas archivos estáticos del proyecto con fotos subidas por usuarios: estas últimas necesitan almacenamiento persistente.

En settings.py revisá tres cosas: DEBUG=False en producción, ALLOWED_HOSTS con los dominios correctos y una SECRET_KEY que venga de una variable de entorno, nunca del repositorio. Conservá un requirements.txt o un archivo de dependencias equivalente.

Paso 1. Conectá el repositorio GitHub a Railway

Creá un proyecto en Railway, elegí desplegar desde GitHub y seleccioná el repositorio de Django. Railway admite también CLI y plantillas, pero GitHub es práctico si querés que quede claro qué commit corresponde a cada despliegue.

Si el build falla, no modifiques cinco cosas a la vez. Buscá en los logs la primera dependencia que no se pudo instalar. Confirmá también la versión de Python que necesita tu proyecto.

Paso 2. Añadí PostgreSQL

Desde el mismo proyecto agregá el servicio PostgreSQL. Railway expone variables de conexión que podés referenciar desde el servicio web. Según cómo esté configurado tu Django, utilizarás una DATABASE_URL interpretada por la aplicación o variables separadas, como PGHOST, PGPORT, PGDATABASE, PGUSER y PGPASSWORD.

Un ejemplo de configuración explícita es:

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"),
    }
}

Es importante que la API se conecte al servicio correcto y que PostgreSQL no quede abierto innecesariamente al público. No copies credenciales reales a capturas o tutoriales.

Paso 3. Elegí cómo arranca la aplicación

Para un proyecto tradicional, un comando de inicio puede ser:

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

Cambiá config por el nombre real de tu módulo Django. Railway asigna el puerto mediante el entorno, por lo que no conviene codificar uno fijo. Si usás ASGI, WebSockets u otra arquitectura, el proceso adecuado puede ser diferente.

Ejecutá las migraciones de Django mediante un procedimiento controlado, por ejemplo python manage.py migrate, antes de dar por terminada una actualización incompatible con el esquema anterior. También revisá collectstatic cuando corresponda.

Paso 4. Publicá el dominio y probá algo real

En la configuración de red del servicio web podés generar un dominio público o vincular uno propio. Comprobá HTTPS, iniciá sesión con un usuario de prueba y creá una reserva. Reiniciá el servicio y verificá que la reserva continúe en PostgreSQL. Si desaparece, seguramente estabas guardando datos en un lugar equivocado.

Después probá un fallo controlado: ¿dónde ves el error? ¿Podés reconocer qué versión se publicó? ¿Sabés cómo volver a la anterior? Esas tres preguntas diferencian una demo de un despliegue que podés mantener.

¿Y si la aplicación tiene Celery, Redis y tareas programadas?

Entonces ya no hablamos sólo de Django y una base. Una API web debe responder rápido; los correos, informes y tareas extensas pueden ir a workers de Celery, con un broker como Redis cuando tu arquitectura lo requiera. En Railway podés distribuir esos procesos entre servicios independientes y configurar sus variables, arranque y consumo.

Por eso no alcanza con comparar el precio del servicio web. Hay que mirar toda la aplicación, incluido almacenamiento, workers, bases, tráfico y backups.

Cómo haría el mismo proyecto con ArduMaker

El enfoque de ArduMaker es diferente: creás un VPS, vinculás el repositorio GitHub para desplegar Django, configurás PostgreSQL y ejecutás la aplicación como servicio. Podés colocar Nginx delante de Gunicorn, asociar un dominio con HTTPS y administrar workers como procesos separados.

Para un sistema de reservas con FastAPI o Django, PostgreSQL, Redis y Celery, tener estos componentes dentro de un VPS puede simplificar el control operativo: ves el servidor, sus procesos y sus recursos desde un mismo entorno. También tenés que hacerte cargo de dimensionarlo, actualizarlo y probar las copias. No es un atajo mágico.

Si querés delegar administración y tu software encaja con el modelo gestionado, Railway tiene mucho sentido. Si necesitás configurar servicios del sistema, juntar varias piezas en un servidor o trabajar con herramientas MCP, vale la pena comparar ArduMaker.

Tres errores que evitaría desde el primer día

Primero: publicar Django con DEBUG=True o secretos en Git. Segundo: creer que un archivo escrito dentro del contenedor de ejecución sobrevivirá a cualquier recreación. Tercero: dejar las migraciones, las copias y los workers «para después». En una aplicación con datos de clientes, ese después llega rápido.

Para seguir investigando

Leé la guía oficial de Django en Railway, nuestro artículo sobre qué es Railway y la comparación detallada de Railway con ArduMaker. Los planes y límites cambian: consultá sus condiciones actuales antes de migrar una aplicación.

En una frase: publicar Django es fácil de demostrar; dejarlo listo para usuarios reales implica pensar en datos, procesos, seguridad y recuperación. Elegí la plataforma que te ayude a sostener esas cuatro cosas.