Video 9gEsqgO05ZE

[00:00] Hello guys, in this video let's talk

[00:01] about deployment of Laravel projects and

[00:04] many mistakes that I've seen developers

[00:06] make when doing that. I've made a list

[00:08] of at least 10 typical mistakes that

[00:11] I've done in the past or I've seen

[00:13] others doing because deployment to life

[00:15] may be tricky. You often forget

[00:17] something. Then you realize that you

[00:19] forgot something only when the project

[00:21] is live and then the panic mode begins.

[00:24] So I hope this video will help you to

[00:26] avoid such situations. Let's begin. So

[00:28] the first mistake developers do before

[00:31] launching project to production is they

[00:33] don't test it fresh. They don't rehearse

[00:36] the deployment. So what often happens is

[00:39] developers work on the project and the

[00:41] project is in certain stage with already

[00:43] existing data locally installed packages

[00:46] and everything but quite rarely

[00:48] developers try to install it fresh in a

[00:50] new folder on a new server in a new

[00:53] environment. So this is what you need to

[00:55] do to kind of simulate what it would be

[00:58] to deploy to live server. And here's a

[01:01] demo project, one of the projects on

[01:03] Laravel Daily. And according to the

[01:05] instructions, you should run the

[01:07] installation fresh. So this is exactly

[01:09] what it will do. Get clone in a new

[01:11] empty folder and then copy.v.example

[01:15] and then fill in the credentials for

[01:17] database and other stuff. And we'll talk

[01:19] about those in a minute in this video.

[01:22] But basically you need to run the whole

[01:23] installation process. Run composer

[01:25] install artis migrate and all of that

[01:28] because the underlying mistakes of how

[01:31] the projects are structured is for

[01:34] example migrations may not work because

[01:36] at some point there were manual changes

[01:38] to the database and everyone forgot

[01:41] about that. Maybe there are cedars

[01:43] missing which are required for deploying

[01:46] to production. some default users,

[01:48] default roles, default categories,

[01:50] whatever. Maybe those are missing

[01:52] because they were added again manually

[01:54] to the database locally. Also,

[01:56] migrations may not work because of

[01:57] different database drivers. So, maybe

[01:59] locally you worked with SQLite and you

[02:02] want to deploy to MySQL. Maybe some

[02:04] packages are abandoned or don't work

[02:07] anymore and composer install would fail

[02:09] for whatever reason. So, basically my

[02:11] first message is ensure that the project

[02:13] installation works at all. So in my case

[02:16] I finished the installation with

[02:17] migrations key generate npm run build

[02:20] and then I launched the homepage and it

[02:23] seemed to be working. This is the first

[02:25] green light good sign to move forward

[02:28] towards production deployment. The next

[02:30] mistake when deploying to production or

[02:32] in fact it will be serious of mistakes

[02:34] is do not fill inv file properly on the

[02:38] deployment live server. So what could be

[02:41] the mistakes made here? Probably two

[02:44] most important settings are app env

[02:47] debug. First on production app debug

[02:49] should be always false because otherwise

[02:52] it would show all the debugging errors

[02:55] and data and details to your live

[02:57] customers including database structure,

[03:00] eloquent queries, file structure, file

[03:02] name. basically huge security issue and

[03:05] then related to that app production will

[03:08] also make sure that some local stuff

[03:11] will not get shown on production for

[03:13] example in Laravel eloquent there's

[03:16] configuring eloquent strictness so you

[03:18] can configure preventing off lazy

[03:20] loading but only in your local

[03:22] environment so here and there you may

[03:24] see app is production manual checks or

[03:27] checks inside of the framework so those

[03:30] two things are non-negotiable app envug.

[03:34] And actually here I will mention another

[03:36] security flow. Perhaps no one does it

[03:38] these days, but just in case I will

[03:40] repeat. Do not push your env to GitHub

[03:43] and do not make it public in whatever

[03:45] form. Env.example should be in the

[03:48] GitHub for other developers to see the

[03:50] keys with empty values. But should be

[03:54] hidden and only accessible on the server

[03:56] when you SSH to the server and edit that

[03:59] data manually. The next mistake is some

[04:02] developers forget to update app URL. I

[04:05] remember on Larcast forum there were

[04:07] typical questions like why my file

[04:09] upload doesn't work and of course it

[04:11] doesn't work because it relies on app

[04:13] URL and if you leave it local host or

[04:15] whatever is your test domain then of

[04:17] course it wouldn't work on the live

[04:19] server. And speaking of app URLs a few

[04:22] more things to not forget. If you

[04:24] install SSL certificate and of course

[04:27] you should do that then do not forget to

[04:29] change that to HTTPS here and also in

[04:32] the code before deployment double check

[04:34] that you're using relative paths

[04:36] everywhere. So here's my tweet pretty

[04:38] recent and pretty popular with 70 likes.

[04:41] So always use paths like storage path,

[04:43] public path. So laravel helpers to

[04:46] access some path without hard- coding

[04:48] the URLs or full paths that may be

[04:52] different on your local and on

[04:54] production server. And also another side

[04:56] note, I remember in WordPress whenever I

[04:58] deploy something to live back in the day

[05:00] when I used WordPress, if I mention some

[05:03] image in the content, it was always with

[05:05] the full URL with local host or whatever

[05:08] was the URL. And I always had to deal

[05:10] with updating all the URLs after

[05:12] deployment. And fun fact, it did work

[05:15] for me because for example, I'm on my

[05:16] local host. I deploy, I launch the

[05:19] website, it works for me with real URL

[05:21] on production, but it loads the images

[05:23] from my local host, which works for me.

[05:26] And then other developers or other users

[05:29] report that the images aren't loading or

[05:31] something. So yeah, kind of a side note,

[05:33] always ask someone else to check the

[05:35] website if it works for them. And of

[05:37] course, run automated tests if you have

[05:39] them. So that's with the URLs. Next

[05:41] topic or the next kind of set of

[05:43] mistakes is basically forgetting to

[05:45] doublech checkck pretty much all the

[05:47] values in NV file. Probably the most

[05:50] crucial ones I will mention is of course

[05:52] database credentials and of course it

[05:54] should be the same database as I

[05:56] mentioned already. If you used SQLite in

[05:58] the process of development, double check

[06:00] with MySQL local before running on MySQL

[06:04] on production. So it should be the same

[06:06] database driver. And speaking of

[06:08] drivers, double check which drivers you

[06:11] want to use for sessions. Q connection

[06:15] file system disk mail driver or it's

[06:18] called mail mailer. So basically make

[06:20] your choices for production which may be

[06:23] different from your local. So for

[06:25] example locally you may run it without

[06:27] cues with Q connection sync and then for

[06:30] production you may want to use database

[06:32] driver or reddis or something else. And

[06:35] with Q's, my advice would be to

[06:36] specifically take the time to test if

[06:38] the cues work after the deployment.

[06:41] Because with QES, there are many things

[06:43] that can go wrong. It may be

[06:44] misconfigured. It may be not launched on

[06:47] the server. You need to configure

[06:48] supervisor if you want it to run

[06:50] automatically. And that's why I love

[06:52] tools like Laravel Forge because they do

[06:55] that automatically for me. And I don't

[06:56] need to SSH to the server to do that

[06:58] manually. But yes, specifically with

[07:00] Q's. Time and time again, I see issues

[07:02] that Q is not working, not restarted or

[07:05] something similar. The next mistake is

[07:07] not checking the third-party

[07:09] credentials. So this is all in config

[07:11] services of Laravel usually and this is

[07:14] a demo from another project. So if you

[07:17] use any service providers like email,

[07:19] postmark or mail gun, they should be

[07:22] here also stripe keys and whatever other

[07:25] API keys locally they are probably

[07:28] different and you need to make sure that

[07:30] production keys are invroduction

[07:33] and that's why it's beneficial to have

[07:34] as I mentioned.

[07:37] For yourself and other developers so you

[07:39] would know what keys do you need

[07:42] specifically and what are their key

[07:44] names. And this tip also includes not

[07:46] only API keys but any URLs for web hooks

[07:50] or social URLs after login. They often

[07:53] also are provided invig.

[07:56] So double check those. The next mistake

[07:58] which I probably should have mentioned

[08:00] earlier is while preparing the server

[08:02] for deployment double check the versions

[08:04] of the software. So PHP version and

[08:08] MySQL version or whatever other database

[08:10] you use also NodeJS version. Here I'm

[08:13] showing Laravel Forge. What it's like to

[08:15] create a server via Laravel Forge so you

[08:18] can choose the versions pretty easily.

[08:20] But that's not the point. The point is

[08:22] that the versions should be identical

[08:24] locally and on production because there

[08:26] may be unpleasant surprises if the

[08:29] production server is older or newer and

[08:32] some syntax in your code that worked

[08:34] locally would not work on production.

[08:36] The next mistake is leaving CDNs after

[08:39] deploying to production. For example,

[08:40] Tailwind locally. You may have worked

[08:43] with this. So, one of the installation

[08:45] ways is play CDN. So, you just do script

[08:49] and load the Tailwind from CDN and that

[08:51] works locally. But after deployment, you

[08:54] may forget to change that to proper

[08:55] installation with npm. Here's an example

[08:58] using Vit or in the latest Laravel 12,

[09:01] it comes already pre-installed with

[09:03] Tailwind 4 and preconfigured. Or another

[09:05] example of CDN based usage often is

[09:08] AlpineJS. So even on their homepage of

[09:10] AlpineJS, they suggest to just load it

[09:13] from CDN and there you go. And you may

[09:16] still do that in production for

[09:17] AlpineJS. But maybe a more proper way

[09:20] for all the JS library is to use proper

[09:24] npm install and have it in package JSON.

[09:27] And the same goes for any JS or CSS

[09:30] scripts that you use. Just double check

[09:31] that you don't leave CDNs if you prefer

[09:34] to install them properly with npm on

[09:37] production. And the final mistake in

[09:39] this video, there may be more and we can

[09:41] discuss in the comments if I miss

[09:42] something, but some developers forget to

[09:45] tweak their PHP or web server settings

[09:48] for production usage. So here's an

[09:50] article, a very old article on Laravel

[09:52] Daily from 2018. Then it was updated to

[09:54] 2022, but the message is the same. A

[09:57] typical practical example is file

[09: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