Let's call our site basically done at this point. We've covered enough material that you could build just about anything. So let's get into deploying Statimix sites, your different options, how to optimize for production and everything like that. First thing to think about is how much of the site you want to version control. I like to do everything possible, site, assets, content, templates, everything. I literally just take my entire project, git commit all, obviously without the .env file, and push that to my repo. That's how I like to do it. However, there are definitely cases where you're going to want to exclude certain directories.

That's how I like to do it. However, there are definitely cases where you're going to want to exclude certain directories. For example, assets, which are usually held in public/assets, although they're completely configurable. If you know you're going to have a lot of assets, a couple gigabytes, a couple hundred gigabytes especially, you're not going to want to keep those in your git repo. That's going to be too unwieldy, new people jumping in the project, it's going to take them an hour to pull it down. In that case, you're going to want to exclude that directory, or maybe you want to mount an S3 file system and use that for your assets.

In that case, you're going to want to exclude that directory, or maybe you want to mount an S3 file system and use that for your assets. That's pretty basic to do. It's literally just a Laravel Flysystem config file. Next would be users. If you have a public git repo, maybe you don't want to have your users committed. But if it's private, it's really not a big deal because the passwords are hashed and if you change them, they just stay hashed. So there's nothing really super insecure about that. For content, I really like having all of it committed, but some people like to leave it.

and then launch your site and then deploy it somewhere. This is Laracast. We're going to use Laravel Forge because it is the easiest way to launch just about every site. Let's go with the little extras you're going to want to focus on for a Statamic site specifically. All right, here I am in Forge. I set up the DNS for heavy.e8.learnstatomic.com, that's where we'll launch this site for now. I'm just going to leave it as a general Laravel application. That's fine. Web directory is fine.

That's fine. Web directory is fine. I always like to use the newest version possible and you don't need to create a database because there isn't one. We'll wait for the site to install. Now we're going to connect our Git repository. In this case, it's JackMcDade/Larasmash. Install Composer Dependencies and we'll install the repo. Most Statamic sites run fine on the basic VPSs like DigitalOcean's $5 or $6 droplet. It works fine.

Most Statomic sites run fine on the basic VPSs like DigitalOcean's $5 or $6 droplet. It works fine. The Linode or Vulture basic VPSs works fine unless you have a really, really high volume, high traffic or high amount of storage space site. It just does a great job. I love enabling quick deploy, so we'll do that. Next we'll update our deploy script and we want to add php please stash refresh. This is going to clear the cache and then warm it. Warming will pre-visit all of the pages in your site and make sure that the cache is fully loaded.

Warming will pre-visit all of the pages in your site and make sure that the cache is fully loaded. If you don't want to do that, you can just do php artisan cache:clear and allow those to happen on the fly. Let's leave it as refresh. Now up to you if you have any npm install and npm run production, so we can add that and let's update. Let's deploy the site. A few moments later. All right, deploy was successful.

It's just a basic way to validate that the changes we're about to make are working, but you can see our first request here is 417 milliseconds, which is too much, honestly, but that is because Statamic is building the cache by default on every request, so in production you're going to want to turn that off. It's great for dev, so every change you make, you don't have to worry about clearing the cache or waiting for a control panel event to clear it for you like an entry save. So we'll go back to our config, we'll edit our .env file, and then we're going to set our stashWatcher to false. This is the config that tells Statamic to rebuild that stash, which is our cache, every page request.

Oh, but we're not done yet. Next, Statamic has static caching strategies. This allows Statamic to cache HTML versions of most of the pages of your site and serve them instead of fully dynamic rendered parsed requests. There's half and full. Half measure will store that static HTML, but bootstrap Laravel and Statamic to render it, which does allow you some level of dynamic interaction, allowing Statamic rules to handle redirects and stuff like that. Let's turn that on because this is a really simple one config change, and the following request should be much faster.

We'll save that, and this does require a change to your nginx config. So let's go there, and this page in our documentation, static caching, will have the server rewrite rules that you're going to need for fully static caching for Apache, nginx, and IIS. We're going to grab this rule right here. This tells nginx to look for the URL in the static directory first, and if it exists, use that. Otherwise, fall back and run the request as normal. So again, we're going to copy that, we're going to bring that down in here and replace this block with the new one. Save that, give us a refresh.

this block with the new one. Save that, give us a refresh. Now we're down to 57 milliseconds. At this point, it is completely bypassing Statamic and is literally just rendering that HTML file from your file system. It's a pretty snappy site. Now keep in mind, this is fully static, so if you make changes to it, you're going to have to clear the cache. If you want to have a fully statically cached site, you'll probably want to update your deploy script and have php please static clear.

If you want to have a fully statically cached site, you'll probably want to update your deploy script and have php please static clear. That will clear out the static cache when you make changes and pushing them from your local development environment. Something else you might want to do is in your config/datamix/CP file, config file, there is this CP_ENABLED is the control panel enabled variable. If you don't plan to make any changes in production, you're only going to push from dev, you can turn that control panel off and make sure that those routes can't be hit, which would prevent anything like brute force attacks from ever happening. Let's take a look at one aspect of the static cache.

just exclude that one part from the HTML file and render that on the server side. But as far as your users are concerned, it works exactly the same, nice and fast.