I never thought deploying a Laravel REST API with a React frontend would be this hard. The development itself wasn't the tough part. My Laravel vocabulary could use some improvement, but that only really matters if I land a project or job that uses that stack. The deployment, though, that's where things fell apart.
What went wrong
The short version: migrations, seeders, and permission errors ate two hours of my life.
I run a shared PostgreSQL instance on my homelab (same for Redis) so I don't spin up separate resources for every project. That means for this app, I had to manually create a new database and alter the table ownership just so the backend's .env could actually connect and run migrations properly. It works, but it's not elegant.
Looking back, I probably should have written a proper .sh script to handle the database and user setup instead of doing it by hand. Too late for this one, but that's going in the toolbox for next time.
The Faker problem
The other big time sink: I had used Faker in my seeders, but it was sitting in require-dev, not require. That meant every time I tried to run seeders in production, it failed. It took two rebuilds before I caught that and moved it to the right place.
Takeaways
- Shared Postgres and Redis instances save resources, but they add a manual setup step (create DB, alter ownership) that's easy to forget until deploy day.
- A reusable
.shscript for provisioning a new database and user would have saved a good chunk of that two hours. - Double check which dependencies actually need to ship to production. Faker, and anything else used only for seeding or testing, belongs in
require-devonly if your production flow never needs it. If it does, move it up.
Deployment day always finds the gaps that development day let slide. This one just found more than usual.