So in our first video, we got our Laravel app up and running with all the local dependencies, linters, formatters, and everything we needed to get it working on our local machine. In this video, we're going to push it up to a remote site and get it working so you can visit it from anywhere else on the internet. One quick note, make sure you've done a git commit before you start this video. Alright, let's go. So the first thing we're going to do is go to github.com/new, and we're going to make a new repository there. For this one, I'm going to name it Symposium for Laracasts because, of course, Symposium already exists. And we don't need any of these options that they give for initializing a gitignore or anything because we already have those things set up with a default Laravel app. So we're going to create the repository, and now we've got a blank repository in GitHub. If we copy this first chunk of code, it will spin up a new repository locally, but we

a default Laravel app. So we're going to create the repository, and now we've got a blank repository in GitHub. If we copy this first chunk of code, it will spin up a new repository locally, but we don't need that because we actually already have one. So we want the second half that takes an existing repository and pushes it up to GitHub. So when we run this command, it attaches that remote GitHub repository to our local and then also tells our local to push it up, and now we can see our actual code here. So now we're going to go over to Forge, and I can't show you everything I'm going to do in Forge. I've got to hide some of my secrets. But people often ask, what are the steps that you all take to spin up new projects in Forge every single time? So I'm going to show you some of them. So first thing I did was I spin up a new project on DigitalOcean. It's a one gigabyte instance called laracast-course2, and it gave me my sudo password and my database password. So I saved them

So first thing I did was I spin up a new project on DigitalOcean. It's a one gigabyte instance called laracast-course2, and it gave me my sudo password and my database password. So I saved them locally to my password manager, and then I just had to wait for a little bit. But at one point, I was able to come in here and see this public IP address here. And once I got the public IP address, I can copy that, and then I can take it over to my domain name service provider, my DNS provider, and start attaching domains and subdomains to it. So let's go over there and get that started. So we're going to log in, and just as with Forge, I have to hide some of my settings here. But we're going to go manage our domain name server, our DNS configuration items. And with most websites, you're going to use an ANAME record. So we're going to create an ANAME record, and whatever I want, .titan.dev, I type it in here. And then the IP address for our server, we're going to paste it.

you're going to use an ANAME record. So we're going to create an ANAME record, and whatever I want, .titan.dev, I type it in here. And then the IP address for our server, we're going to paste it into the IP address section. And so now anytime anybody types in symposium.titan.dev, they're going to be automatically redirected to our server. And because dnsimple is fast, it's going to happen almost instantaneously. So once Forge finishes provisioning, we'll be able to set up a site for symposium.titan.dev, push our GitHub code up there, and also define a deploy script that runs every single time we push new code up to our GitHub repo. All right, so now a little bit of time has passed. The site is up and running, and we have this default site that shows up on every single layer of our server. If you just type in your IP address for your server, you're automatically going to see this default site, which shows you all sorts of configuration

up on every single layer of our server. If you just type in your IP address for your server, you're automatically going to see this default site, which shows you all sorts of configuration information about your server that we don't really want showing. So we're going to delete the default site. And now we're going to create a site specifically for ours, like I was mentioning before. So symposium.titan.dev, it's a Laravel app, so we want to just stick with the defaults there. We don't need to add any aliases, so we can just hit add site. All right, so we want to hit our repository first, so mat-style first, /symposium for laracasts. And the next thing is going to be the branch. We want the default main. And then we want to say, yes, install composer dependencies for me after you set it up. And this last one here, generate deploy key, by default, Forge adds a key to your entire GitHub account for the server. If you want to be a little

composed dependencies for me after you set it up. And this last one here, generate deploy key, by default, Forge adds a key to your entire GitHub account for the server. If you want to be a little bit safer, you can say only attach this server to this one GitHub repository, which is what we're going to do here. As you can see, it says we should add the deploy key to our source control provider before we install it. So let's click it to copy it, and we want to go over to our GitHub repo, the settings, and we scroll down to the deploy keys section, and we can add it as a deploy key. So you paste it in, give it a name, I would just call it Forge, add the key, and now we can install our repository. So while that's installing, the last thing we want to do before we are actually live is to be able to connect to the database. So we're going to come in here and add a new entry, a new connection in TablePlus. And we want to make this the

before we are actually live is to be able to connect to the database. So we're going to come in here and add a new entry, a new connection in TablePlus. And we want to make this the named Symposium for Laracasts. And we want to connect over SSH. So you click the over SSH button. And the first thing we want to do is put in the IP address, well, the user Forge, and then the IP address which you can copy from the public IP from Forge. We want to click use SSH key, I have it set up so that Forge automatically uploads my SSH key to all my servers. And then the database user is Forge. And this section down at the bottom is the SSH information, section at the top is the database information. I grabbed my database password from where we stored it earlier. And then we want to do a test connection. So green down here means SSH connected, and green up here means the database connected. So now let's tag it as a staging environment and save it. We can

And then we want to do a test connection. So green down here means SSH connected, and green up here means the database connected. So now let's tag it as a staging environment and save it. We can click on it now make sure it works. And once we've got it open, we can actually create a new database Symposium. Open and there we go. Now if we come back over here, we can see that everything has finally finished provisioning. It's time for us to modify the settings. We're going to start with the deploys. So as you can see here, we've got a deploy script that Forge runs by default. And I'll almost always modify this at least a little bit to do some build steps or whatever. We're going to keep it pretty simple for this one. We're just going to do npm ci which installs and then npm run build, which will actually run the build process. In most of my production sites, I will actually run things like php artisan config:cache and other artisan commands. But for this, we'll just

then npm run build, which will actually run the build process. In most of my production sites, I will actually run things like config:cache and other artisan commands. But for this, we'll just keep it pretty simple. So let's save our build script and enable quick deploy. And what this does is basically every single time we push up to that main branch that's watching, it's going to run this deploy script for us. And when you run it manually, you can actually watch the output as if you were running it directly in a server to make sure everything's happening you expect to be happening. And it's done building. So let's take a look at symposium.titan.dev to see what we see there. And oops, so this is because this is a .dev domain, we're restricted, we were required to have SSL. And I was going to wait and show you the non HTTPS version. But it's actually required for .dev domains. So we're going to go to let's encrypt. And we're going to ask it for a SSL

have SSL. And I was going to wait and show you the non HTTPS version. But it's actually required for .dev domains. So we're going to go to let's encrypt. And we're going to ask it for a SSL certificate. And this is a free way to have an SSL certificate running. So refresh it. And there we go. Now on the staging site, which is accessible on the whole internet, we see all the things that we were previously seeing in our local development environment. So at this point, we're almost ready to go. But there's a few things that I'll often forget a little bit down the road that I didn't turn on in a server. For example, I forgot to turn on the cron scheduler, or I forgot to install a mailer or whatever else. So I like to make sure that when I'm first setting up a server, I've got a little checklist and you can have your own checklist. But for me, the first thing I definitely want to do is go turn on the scheduler because that's one of the things that catches me the most

a little checklist and you can have your own checklist. But for me, the first thing I definitely want to do is go turn on the scheduler because that's one of the things that catches me the most often. Thankfully, in the newest version of Forge, you don't even have to go set it up yourself, there's just a button for it. Just hit this toggle. And all of a sudden the scheduler is set up for you. And that's a cron job that's going to hit the schedule:run command on your project once every minute. And that's what enables Laravel scheduler to do all these configurations in your console. The other thing I like to do is set up notifications. So I want to know that if a deployment succeeds or fails or whatever else I want to be told somewhere so you can set it up in your email, you can set up webhooks. Personally, I just have a ops channel. So for example, if I'm working on a project called symposium, I will have a channel in Slack that is symposium-

in your email, you can set up webhooks. Personally, I just have a ops channel. So for example, if I'm working on a project called symposium, I will have a channel in Slack that is symposium-ops. And I'll just set it up in here to enable notifications when things succeed or when things fail. I also do the same thing in GitHub. And there's this GitHub Slack integration. And what allows you to do is basically in Slack, you can subscribe to a particular repo, and you just say /github subscribe, and it does some default subscriptions. But you can also add subscriptions. So one of the things I would like to do usually is say also notify me when my workflows succeed or fail. And so you can take a look at this slack.github.com for all the details of how to do those subscriptions and what you're going to get notified of by default and what additional things you can get notified of. The last thing I want to do every time is I want to

of how to do those subscriptions and what you're going to get notified of by default and what additional things you can get notified of. The last thing I want to do every time is I want to add a SSH shortcut. And this is something that we don't talk about very often. But if you take a look at this file, /config, this file allows you to set up all sorts of configuration items for your SSH, including shortcuts. And I will make an SSH shortcut that just allows me to say SSH symposium. And that's it. I don't have to type the username. I don't have to type the IP address or anything like that. So for this particular one, we're going to vim our, oops, ~/.ssh/config file. I'm going to blur a whole bunch of stuff out. And you can see the first thing we're saying is for all of our hosts, we're going to use our SSH keys and pass it along with our SSH calls. And then for each of these hosts, we can define the shortcut name, the host name, user, and all sorts of other.

of our hosts, we're going to use our SSH keys and pass it along with our SSH calls. And then for each of these hosts, we can define the shortcut name, the host name, user, and all sorts of other specific configuration items. So I can create one called, you know, laracasts_symposium, kind of long. I probably wouldn't make it that long. Usually host name. And we paste in our IP address here. And then user, we'd make it forge. There's that IP address. Once we save this, we can then SSH laracasts_symposium. Like I said, it's long, it's a bad name. And here we go. We're now SSH-ed in, and we can access our code however we want. The last thing I like to do when I'm first setting up a project like this is I like to set up a mailer. And I'm not going to walk through the whole process because it takes a little bit of time with some DNS connections. But what I would say is sign up for a

like this is I like to set up a mailer. And I'm not going to walk through the whole process because it takes a little bit of time with some DNS connections. But what I would say is sign up for a service like Mailgun or Postmark, and this will allow you to actually send real mail with your staging sites. You need to be careful to make sure you're not sending mail to a whole bunch of fake email addresses. But at some point, you're going to want people to be able to do password resets and get confirmation emails. And you're not going to be able to be as confident that that's actually working correctly if you're not sending real emails. So I like to set up a mailer. And Mailgun is also fine. It doesn't have the same deliverability as Postmark. So Postmark is kind of my favorite. You come in here and you set up a new server. I would name this Symposium Staging. And you set up some DNS settings and basically prove to Postmark you are who you say you are.

of my favorite. You come in here and you set up a new server. I would name this Symposium Staging. And you set up some DNS settings and basically prove to Postmark you are who you say you are. And then you'll be able to send emails directly from this. Many of these mailers have php packages, but I often just use the SMTP settings because every single one of them is going to provide you with an SMTP username and password anyway. It's a lot easier that way. And if you ever want to change your email provider down the road, it's a lot easier when all you're doing is just swapping out an SMTP username and password versus actually changing out the packages you're using. So we did it. The site that was previously only working in our local development environment now is hosted on GitHub, automatically deployed to Forge, and visible from an actual live domain or subdomain name accessible from the whole internet. Now let's get started building.

now is hosted on GitHub, automatically deployed to Forge, and visible from an actual live domain or subdomain name accessible from the whole internet. Now let's get started building. See you in the next one.