Lecturer: 0:00 As much as I love typing fly deploy every time I want to deploy my app, I'd much rather have my main branch of my Git repo always be deployable. Anytime I merge anything into the main branch, it deploys automatically.

0:14 I've already got a GitHub repo here set up. All I need is a GitHub Action that runs the fly deploy command for me. Now, I don't have to worry about it anymore.

0:23 We're going to make that in a GitHub directory. Under that, we'll have a workflows directory. Under that, we'll have our deploy.yml. This will have our config for our action. We're going to call it deploy. We only want this to run on main branch pushes.

0:44 Then, for our job, we'll have a job called deploy. It runs on Ubuntu, and we have just two steps. All we have to do is check out the repo, and then run the deploy command with Fly.

0:58 Now, this one's a little bit different. It's not as simple as run, fly deploy for a couple of reasons. First of all, we need to get Fly installed. We get Fly installed using the superfly/flyctl-actions. That gets it installed for us, but this specifically will allow us to run a command with specific args.

1:20 The args we want to pass to Fly is deploy. We're also going to pass --remote-only. That way, we're going to use the Fly builder instead of running within the action itself to build the Dockerfile on everything. Fly will manage all of that for us. That's why we're specifying remote only.

1:38 The final thing is our Fly API token needs to be provided, because we're not authenticated on Fly within the context of this GitHub Action. If anybody could make a GitHub Action and deploy it to our app, that would not be a good thing. We need to have a Fly token. We need to have it accessible for our actions.

1:57 Let's go to our Fly dashboard. We'll go to account and access tokens. Then, we'll make one called GitHub Action. We'll call create, we'll copy that, and then we'll go to our GitHub repo. We'll go to the settings, and over to our secrets and variables. Under actions, make a new repository secret. We'll call this our FLY...

2:22 Actually, we need to make sure it's the same, the FLY_API_TOKEN. We'll paste in the secret there, add that secret. Now, we're ready to commit this. We'll git status. We added the GitHub directory, so we'll git add everything. Then, we'll run git commit, add deploy workflow. Now, we push.

2:49 With that, we can go over to our actions. In a moment, we should get a running deploy action. Now, we can go to that running action. We can look at the deploy. This should only take a little time here.

3:03 We get to the deploy-to-production piece. Obviously, we've been authenticated because it is running. It verifies our config. It's running with our Dockerfile. Now, it's going to push that image up to Fly. Then, Fly will trigger the release, which is happening right now. We can open up the logs, and take a look at how our application is doing.

3:26 There we go. It's shutting down the virtual machine. Now, it's starting our instance, pulling up our new instance of our application, and it is listening. It's already responding to health checks. Let's go to our app, refresh, and everything is running swimmingly.

3:44 All we needed to do was create a GitHub repo for our application. Create a workflow that has a simple deploy that all it does is check out the repo. It runs the deploy command with the superfly/flyctl-actions. We created our API token by going to our Fly dashboard, and going to account, access tokens, creating a new token.

4:09 Then, going to the settings of our GitHub repo. Going to secrets and variables, actions. Then, creating a new repository secret that has the same name as the name in our action right here. Then, we simply commit that workflow, push it up, and watch it fly.