Applications that you care about should be tested.

While we won't get into testing in this tutorial, Fly does feature health checks that can be thought of as a last line of defense when deploying an application.

## TCP Health Check

In our `fly.toml` file we can see that Fly already has a TCP health check in place.This ensures the application is ready to accept network connections, but it doesn't actually make a request to the application.

```yaml
[[services.tcp_checks]]
  grace_period = "1s"
  interval = "15s"
  restart_limit = 0
  timeout = "2s"
```

![](http://res.cloudinary.com/epic-web/image/upload/v1680815840/epicweb.dev/tutorials/deploy-web-applications/images-06-healthcheck.mp4/06-healthcheck_5_00-22040-called-a-tcp-check-which-will-just-make-sure-that-our-application-is-ready-to.png)

## Adding HTTP Health Checks

To further enhance our checks, we can add an HTTP check to make a request to the application and deploy it only if it responds with a 200 OK status.

Inside of the Fly.io docs is more information about `services.http_checks` along with a starter we will copy.

![](http://res.cloudinary.com/epic-web/image/upload/v1680815841/epicweb.dev/tutorials/deploy-web-applications/images-06-healthcheck.mp4/06-healthcheck_11_01-16200-were-going-to-copy-this-and-bring-it-over-here-right-below-our.png)

Add the following lines below the TCP check in `fly.toml`:

```yaml
[[services.http_checks]]
interval = 10000
grace_period = "1s"
method = "get"
path = "/"
protocol = "http"
restart_limit = 0
timeout = 500
tls_skip_verify = false
```

This configuration will perform an HTTP GET request every 10 seconds. The grace period of 1 seconds is how long it waits to check after the application starts up. You might need to make this longer for larger apps.

The restart limit is set to 0, which means it won't automatically restart the server after failed HTTP checks. You might want to increase this in your own applications.

There is also the option to add HTTP headers to your checks.

![](http://res.cloudinary.com/epic-web/image/upload/v1680815835/epicweb.dev/tutorials/deploy-web-applications/images-06-healthcheck.mp4/06-healthcheck_29_03-15560-you-want-to-make-authenticated-requests-or-something-like-that-you-can-add.png)

## Testing Health Checks

Let's do a `fly deploy` to test our health checks.

After deploying your application with the new HTTP health check, notice that 2 health checks ran and passed.

![](http://res.cloudinary.com/epic-web/image/upload/v1680815835/epicweb.dev/tutorials/deploy-web-applications/images-06-healthcheck.mp4/06-healthcheck_36_03-57360-so-now-there-are-two-of-them-and-after-a-while-theyre-both-passing-so-if-we-go.png)

To test the health checks, you can deliberately introduce an error in your code and deploy the application.

For example, you can misspell "GET" in the `index.ts` application code and redeploy the app.

Fly will try to deploy the broken version, but since the HTTP health check fails the terminal shows us 1 passing, 1 critical:

![](http://res.cloudinary.com/epic-web/image/upload/v1680815869/epicweb.dev/tutorials/deploy-web-applications/images-06-healthcheck.mp4/06-healthcheck_44_04-43600-all-right-so-now-we-see-that-we-do-still-have-those-two-health-checks-one-is.png)

Because the health check failed, Fly will roll back to the previously good deployment.

## Adding Custom Health Check Endpoints

You can add multiple health checks to further ensure that your application is working.

For example, we an create a custom health check endpoint that checks the database connection by making some queries.

Inside of `fly.toml` copy and paste the existing `services.http_checks` block and change the path to `/healthcheck`:

![](http://res.cloudinary.com/epic-web/image/upload/v1680815838/epicweb.dev/tutorials/deploy-web-applications/images-06-healthcheck.mp4/06-healthcheck_67_07-19880-not-only-will-check-that-i-can-accept-traffic-on-my-home-page-but-also-will.png)

Then inside of `index.ts` we'll add a case to the `switch` statement for `GET /healthcheck` that will get the current count:

![](http://res.cloudinary.com/epic-web/image/upload/v1680815845/epicweb.dev/tutorials/deploy-web-applications/images-06-healthcheck.mp4/06-healthcheck_73_08-12680-res-right-head-200-and-res-end-okay-so-were-all-set-there-and-so-now-we-have.png)

With this custom health check, we can verify not only that the application can accept traffic on the home page, but also that it can make queries to the database.

## Wrapping Up

Our application now has three health checks: the TCP health check, the HTTP health check for the home page, and the additional health check endpoint that checks the database connection.

Remember, health checks are not a replacement for tests but serve as a helpful last line of defense before deploying an application!

While not a replacement for testing, Fly offers health checks to prevent broken code from being deployed.

Lecturer: [0:00] Applications that you care about should be tested, and we're not going to get into testing specifically in this tutorial. However, we do have a little bit of a last line of defense that is offered to us by Fly in the form of health checks.  
  
[0:14] In fact, we already have one health check here. It's called a TCP check, which will make sure that our application is ready to accept network connections, but it doesn't actually connect to our application, make a request, or anything like that.  
  
[0:28] What would be really nice is if, right before deploying, we could just make a quick HTTP call to our application and say, "Can you accept traffic yet?" If it responds with a 200 OK, then let's go ahead and deploy the app. If it doesn't, then let's not deployed the app. Let's keep the old one around and then go figure out why it didn't respond.  
  
[0:47] This is a last line of defense. It's not intended to replace regular testing, but it can be really helpful in deploying applications where there's a lot of moving parts and you want to have just one last little check. This is called HTTP checks. If you look up fly.toml and go to the configuration documentation page, then you can find the services.http_checks config.  
  
[1:12] We're going to copy this and bring it over here, right below our TCP check. This interval is how frequently this HTTP check is going to be made, because it's not just when the application starts. We want to make sure that our application is healthy over time, and so every 10 seconds, it will say, "Hey, are you still healthy?"  
  
[1:33] Then, the grace_period is how long after our application has started up does this HTTP check get called. I'm actually fine with it being one second for this simple application, but some applications take a little while to boot up. Depending on how long it takes for your application to boot up, you'll adjust that grace_period.  
  
[1:53] The method, we can do a GET. You could also do a HEAD request here. We'll just do a GET. We'll do the path to our home page. That seems like a pretty reasonable thing, that people should be able to get to our home page. That should cover a fair bit of ground as a last line of defense.  
  
[2:07] The protocol we're going to leave as HTTP because this is a behind-at-the-network request that's going to be happening from a Fly server to our server, so there's no certificate going on there. We'll leave that as HTTP.  
  
[2:18] Restart_limit. This is how many times, after a failed HTTP check, should Fly automatically restart the server for you. The default is zero. I'm going to leave it there. What zero means is it disables that behavior. It will never restart your application, once the HTTP checks start happening.  
  
[2:36] Depending on your use case or use situation, you might bump that up a couple of times. After a couple failures, go ahead and try and restart, and magically maybe it'll work. Then, the timeout. It's making requests to your application. How long are you OK with it waiting to get a response before it decides, "Oh, must be failing"? I'll just leave that as 200.  
  
[2:57] Something more reasonable, I suppose, might be 500 milliseconds. It depends on how fast your application responds. The tls_skip_verify. This doesn't actually matter all that much because our protocol is HTTP. Then, any headers. If you want to make authenticated requests or something like that, you can add headers down here.  
  
[3:17] With all of that, let's do a fly deploy to get a basic health check out there. Then, after this is successfully deployed and it's running, let's go ahead and see what the experience would be like if we actually did deploy something that totally blew up our home page, for example. We'll speed up here a little bit to get it deployed, and then we'll give that a test.  
  
[3:46] Here, you'll see that it has two health checks. Before, it only had the one, TCP, but now we've added our HTTP check, and so now there are two of them. After a while, they're both passing, so if we go and take a look at our application, we can see that it's still running. Everything is working just fine and things are happy.  
  
[4:04] Of course, you probably ran your test as well, hopefully, and so you are pretty confident that things are good. This just double-checks that everything is going to work out. Now let's make little mistake here. What if I misspell GET right here? That would not be good, and I don't have any TypeScript that's going to double-check that that's right.  
  
[4:23] Maybe I should, but let's go ahead and do a fly deploy right now and see what happens as that gets deployed. Let's expand this so we can see all of the output. We'll speed that up for you too. Now we see that we do still have those two health checks.  
  
[4:42] One is passing, one is critical. It's not passing, and if we look at our logs over here, we're going to see things are not looking super great for our application. The reason is, if we look at our code, when we had that typo on GET, what happens is it passes this case.  
  
[5:01] It continues down in here, and it's going to give us a 404, not found, which is not going to pass our health check. Eventually, Fly is going to decide, "OK, that's not going to fly," literally, and it will roll back to the previous version, so we'll wait for that. Great. Our deploy failed due to unhealthy allocations, so it rolled back to job version 18 and deployed as version 20.  
  
[5:31] We tried to deploy the version that had the breakage in our index here, where we misspelled GET, and that deployed, but Fly didn't actually start sending traffic to it until after the health checks passed. They never passed, and so it rolled back and restarted our application with the previous working version, the version that was up before.  
  
[5:56] It shut down the version that was not working and wasn't able to accept traffic, and it started up a previous version that was working before, and now our application is working. There are various strategies for deploying with Fly that you can use. There's the rolling strategy, which is the default for a Node application that has a persisted volume, and that's the one that we have.  
  
[6:19] There are other strategies you can employ to reduce the amount of time that your deployment is waiting on health checks. In our case, the right thing happened. We did not deploy a app that didn't work. We just made traffic hold off while the deploy was happening and while those health checks were being checked.  
  
[6:38] Because they didn't successfully happen, we ended up shutting down the new deploy, starting up the previous version, so that we could accept traffic. Then, hopefully, we get some alerts and say, "Hey, that deploy did not work, and so you're going to want to take a look at it and figure out what you did wrong."  
  
[6:55] Another thing that I want to do with this is add another health check to make it really certain that things are working, because you can add multiple of these, and that can be quite useful. For example, on my own personal website, I have a health check endpoint, so we'll do the same thing here, /healthcheck.  
  
[7:13] What this does is it not only will check that I can accept traffic on my home page, but also will make some queries to the database to make sure that the database is in a healthy state as well. We'll go ahead and add a health check endpoint here at the top. Case, it'll be a GET request to /healthcheck.  
  
[7:35] With this, we'll just do a try-catch. Of course, we need to add a break. It's a switch statement, after all. In the catch, we'll add a console.error. We'll log the error, and then we'll say, res.writeHead(500) and res.end. We can do "Internal Server Error" or just "ERROR," whatever you want to do there.  
  
[7:55] The actual check that we want to do, let's just say we want to do this query that we're making on the back end. We'll say, await getCurrentCount, and res.writeHead(200) and res.end("OK"). We're all set there, and so now we have three health checks.  
  
[8:13] We've got the TCP health check that came with the initial fly.toml that we started with, the HTTP health check for the home page, and the additional health check endpoint that we can do whatever types of health checks we want. Make sure we have connections with the right services, all of that stuff happening inside of our health check endpoint.  
  
[8:34] That's how you make sure that you don't deploy a broken app to production, as a last line of defense. Again, this is not a replacement for tests, but it's a really good last line of defense, right before you switch from it is almost deployed to actually being deployed and accepting traffic. Really helpful feature from Fly.

Adding Deployment Health Checks

Discord

Email

GitHub

The closer you are to the server, the faster your experience will be.

It wasn't long ago that web app developers had to choose a region where they thought the bulk of their users would be located, leaving people on the other side of the world with longer waiting times.

Fortunately, times have changed and it's now possible to deploy an application and have it be distributed worldwide– and it's not as tough as it sounds!

This tutorial will show you how to deploy a multi-region Node.js application with a persistent database, ensuring optimal performance no matter where your users are located thanks to Fly.io.

Here are some of the topics you'll tackle along the way:

## Deployment with Fly.io

The first step is to get acquainted with configuring Docker and Fly's CLI tool by deploying the demo Counter app.

After all, you have to have everything working in one region before you make it work in multiple regions!

## Data Persistence and Health Checks

You'll learn how to create persisted volumes to avoid data loss, as well as the steps for setting up health checks and custom endpoints for monitoring the app.

## Automatic Deployment with GitHub Actions

The deployment process is pretty easy thanks to Fly's CLI tool– but automating it makes it even easier 😎

## Creating a Staging Environment

Testing your app safely in a staging environment before it goes live is a great way to ensure a smoother rollout with reduced risk of downtime. This is a huge benefit that comes from a minimal amount of configuration.

## Embrace the Distributed Architecture

Once you understand how the pieces fit together, you'll be ready to deploy the demo application to regions all around the world.  
But it's not just the app itself. Fly.io supports LiteFS, which is used to replicate SQLite databases. This means your database can live on the edge, right beside your application.

Everything you learn about deployment in this tutorial is ready for you to put into action for your own applications.

Ready to fly?

Let's do this!

Kent C. Dodds

Learn how to deploy a Node.js application that persists data to multiple regions.

Intro to Deploy Distributed Apps with Node.js & Fly

Fly.io is the service we'll use for deploying our app. The first step is signing up for an account. 

Signing Up for Fly.io

We will deploy to Fly with Docker. A Dockerfile is used to tell Docker the steps to take to run our app.

Setting Up Docker

With the Dockerfile ready to go, let's deploy our app to Fly.

Deploying to Fly with Docker

Fly.io

Project Setup and First Deployment

Currently the counter state is reset to zero after every deployment. Creating a persistent volume with Fly solves this problem.

Persist Application Data Between Deployments

Fly allows you to SSH into your app's virtual machine and run commands. Updating the Dockerfile to create a shortcut script makes the process run more smoothly.

Add a SQLite Console Shortcut with the Dockerfile

Configure GitHub Actions for Automatic Deployment

A staging environment is useful for play testing before pushing changes to production. This can be quickly set up with GitHub Actions and Fly

Add a Staging Environment

Persisting Data and Automatic Deployment

Deploying sites to multiple regions is less of a challenge than handling data. Fortunately Fly makes it easy to prepare for multi-region data.

Prepare for Multi-Region Data with LiteFS

If you're migrating to LiteFS from an existing application, you may have data you'd like to keep. Luckily, there's an easy process for importing it into LiteFS.

Import Existing Data into LiteFS

The Consul lease type provides a resilient solution in case the primary instance of our application goes down.

Set Up the Consul Lease Type

In order to make sure only our primary region attempts to write data, we'll set up a proxy server configuration for LiteFS

Set Up a Proxy Server for Multi-Region Database Support

With all the setup in place, it's time to scale our deployment to multiple regions, and test to confirm it's working as expected.

Get access to Deploy Web Applications All Over the World

And continue watching this video