Deploy de un proyecto en Laravel modo demostración con Railway

▶

¿Qué es Railway y por qué usarlo con Laravel?

Railway es una plataforma que permite desplegar aplicaciones web de manera sencilla, sin necesidad de gestionar servidores manualmente. Su principal atractivo es que puedes conectar directamente tu repositorio de GitHub y desplegar tu aplicación Laravel en cuestión de minutos.
Además, ofrece un entorno gratuito suficiente para pruebas o demos, con soporte para bases de datos y variables de entorno.

Ventajas frente a otros servicios

Comparado con Render, Vercel o Heroku, Railway destaca por su interfaz intuitiva y su integración directa con GitHub. Render y Vercel suelen requerir configuraciones más avanzadas, mientras que Railway permite iniciar un deploy completo con muy pocos clics.
Para entornos de desarrollo o pruebas, Railway es ideal. En producción, sin embargo, conviene usar configuraciones más robustas (como Docker, Nginx o Apache) para garantizar estabilidad y seguridad.

Limitaciones del entorno gratuito

El plan gratuito de Railway tiene límites de horas de uso y almacenamiento. Además, las instancias se suspenden tras inactividad, por lo que no conviene usarlo para proyectos de clientes o servicios críticos.

Preparación del proyecto Laravel antes del deploy

Antes de subir el proyecto a Railway, asegúrate de que tu entorno local está limpio y funcional. Laravel utiliza dos componentes principales: la parte del cliente, gestionada con Vite (vite.config.js), y la parte del servidor, basada en PHP.

En mi caso, he utilizado el servidor de desarrollo de Laravel solo como demostración. No es recomendable para producción, pero resulta muy útil para mostrar el flujo de trabajo y probar rápidamente el despliegue.

Estructura base del proyecto y archivos clave

Verifica que tu proyecto incluya:

• El archivo composer.json con las dependencias actualizadas.
• El archivo vite.config.js para gestionar los recursos frontend.
• El archivo .env correctamente configurado.
• El directorio public/ con los recursos generados por el build.

Diferencias entre Laravel base, Livewire e Inertia

En mis pruebas noté que Laravel base, Livewire e Inertia requieren configuraciones ligeramente distintas.
Livewire e Inertia dependen de JavaScript, por lo que siempre es necesario ejecutar el build del frontend (npm run build).
En cambio, si el proyecto es solo una API en Laravel base, este paso puede omitirse. Aun así, recomiendo ejecutarlo dentro de Railway para evitar inconsistencias.

No generes el build todavía. Ese paso lo realizaremos dentro de Railway, para que el entorno se compile en el servidor y no tengas problemas de dependencias.

Crear y configurar tu proyecto en Railway

Una vez que tengas el proyecto en GitHub, inicia sesión en Railway y selecciona la opción “New Project → Deploy from GitHub repo”.
Si tu repositorio es privado, cámbialo a público temporalmente para que Railway pueda leerlo.

Conectar tu repositorio de GitHub a Railway

Railway detectará automáticamente el tipo de proyecto y configurará un entorno PHP. Si no lo hace, puedes definirlo manualmente desde el panel de control, esto lo puedes ver desde el panel de Settings una vez creado el proyecto mediante GitHub.

Configurar la base de datos

En mis despliegues noté que SQLite funciona localmente, pero no dentro de Railway. Al estar dentro de un contenedor Docker, SQLite pasa a modo de solo lectura y genera errores al escribir (por ejemplo, al guardar sesiones o migraciones).
Por eso, te recomiendo usar MySQL o PostgreSQL, ambas disponibles en Railway con solo un clic. Una vez creada la base de datos, copia las credenciales y configúralas en el archivo .env.

Variables de entorno y ajustes del archivo .env

Railway permite definir variables de entorno directamente desde su interfaz. Asegúrate de incluir las siguientes:

APP_KEY=...
APP_ENV=production
APP_DEBUG=false
DB_CONNECTION=mysql
DB_HOST=containers-us-west-12.railway.app
DB_PORT=XXXX
DB_DATABASE=railway
DB_USERNAME=usuario
DB_PASSWORD=contraseña

Si estás haciendo una demo o pruebas, puedes dejar APP_DEBUG=true, pero nunca en producción.

Comandos de build y despliegue en Railway

En la sección Build & Deployment, Railway ejecuta los comandos definidos en tu configuración.
En mi caso, coloqué todos los comandos dentro del bloque de deployment (aunque no es lo ideal, funcionó bien para esta demostración). Los principales son:

composer install
npm install
npm run build
php artisan migrate --force
php artisan db:seed --force
php artisan serve --host=0.0.0.0 --port=$PORT

El parámetro --force evita bloqueos en las migraciones al redeployar. Así, cada despliegue parte de una base limpia.

Estos son los que estoy empleando en Deploy Command:

composer install && npm install && npm run build && php artisan migrate --force && php artisan db:seed --force

Y para Start Command iniciamos el servidor de DESARROLLO, en el host expuesto en el contenedor y el puerto definido por Railway en la variable de entorno:

php artisan serve --host=0.0.0.0 --port=$PORT

Errores comunes durante el build

Uno de los errores más frecuentes ocurre cuando faltan dependencias de Node o Composer. Si Railway muestra un error en los logs, revisa cuál de los comandos falló y ejecútalos manualmente para verificar.
Recomiendo ejecutar los comandos de uno en uno hasta encontrar el punto exacto de fallo.

Verificar el despliegue y dominio en Railway

Cuando el deploy finaliza, Railway genera una URL automática como https://nombre-proyecto.up.railway.app.
Puedes acceder a ella desde la pestaña Network. Si la aplicación no carga, revisa los logs.

Configurar un dominio personalizado

Si cuentas con un dominio propio, puedes vincularlo desde la misma pestaña. Esta opción solo está disponible en los planes de pago.

Buenas prácticas y advertencias para producción

Aunque php artisan serve permite ver tu aplicación rápidamente, este comando está diseñado para desarrollo.
En producción, deberías usar servidores como Nginx o Apache, o configurar un contenedor Docker con PHP-FPM.

También conviene:

• Desactivar el modo debug (APP_DEBUG=false).
• Usar HTTPS mediante proxy inverso o certificado externo.
• Revisar los permisos de escritura y logs.

Consejos prácticos y casos reales

Cuando hice mi primer deploy en Railway, tuve problemas con SQLite y las migraciones. Después de cambiar a MySQL, todo funcionó sin inconvenientes.
También noté que es más estable ejecutar npm run build en Railway que hacerlo localmente, ya que el entorno del contenedor replica el servidor real.
En otro proyecto con Django, el despliegue fue aún más simple usando Uvicorn, lo que me permitió comparar comportamientos entre frameworks.

Si experimentas errores persistentes, revisa los logs del panel o copia el mensaje para buscarlo en foros o herramientas como ChatGPT. La mayoría de los problemas se resuelven ajustando dependencias o variables de entorno.

Conclusión

Railway es una excelente opción para probar o mostrar proyectos Laravel rápidamente. Aunque el entorno de desarrollo no es ideal para producción, su facilidad de uso lo convierte en una herramienta práctica para demostraciones o validación de ideas.
Si quieres usarlo profesionalmente, complementa con una configuración de servidor más robusta o contenedores Docker personalizados.

Preguntas frecuentes

¿Se puede usar SQLite en Railway con Laravel?
No. Railway usa contenedores Docker donde SQLite opera en modo solo lectura, por lo que no permite escribir datos.

¿Cómo hacer deploy automático desde GitHub?
Railway lo hace de forma automática cada vez que haces push al repositorio conectado.

¿Railway sirve para entornos de producción?
Sí, pero requiere configuración adicional con Nginx o Docker, especialmente si buscas estabilidad y rendimiento.

¿Qué comandos usa Laravel en el build de Railway?
composer install, npm install, npm run build, php artisan migrate --force y php artisan serve --host=0.0.0.0 --port=$PORT.