---
title: 'Video 9gEsqgO05ZE'
source: 'https://youtube.com/watch?v=9gEsqgO05ZE'
video_id: '9gEsqgO05ZE'
date: 2026-06-14
duration_sec: 0
---

# Video 9gEsqgO05ZE

> Source: [Video 9gEsqgO05ZE](https://youtube.com/watch?v=9gEsqgO05ZE)

## Summary

This video covers 10 common mistakes developers make when deploying Laravel projects to production, based on the creator's personal experience and observations from forums and comments. It aims to help viewers avoid panic-inducing issues by highlighting pitfalls like not testing fresh installations, misconfiguring environment files, and forgetting to update URLs or server settings.

### Key Points

- **Not Testing Fresh Installation** [0:28] — Developers often skip simulating a fresh deployment in a new environment, leading to issues like broken migrations, missing seeders, or incompatible database drivers.
- **Improper .env File Configuration** [2:30] — Key settings like APP_ENV and APP_DEBUG must be set correctly: APP_DEBUG should be false on production to avoid exposing sensitive data, and APP_ENV should be production.
- **Pushing .env to GitHub** [3:34] — Never commit the actual .env file to version control; only .env.example should be shared, with empty values for reference.
- **Forgetting to Update APP_URL** [4:02] — Leaving APP_URL as localhost causes file uploads and other URL-dependent features to break on production. Also ensure HTTPS is used after SSL installation.
- **Not Double-Checking All .env Values** [5:41] — Verify database credentials, session driver, queue connection, mail driver, and file system disk. Test queues specifically as they often misconfigure.
- **Ignoring Third-Party Credentials** [7:07] — Ensure API keys for services like Stripe, Postmark, or Mailgun are set correctly in production, along with webhook URLs and social login redirects.
- **Version Mismatches** [7:58] — PHP, MySQL, and Node.js versions should match between local and production environments to avoid syntax or compatibility issues.
- **Leaving CDN Links in Production** [8:36] — CDN-based libraries like Tailwind or AlpineJS should be properly installed via npm for production, not left as CDN scripts.
- **Not Tuning PHP/Web Server Settings** [9:39] — Adjust upload_max_filesize, post_max_size, and client_max_body_size for file uploads, and ensure other PHP/nginx settings match local configuration.

### Conclusion

By avoiding these common mistakes—like testing fresh installations, correctly configuring .env files, and matching server versions—developers can achieve smoother Laravel deployments. Always double-check settings and test thoroughly before going live.

## Transcript

Hello guys, in this video let's talk
about deployment of Laravel projects and
many mistakes that I've seen developers
make when doing that. I've made a list
of at least 10 typical mistakes that
I've done in the past or I've seen
others doing because deployment to life
may be tricky. You often forget
something. Then you realize that you
forgot something only when the project
is live and then the panic mode begins.
So I hope this video will help you to
avoid such situations. Let's begin. So
the first mistake developers do before
launching project to production is they
don't test it fresh. They don't rehearse
the deployment. So what often happens is
developers work on the project and the
project is in certain stage with already
existing data locally installed packages
and everything but quite rarely
developers try to install it fresh in a
new folder on a new server in a new
environment. So this is what you need to
do to kind of simulate what it would be
to deploy to live server. And here's a
demo project, one of the projects on
Laravel Daily. And according to the
instructions, you should run the
installation fresh. So this is exactly
what it will do. Get clone in a new
empty folder and then copy.v.example
and then fill in the credentials for
database and other stuff. And we'll talk
about those in a minute in this video.
But basically you need to run the whole
installation process. Run composer
install artis migrate and all of that
because the underlying mistakes of how
the projects are structured is for
example migrations may not work because
at some point there were manual changes
to the database and everyone forgot
about that. Maybe there are cedars
missing which are required for deploying
to production. some default users,
default roles, default categories,
whatever. Maybe those are missing
because they were added again manually
to the database locally. Also,
migrations may not work because of
different database drivers. So, maybe
locally you worked with SQLite and you
want to deploy to MySQL. Maybe some
packages are abandoned or don't work
anymore and composer install would fail
for whatever reason. So, basically my
first message is ensure that the project
installation works at all. So in my case
I finished the installation with
migrations key generate npm run build
and then I launched the homepage and it
seemed to be working. This is the first
green light good sign to move forward
towards production deployment. The next
mistake when deploying to production or
in fact it will be serious of mistakes
is do not fill inv file properly on the
deployment live server. So what could be
the mistakes made here? Probably two
most important settings are app env
debug. First on production app debug
should be always false because otherwise
it would show all the debugging errors
and data and details to your live
customers including database structure,
eloquent queries, file structure, file
name. basically huge security issue and
then related to that app production will
also make sure that some local stuff
will not get shown on production for
example in Laravel eloquent there's
configuring eloquent strictness so you
can configure preventing off lazy
loading but only in your local
environment so here and there you may
see app is production manual checks or
checks inside of the framework so those
two things are non-negotiable app envug.
And actually here I will mention another
security flow. Perhaps no one does it
these days, but just in case I will
repeat. Do not push your env to GitHub
and do not make it public in whatever
form. Env.example should be in the
GitHub for other developers to see the
keys with empty values. But should be
hidden and only accessible on the server
when you SSH to the server and edit that
data manually. The next mistake is some
developers forget to update app URL. I
remember on Larcast forum there were
typical questions like why my file
upload doesn't work and of course it
doesn't work because it relies on app
URL and if you leave it local host or
whatever is your test domain then of
course it wouldn't work on the live
server. And speaking of app URLs a few
more things to not forget. If you
install SSL certificate and of course
you should do that then do not forget to
change that to HTTPS here and also in
the code before deployment double check
that you're using relative paths
everywhere. So here's my tweet pretty
recent and pretty popular with 70 likes.
So always use paths like storage path,
public path. So laravel helpers to
access some path without hard- coding
the URLs or full paths that may be
different on your local and on
production server. And also another side
note, I remember in WordPress whenever I
deploy something to live back in the day
when I used WordPress, if I mention some
image in the content, it was always with
the full URL with local host or whatever
was the URL. And I always had to deal
with updating all the URLs after
deployment. And fun fact, it did work
for me because for example, I'm on my
local host. I deploy, I launch the
website, it works for me with real URL
on production, but it loads the images
from my local host, which works for me.
And then other developers or other users
report that the images aren't loading or
something. So yeah, kind of a side note,
always ask someone else to check the
website if it works for them. And of
course, run automated tests if you have
them. So that's with the URLs. Next
topic or the next kind of set of
mistakes is basically forgetting to
doublech checkck pretty much all the
values in NV file. Probably the most
crucial ones I will mention is of course
database credentials and of course it
should be the same database as I
mentioned already. If you used SQLite in
the process of development, double check
with MySQL local before running on MySQL
on production. So it should be the same
database driver. And speaking of
drivers, double check which drivers you
want to use for sessions. Q connection
file system disk mail driver or it's
called mail mailer. So basically make
your choices for production which may be
different from your local. So for
example locally you may run it without
cues with Q connection sync and then for
production you may want to use database
driver or reddis or something else. And
with Q's, my advice would be to
specifically take the time to test if
the cues work after the deployment.
Because with QES, there are many things
that can go wrong. It may be
misconfigured. It may be not launched on
the server. You need to configure
supervisor if you want it to run
automatically. And that's why I love
tools like Laravel Forge because they do
that automatically for me. And I don't
need to SSH to the server to do that
manually. But yes, specifically with
Q's. Time and time again, I see issues
that Q is not working, not restarted or
something similar. The next mistake is
not checking the third-party
credentials. So this is all in config
services of Laravel usually and this is
a demo from another project. So if you
use any service providers like email,
postmark or mail gun, they should be
here also stripe keys and whatever other
API keys locally they are probably
different and you need to make sure that
production keys are invroduction
and that's why it's beneficial to have
as I mentioned.
For yourself and other developers so you
would know what keys do you need
specifically and what are their key
names. And this tip also includes not
only API keys but any URLs for web hooks
or social URLs after login. They often
also are provided invig.
So double check those. The next mistake
which I probably should have mentioned
earlier is while preparing the server
for deployment double check the versions
of the software. So PHP version and
MySQL version or whatever other database
you use also NodeJS version. Here I'm
showing Laravel Forge. What it's like to
create a server via Laravel Forge so you
can choose the versions pretty easily.
But that's not the point. The point is
that the versions should be identical
locally and on production because there
may be unpleasant surprises if the
production server is older or newer and
some syntax in your code that worked
locally would not work on production.
The next mistake is leaving CDNs after
deploying to production. For example,
Tailwind locally. You may have worked
with this. So, one of the installation
ways is play CDN. So, you just do script
and load the Tailwind from CDN and that
works locally. But after deployment, you
may forget to change that to proper
installation with npm. Here's an example
using Vit or in the latest Laravel 12,
it comes already pre-installed with
Tailwind 4 and preconfigured. Or another
example of CDN based usage often is
AlpineJS. So even on their homepage of
AlpineJS, they suggest to just load it
from CDN and there you go. And you may
still do that in production for
AlpineJS. But maybe a more proper way
for all the JS library is to use proper
npm install and have it in package JSON.
And the same goes for any JS or CSS
scripts that you use. Just double check
that you don't leave CDNs if you prefer
to install them properly with npm on
production. And the final mistake in
this video, there may be more and we can
discuss in the comments if I miss
something, but some developers forget to
tweak their PHP or web server settings
for production usage. So here's an
article, a very old article on Laravel
Daily from 2018. Then it was updated to
2022, but the message is the same. A
typical practical example is file
validation. So if you work with bigger
files, you need to put the validation
rules in a few places. So first
validation is on Laravel level in form
request or whatever. Then you have PHP
settings which are these upload max file
size and post max size in general. So
you need to bump them up for bigger
files and also in engineext or Apache
whatever web server you use probably
enginex at this point in most cases.
There's also client max body size
setting that you may want to tweak. And
this is just one example, but in
general, make sure that your PHP and web
server settings are ideally identical to
your local ones or otherwise make
necessary changes. So yeah, these are
the mistakes when deploying to
production that I've made personally in
the past or I've seen others did it
based on the questions that I saw on
forums or in my YouTube comments or on
Twitter or elsewhere. What do you think
about this list? Have you done anything
like that yourself? Any of those
mistakes? Share your stories and what
other mistakes developers should avoid
when deploying their Laravel projects to
live servers. Let's discuss everything
in the comments. That's it for this time
and see you guys in other