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