Deploying a Laravel project in demo mode with Railway

▶

What is Railway and why use it with Laravel?

Railway is a platform that allows you to deploy web applications easily, without the need to manually manage servers. Its main appeal is that you can directly connect your GitHub repository and deploy your Laravel application in minutes.
In addition, it offers a free environment sufficient for testing or demos, with support for databases and environment variables.

Advantages over other services

Compared to Render, Vercel, or Heroku, Railway stands out for its intuitive interface and direct integration with GitHub. Render and Vercel often require more advanced configurations, while Railway allows you to start a full deploy with very few clicks.
For development or testing environments, Railway is ideal. In production, however, it's advisable to use more robust configurations (such as Docker, Nginx, or Apache) to ensure stability and security.

Limitations of the free environment

Railway's free plan has limits on usage hours and storage. Also, instances are suspended after inactivity, so it should not be used for client projects or critical services.

Preparing the Laravel project before deployment

Before uploading the project to Railway, make sure your local environment is clean and functional. Laravel uses two main components: the client side, managed with Vite (vite.config.js), and the server side, based on PHP.

In my case, I only used the Laravel development server as a demonstration. It's not recommended for production, but it's very useful for showing the workflow and quickly testing the deployment.

Base project structure and key files

Verify that your project includes:

• The composer.json file with updated dependencies.
• The vite.config.js file to manage frontend resources.
• The .env file correctly configured.
• The public/ directory with the resources generated by the build.

Differences between base Laravel, Livewire, and Inertia

In my tests, I noticed that base Laravel, Livewire, and Inertia require slightly different configurations.
Livewire and Inertia depend on JavaScript, so it's always necessary to run the frontend build (npm run build).
In contrast, if the project is only an API in base Laravel, this step can be omitted. Even so, I recommend running it within Railway to avoid inconsistencies.

Don't generate the build yet. We will perform that step within Railway, so that the environment compiles on the server and you don't have dependency issues.

Creating and configuring your project in Railway

Once you have the project on GitHub, log in to Railway and select the option "New Project → Deploy from GitHub repo".
If your repository is private, temporarily change it to public so that Railway can read it.

Connecting your GitHub repository to Railway

Railway will automatically detect the project type and configure a PHP environment. If it doesn't, you can define it manually from the control panel; you can see this from the Settings panel once the project is created via GitHub.

Configuring the database

In my deployments, I noticed that SQLite works locally but not within Railway. Being inside a Docker container, SQLite goes into read-only mode and generates errors when writing (for example, when saving sessions or migrations).
Therefore, I recommend using MySQL or PostgreSQL, both available in Railway with just one click. Once the database is created, copy the credentials and configure them in the .env file.

Environment variables and .env file settings

Railway allows you to define environment variables directly from its interface. Make sure to include the following:

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

If you are doing a demo or testing, you can leave APP_DEBUG=true, but never in production.

Build and deployment commands in Railway

In the Build & Deployment section, Railway executes the commands defined in your configuration.
In my case, I placed all the commands inside the deployment block (although it's not ideal, it worked well for this demonstration). The main ones are:

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

The --force parameter prevents deadlocks in migrations when redeploying. Thus, each deployment starts from a clean base.

These are the ones I am using in Deploy Command:

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

And for Start Command, we start the DEVELOPMENT server, on the host exposed in the container and the port defined by Railway in the environment variable:

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

Common errors during the build

One of the most frequent errors occurs when Node or Composer dependencies are missing. If Railway shows an error in the logs, check which command failed and execute them manually to verify.
I recommend executing the commands one by one until you find the exact point of failure.

Verifying the deployment and domain in Railway

When the deploy finishes, Railway generates an automatic URL like https://project-name.up.railway.app.
You can access it from the Network tab. If the application doesn't load, check the logs.

Configuring a custom domain

If you have your own domain, you can link it from the same tab. This option is only available on paid plans.

Best practices and warnings for production

Although php artisan serve allows you to see your application quickly, this command is designed for development.
In production, you should use servers like Nginx or Apache, or configure a Docker container with PHP-FPM.

It is also advisable to:

• Deactivate debug mode (APP_DEBUG=false).
• Use HTTPS via reverse proxy or external certificate.
• Review write permissions and logs.

Practical tips and real cases

When I did my first deploy on Railway, I had problems with SQLite and migrations. After switching to MySQL, everything worked without inconvenience.
I also noticed that running npm run build on Railway is more stable than doing it locally, as the container environment replicates the actual server.
In another project with Django, the deployment was even simpler using Uvicorn, which allowed me to compare behaviors between frameworks.

If you experience persistent errors, check the panel logs or copy the message to search for it in forums or tools like ChatGPT. Most problems are solved by adjusting dependencies or environment variables.

Conclusion

Railway is an excellent option for quickly testing or showcasing Laravel projects. Although the development environment is not ideal for production, its ease of use makes it a practical tool for demonstrations or idea validation.
If you want to use it professionally, complement it with a more robust server configuration or custom Docker containers.

Frequently Asked Questions

Can SQLite be used on Railway with Laravel?
No. Railway uses Docker containers where SQLite operates in read-only mode, so it does not allow writing data.

How to do automatic deploy from GitHub?
Railway does it automatically every time you push to the connected repository.

Is Railway suitable for production environments?
Yes, but it requires additional configuration with Nginx or Docker, especially if you are looking for stability and performance.

What commands does Laravel use in the Railway build?
composer install, npm install, npm run build, php artisan migrate --force and php artisan serve --host=0.0.0.0 --port=$PORT.