{"id":4742,"date":"2024-12-12T10:18:54","date_gmt":"2024-12-12T15:18:54","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=4742"},"modified":"2024-12-12T10:18:55","modified_gmt":"2024-12-12T15:18:55","slug":"introducing-fly-io","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/introducing-fly-io\/","title":{"rendered":"Introducing Fly.io"},"content":{"rendered":"\n

Fly.io<\/a> is an increasingly popular infrastructure platform. Fly is a place to deploy your applications, similar to Vercel or Netlify, but with some different tradeoffs.<\/p>\n\n\n\n

This post will introduce the platform, show how to deploy web apps, stand up databases, and some other fun things. If you leave here wanting to learn more, the docs are here<\/a> and are outstanding.<\/p>\n\n\n\n

What is Fly?<\/h2>\n\n\n\n

Where platforms like Vercel and Netlify run your app on serverless functions which spin up and die off as needed (typically running on AWS Lambda), Fly runs your machines on actual VM’s, running in their infrastructure. These VMs can be configured to scale up as your app’s traffic grows, just like with serverless functions. But as the continuously run, there is no cold start issues. That said, if you’re on a budget, or your app isn’t that important (or both) you can also configure Fly to scale your app down to zero machines when traffic dies. You’ll be billed essentially nothing during those periods of inactivity, though your users will see a cold start time if they’re the first to hit your app during an inactive period.<\/p>\n\n\n\n

To be perfectly frank, the cold start problem has been historically exaggerated, so please don’t pick a platform just to avoid cold starts.<\/p>\n\n\n\n

Why VMs?<\/h2>\n\n\n\n

You might be wondering why, if cold starts aren’t a big deal in practice, one should care about Fly using VMs instead of cloud functions. For me there’s two reasons: the ability to execute long-running processes, and the ability to run anything that will run in a Docker image. Let’s dive into both.<\/p>\n\n\n\n

The ability to handle long-running processes greatly expands the range of apps Fly can run. They have turn-key solutions for Phoenix LiveView, Laravel, Django, Postgres, and lots more. Anything you ship on Fly will be via a Dockerfile (don’t worry, they’ll help you generate them). That means anything you can put into a Dockerfile, can be run by Fly. If there’s a niche database you’ve been wanting to try (Neo4J, CouchDB, etc), just stand one up via a Dockerfile (and both of those DBs have official images), and you’re good to go. New databases, new languages, new anything: if there’s something you’ve been wanting to try, you can run it on Fly if you can containerize it; and anything can be containerized.<\/p>\n\n\n\n

But… I don’t know Docker<\/h2>\n\n\n\n

Don’t worry, Fly will, as you’re about to see, help you scaffold a Dockerfile from any common app framework. We’ll take a quick look at what’s generated, and explain the high points.<\/p>\n\n\n\n

That said, Docker is one of the most valuable tools for a new engineer to get familiar with, so if Fly motivates you to learn more, so much the better! <\/p>\n\n\n\n

If you’d like to go deeper on Docker, our course Complete Intro to Containers<\/a> from Brian Holt is fantastic.<\/p>\n\n\n\n

Let’s launch an app!<\/h2>\n\n\n\n

Let’s ship something. We’ll create a brand new Next.js app, using the standard scaffolding here<\/a>.<\/p>\n\n\n\n

We’ll create an app, run npm i<\/code> and then npm run dev<\/code> and verify that it works.<\/p>\n\n\n

\n
\"screenshot<\/figure>\n<\/div>\n\n\n

Now let’s deploy it to Fly. If you haven’t already, install the Fly CLI, and sign up for an account. Instructions can be found in the first few steps of the\u00a0quick start guide<\/a>.<\/p>\n\n\n\n

To deploy an app on Fly, you need to containerize your app. We\u00a0could<\/em>\u00a0manually piece together a valid Dockerfile that would run our Next app, and then run\u00a0fly deploy<\/code>. But that’s a tedious process. Thankfully Fly has made life easier for us. Instead, we can just run\u00a0fly launch<\/code>\u00a0from our app’s root directory.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Fly easily detected<\/em> Next.js, and then made some best guesses as to deployment settings. It opted for the third cheapest deployment option. Here’s Fly’s full pricing information<\/a>. Fly let’s us accept these defaults, or tweak them. Let’s hit yes to tweak. We should be taken to the fly.io site, where our app is in the process of being set up.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

For fun, let’s switch to the cheapest option, and change the region to Virginia (what AWS would call us-east-1).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Hit confirm, and return to your command line. It should finish setting everything up, which should look like this, in part.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

If we head over to our Fly dashboard<\/a>, we should see something like this:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

We can then click that app and see the app’s details<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

And lastly, we can go to the URL listed, and see the app actually running!<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Looking closer<\/h2>\n\n\n\n

There’s a number of files that Fly created for us. The two most important are the Dockerfile, and fly.toml<\/code>. Let’s take a look at each. We’ll start with the Dockerfile.<\/p>\n\n\n

# syntax = docker\/dockerfile:1<\/span>\n\n# Adjust NODE_VERSION as desired<\/span>\nARG<\/span> NODE_VERSION=20.18<\/span>.1<\/span>\nFROM<\/span> node:${NODE_VERSION}-slim as base\n\nLABEL<\/span> fly_launch_runtime=\"Next.js\"<\/span><\/span>\n\n# Next.js app lives here<\/span>\nWORKDIR<\/span> \/app<\/span>\n\n# Set production environment<\/span>\nENV<\/span> NODE_ENV=\"production\"<\/span>\n\n# Throw-away build stage to reduce size of final image<\/span>\nFROM<\/span> base as build\n\n# Install packages needed to build node modules<\/span>\nRUN<\/span> apt-get update -qq && \\\n    apt-get install --no-install-recommends -y build-essential node-gyp pkg-config python-is-python3<\/span>\n\n# Install node modules<\/span>\nCOPY<\/span> package-lock.json package.json .\/<\/span>\nRUN<\/span> npm ci --include=dev<\/span>\n\n# Copy application code<\/span>\nCOPY<\/span> . .<\/span>\n\n# Build application<\/span>\nRUN<\/span> npm run build<\/span>\n\n# Remove development dependencies<\/span>\nRUN<\/span> npm prune --omit=dev<\/span>\n\n\n# Final stage for app image<\/span>\nFROM<\/span> base\n\n# Copy built application<\/span>\nCOPY<\/span> --from=build \/app \/app<\/span>\n\n# Start the server by default, this can be overwritten at runtime<\/span>\nEXPOSE<\/span> 3000<\/span>\nCMD<\/span> [ \"npm\"<\/span>, \"run\"<\/span>, \"start\"<\/span> ]<\/span>\n<\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
A Quick Detour to Understand Docker<\/h3>\n\n\n\n
Docker is a book unto its own, but as an extremely quick intro: Docker allows us to package our app into an “image.” Containers allow you to start with an entire operating system (almost always a minimal Linux distro), and allow you to do whatever you want with it. Docker then packages whatever you create, and allows it to be run. The Docker image is completely self-contained. You choose the whatever goes into it, from the base operating system, down to whatever you install into the image. Again, they’re self-contained.<\/p>\n\n\n\n
Now let’s take a quick tour of the important pieces of our Dockerfile.<\/p>\n\n\n\n
After some comments and labels, we find what will always be present at the top of a Dockerfile: the FROM<\/code> command.<\/p>\n\n\n
FROM<\/span> node:${NODE_VERSION}-slim as base<\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
There’s a LABEL<\/code> that’s added, likely for use with Fly. Then we set the working directory in our image.<\/p>\n\n\n
WORKDIR<\/span> \/app<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
We copy the package.json<\/code> and lockfiles.<\/p>\n\n\n
# Install node modules<\/span>\nCOPY<\/span> package-lock.json package.json .\/<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
Then run\u00a0npm i<\/code>\u00a0(but in<\/em> our Docker image):<\/p>\n\n\n
RUN<\/span> npm ci --include=dev<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
Then we copy the rest of the application code:<\/p>\n\n\n
# Copy application code<\/span>\nCOPY<\/span> . .<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
Hopefully you get the point. We won’t go over every line, here. But hopefully the general idea is clear enough, and hopefully you’d feel comfortable tweaking this if you wanted to. Two last points though. See this part:<\/p>\n\n\n
# Install packages needed to build node modules<\/span>\nRUN<\/span> apt-get update -qq && \\\n    apt-get install --no-install-recommends -y build-essential node-gyp pkg-config python-is-python3<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
Lastly, if you were wondering why the package.json<\/code> and lockfiles were copied, followed by\u00a0npm install<\/code>\u00a0and then<\/em>\u00a0followed by copying the rest of the application code, the reason is (Docker) performance. Briefly, each line in the Dockerfile creates a “layer.” These layers can be cached and re-used if nothing has changed. If anything\u00a0has<\/em>\u00a0changed, that invalidates the cache for that layer,\u00a0and also<\/em>\u00a0all layers after it. So you’ll want to push your likely-to-change work as low as possible. Your application code will almost always change between deployments; the dependencies in your package.json<\/code> will change much less frequently. So we do that install first, by itself, so it will be more likely to be cached, and speed up our builds.<\/p>\n\n\n\n
I tried my best to provide the absolute minimal amount of a Docker intro to make this post make sense, without being overhwelming. I hope I’ve succeeded. If you’d like to learn more, there’s tons of books and YouTube videos, and even an entire course\u00a0here on Frontend Masters<\/a>.<\/p>\n\n\n\n
Fly.toml<\/h2>\n\n\n\n
Now let’s take a peek at the fly.toml<\/code> file.<\/p>\n\n\n
# fly.toml app configuration file generated for next-fly-test on 2024-11-28T19:04:19-06:00<\/span>\n#<\/span>\n# See https:\/\/fly.io\/docs\/reference\/configuration\/ for information about how to use this file.<\/span>\n#<\/span>\n\napp<\/span> = 'next-fly-test'<\/span>\nprimary_region<\/span> = 'iad'<\/span>\n\n[build]<\/span>\n\n[http_service]<\/span>\n  internal_port = 3000\n  force_https = true\n  auto_stop_machines = 'stop'\n  auto_start_machines = true\n  min_machines_running = 0\n  processes = ['app']<\/span>\n\n[[vm]]<\/span>\n  size = 'shared-cpu-1x'<\/code><\/span>Code language:<\/span> TOML, also INI<\/span> (<\/span>ini<\/span>)<\/span><\/small><\/pre>\n\n\n
auto_stop_machines<\/span> = 'stop'<\/span><\/code><\/span>Code language:<\/span> TOML, also INI<\/span> (<\/span>ini<\/span>)<\/span><\/small><\/pre>\n\n\n
This tells Fly to automatically kill machines when they’re not needed, when traffic is low on our app.<\/p>\n\n\n
auto_start_machines<\/span> = true<\/span><\/code><\/span>Code language:<\/span> TOML, also INI<\/span> (<\/span>ini<\/span>)<\/span><\/small><\/pre>\n\n\n
The line above tells Fly to automatically spin up new machines when it detects it needs to do so, given your traffic. Lastly, this line<\/p>\n\n\n
min_machines_running<\/span> = 0<\/span><\/code><\/span>Code language:<\/span> TOML, also INI<\/span> (<\/span>ini<\/span>)<\/span><\/small><\/pre>\n\n\n
That line allows us to tell Fly to always keep a minimum number of machines running, no matter how minimal your current traffic is. Setting it to zero allows for no machines to be running, which means your next visitor will see a slow response as the first machine spins up.<\/p>\n\n\n\n
You may have noticed above that Fly spun up two machines initially, even though there was no traffic at all. It does this by default to give your app a higher availability, that is, in case anything happens to the one machine, the other will (hopefully) still be up and running. If you don’t want or need this, you can prevent it by passing\u00a0--ha=false<\/code>\u00a0when you run\u00a0fly launch<\/code>\u00a0or\u00a0fly deploy<\/code>\u00a0(or you can just kill one of the machines in the dashboard – Fly will not re-create it on subsequent deploys).<\/p>\n\n\n\n
Machines won’t bill you if they’re not running<\/h3>\n\n\n\n
When a machine is not running, you’ll be billed\u00a0essentially<\/em>\u00a0zero for it. You’ll just pay $0.15 per GB, per month, per machine (machines will usually have only one GB).<\/p>\n\n\n\n
Adding a database<\/h2>\n\n\n\n
\n
You can launch a Fly app anytime with just a Dockerfile. You could absolutely find an official Postgres Docker image and deploy from that. But it turns out Fly has this built in. Let’s run fly postgres create<\/code> in a terminal, and see what happens<\/p>\n\n\n\n
\"\"<\/figure>\n<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
It’ll ask you for a name and a region, and then how serious of a Postgres setup you want. Once it’s done, it’ll show you something like this.<\/p>\n\n\n\n
\"Fly<\/figure>\n\n\n\n
The connection string listed at the bottom can be used to connect to your db\u00a0from within another Fly app<\/em>\u00a0(which you own). But to run database creation and migration scripts, and for local development you’ll need to connect to this db on your local machine. To do that, you can run this:<\/p>\n\n\n
fly proxy 5432 -a <your<\/span> app<\/span> name<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
\"\"<\/figure>\n\n\n\n
Now you can connect<\/a> via the same connection string on your local machine, but on\u00a0localhost:5432<\/code>\u00a0instead of\u00a0flycast:5432<\/code>.<\/p>\n\n\n\n
Making your database publicly available<\/h3>\n\n\n\n
It’s not ideal, but if you want to make your Fly pg box publicly available<\/a>, you can. You basically have to add a dedicated ipv4 address to it (at a cost of $2 per month), and then tweak your config.<\/p>\n\n\n\n
Consider using a dedicated host for serious applications.<\/h3>\n\n\n\n
Fly’s\u00a0built-in Postgres support<\/a>\u00a0is superb, but there’s some things you’ll have to\u00a0manage yourself<\/a>. If that’s not for you,\u00a0Supabase<\/a>\u00a0is a fully managed pg host, and it’s also superb. Fly even has\u00a0a service<\/a>\u00a0for creating Supabase db’s on Fly infra, for extra low latency. It’s currently only in public alpha, but it might be worth keeping an eye on.<\/p>\n\n\n\n
Interlude<\/h2>\n\n\n\n
If you just want a nice place to deploy your apps, what we’ve covered will suffice for the vast majority of use cases. I could stop this post here, but I’d be remiss if I didn’t show some of the cooler things you can do with Fly. Please don’t let what follows be indicative of the complexity you’ll normally deal with. We’ll be putting together a cron job for running Postgres backups. In practice, you’ll just use a mature DB provider like Supabase or PlanetScale, which will handle things like this for you.<\/p>\n\n\n\n
But sometimes it’s fun to tinker, especially for side projects. So let’s kick the tires a bit and see what we can come up with.<\/p>\n\n\n\n
Having Fun<\/h2>\n\n\n\n
One of Fly’s greatest strengths is its flexibility. You give it a Dockerfile, and it’ll run it. To drive that point home, let’s conclude this post with a fun example.<\/p>\n\n\n\n
As much as I love Fly, it makes me a little<\/em> uneasy that my database is running isolated in some VM under my account. Accidents happen, and I’d want automatic backups. Why don’t we build a Docker image to do just that?<\/p>\n\n\n\n
I’ll want to run a script, written in TypeScript, preferably without hating my life: Bun is ideal for this. I’ll also need to run the actual\u00a0pg_dump<\/code>\u00a0command. So what should I build my Dockerfile from: the bun image, which would lack to pg utilities, or the pg base, which wouldn’t have bun installed. I could do either, and use the Linux package manager to install what I need. But really, there’s a simpler way: use a multi-stage Docker build. Let’s see the whole Dockerfile<\/p>\n\n\n
FROM<\/span> oven\/bun:latest AS BUILDER\n\nWORKDIR<\/span> \/app<\/span>\n\nCOPY<\/span> . .<\/span>\n\nRUN<\/span> [\"bun\"<\/span>, \"install\"<\/span>]<\/span>\nRUN<\/span> [\"bun\"<\/span>, \"build\"<\/span>, \"index.ts\"<\/span>, \"--compile\"<\/span>, \"--outfile\"<\/span>, \"run-pg_dump\"<\/span>]<\/span>\n\nFROM<\/span> postgres:16.4<\/span>\n\nWORKDIR<\/span> \/app<\/span>\nCOPY<\/span> --from=BUILDER \/app\/run-pg_dump .<\/span>\nCOPY<\/span> --from=BUILDER \/app\/run-backup.sh .<\/span>\n\nRUN<\/span> chmod +x .\/run-backup.sh<\/span>\n\nCMD<\/span> [\".\/run-backup.sh\"<\/span>]<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
We start with a Bun image. We run a\u00a0bun install<\/code>\u00a0to tell Bun to install what we need: aws sdk’s and such. Then we tell Bun to compile our script into a standalone executable: yes, Bun can do that, and yes: it’s that easy.<\/p>\n\n\n
FROM<\/span> postgres:16.4<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
Tells Docker to start a new stage, from a new (Postgres) base.<\/p>\n\n\n
WORKDIR<\/span> \/app<\/span>\nCOPY<\/span> --from=BUILDER \/app\/run-pg_dump .<\/span>\nCOPY<\/span> --from=BUILDER \/app\/run-backup.sh .<\/span>\n\nRUN<\/span> chmod +x .\/run-backup.sh<\/span>\n\nCMD<\/span> [\".\/run-backup.sh\"<\/span>]<\/span><\/code><\/span>Code language:<\/span> Dockerfile<\/span> (<\/span>dockerfile<\/span>)<\/span><\/small><\/pre>\n\n\n
This drops into the \/app<\/code> folder from the prior step, and copies over the\u00a0run-pg_dump<\/code>\u00a0file, which Bun compiled for us, and also copies over\u00a0run-backup.sh<\/code>. This is a shell script I wrote. It runs\u00a0pg_dump<\/code>\u00a0a few times, to generate the files the Bun script (run-pg_dump<\/code>) is expecting, and then calls it. Here’s what that file looks like:<\/p>\n\n\n
<strong>#!\/bin\/sh<\/strong><\/span>\n\nPG_URI_CLEANED=$(echo<\/span> ${PG_URI}<\/span> | sed -e 's\/^\"\/\/'<\/span> -e 's\/\"$\/\/'<\/span>)\n\npg_dump ${PG_URI_CLEANED}<\/span> -Fc > .\/backup.dump\n\npg_dump ${PG_URI_CLEANED}<\/span> -f .\/backup.sql\n\n.\/run-pg_dump<\/code><\/span>Code language:<\/span> Bash<\/span> (<\/span>bash<\/span>)<\/span><\/small><\/pre>\n\n\n
This unhinged line:<\/p>\n\n\n
PG_URI_CLEANED=$(echo<\/span> ${PG_URI}<\/span> | sed -e 's\/^\"\/\/'<\/span> -e 's\/\"$\/\/'<\/span>)<\/code><\/span>Code language:<\/span> Bash<\/span> (<\/span>bash<\/span>)<\/span><\/small><\/pre>\n\n\n
is something ChatGPT helped me write, to strip the double quotes from my connection string environment variable.<\/p>\n\n\n\n
Lastly, if you’re curious about the index.ts<\/code> file Bun compiled into a standalone executable, this is it:<\/p>\n\n\n
import<\/span> fs from<\/span> \"fs\"<\/span>;\nimport<\/span> path from<\/span> \"path\"<\/span>;\n\nimport<\/span> { S3Client, PutObjectCommand } from<\/span> \"@aws-sdk\/client-s3\"<\/span>;\n\nconst<\/span> numToDisplay = (num: number<\/span>) =><\/span> num.toString().padStart(2<\/span>, \"0\"<\/span>);\n\nconst<\/span> today = new<\/span> Date<\/span>();\nconst<\/span> date = `${today.getFullYear()}<\/span>\/${numToDisplay(today.getMonth() + 1<\/span>)}<\/span>\/${numToDisplay(today.getDate())}<\/span>`<\/span>;\nconst<\/span> time = `${today.getHours()}<\/span>-${numToDisplay(today.getMinutes())}<\/span>-${numToDisplay(today.getSeconds())}<\/span>`<\/span>;\nconst<\/span> filename = `${date}<\/span>\/${time}<\/span>`<\/span>;\n\nconst<\/span> REGION = \"us-east-1\"<\/span>;\nconst<\/span> dumpParams = {\n  Bucket<\/span>: \"my-library-backups\"<\/span>,\n  Key<\/span>: `${filename}<\/span>.dump`<\/span>,\n  Body<\/span>: fs.readFileSync(path.resolve(__dirname, \"backup.dump\"<\/span>)),\n};\nconst<\/span> sqlParams = {\n  Bucket<\/span>: \"my-library-backups\"<\/span>,\n  Key<\/span>: `${filename}<\/span>.sql`<\/span>,\n  Body<\/span>: fs.readFileSync(path.resolve(__dirname, \"backup.sql\"<\/span>)),\n};\n\nconst<\/span> s3 = new<\/span> S3Client({\n  region<\/span>: REGION,\n  credentials<\/span>: {\n    accessKeyId<\/span>: process.env.AWS_ID!,\n    secretAccessKey<\/span>: process.env.AWS_SECRET!,\n  },\n});\n\ns3.send(new<\/span> PutObjectCommand(sqlParams))\n  .then(()<\/span> =><\/span> {\n    console<\/span>.log(\"SQL Backup Uploaded!\"<\/span>);\n  })\n  .catch(err<\/span> =><\/span> {\n    console<\/span>.log(\"Error: \"<\/span>, err);\n  });\n\ns3.send(new<\/span> PutObjectCommand(dumpParams))\n  .then(()<\/span> =><\/span> {\n    console<\/span>.log(\"Dump Backup Uploaded!\"<\/span>);\n  })\n  .catch(err<\/span> =><\/span> {\n    console<\/span>.log(\"Error: \"<\/span>, err);\n  });<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
I’m sure someone who’s actually good with Docker could come up with something better, but this works well enough.<\/p>\n\n\n\n
Scheduling a custom job<\/h3>\n\n\n\n
We have a working, valid Docker image. How do we tell Fly to run it on an interval? Fly has a command just for that:\u00a0fly machine run<\/a><\/code>. In fact, it can take a\u00a0schedule<\/code>\u00a0argument, to have Fly run it on an interval. Unfortunately, the options are horribly limited: only hourly, daily, and monthly. But, as a workaround you can run this command at different times: this will set up executions at whatever interval you selected, scheduled off of when you ran the command.<\/p>\n\n\n
fly machine run . --schedule=daily<\/code><\/span><\/pre>\n\n\n
If you ran that command at noon, that will schedule a daily task that runs at noon every day. If you run that command again at 5pm, it will schedule a\u00a0second<\/em>\u00a0task to run daily, at 5pm (without interfering with the first). Each job will have a dedicated machine, but will be idle when not running, which means it will cost you almost nothing; you’ll pay the normal $0.15 per month, per GB on the machine.<\/p>\n\n\n\n
I hate this limitation in scheduling machines. In theory there’s a true cron job template\u00a0here<\/a>, but it’s not the simplest thing to look through.<\/p>\n\n\n\n
Odds and ends<\/h2>\n\n\n\n
That was a lot. Let’s lighten things up a bit with some happy odds and ends, before we wrap up.<\/p>\n\n\n\n
Custom domains<\/h3>\n\n\n\n
Fly makes it easy to add a custom domain to your app. You’ll just need to add the right records. Full instructions are\u00a0here<\/a>.<\/p>\n\n\n\n
Secrets<\/h3>\n\n\n\n
You’ll probably have some secrets you want run in your app, in production. If you’re thinking you could just bundle a .env.prod<\/code> file into your Docker image, yes, you could. But that’s considered a bad idea. Instead, leverage Fly’s secret management<\/a>.<\/p>\n\n\n\n
Learning More<\/h2>\n\n\n\n
This post started brushing up against some full-stack topics. If this sparked your interest, be sure to check out the\u00a0entire course\u00a0on full-stack engineering<\/a> here on Frontend Masters.<\/p>\n\n\n\n
Wrapping Up<\/h2>\n\n\n\n
The truth is we’ve truly, barely scratched the surface of Fly. For simple side projects what we’ve covered here is probably more than you’d need. But Fly also has power tools available for advanced use cases. The sky’s the limit!<\/p>\n\n\n\n
Fly.io is a wonderful platform. It’s fun to work with, will scale to your application’s changing load, and is incredibly flexible. I urge you to give it a try for your next project.<\/p>\n","protected":false},"excerpt":{"rendered":"
If it can go in a Docker, Fly can host it, and they’ll help you with that. Adam Rackis takes a look at the platform and shows off all the things he likes about it.<\/p>\n","protected":false},"author":21,"featured_media":4779,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[270,269],"class_list":["post-4742","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-post","tag-fly-io","tag-hosting"],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/frontendmasters.com\/blog\/wp-content\/uploads\/2024\/12\/fly-io.jpg?fit=1000%2C500&ssl=1","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/4742","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/comments?post=4742"}],"version-history":[{"count":15,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/4742\/revisions"}],"predecessor-version":[{"id":4780,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/posts\/4742\/revisions\/4780"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media\/4779"}],"wp:attachment":[{"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/media?parent=4742"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/categories?post=4742"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/frontendmasters.com\/blog\/wp-json\/wp\/v2\/tags?post=4742"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
To see this whole thing all together, in one place, you can see it in my GitHub<\/a>.<\/p>\n\n\n\n
This is basically the config file for the Fly app. The options for this file are almost endless, and are documented\u00a0here<\/a>. The three most important lines are the next three.<\/p>\n\n\n
That tells the Linux package manager to install some things Fly thinks Next might need, but in actuality\u00a0probably doesn’t<\/a>. Don’t be surprised if these lines are absent when you read this, and try for yourself.<\/p>\n\n\n\n
This tells us the base of the image. We could start with any random Linux distro, and then install Node and npm, but unsurprisingly there’s already an officially maintained Node image: there will almost always be officially maintained Docker images for almost any technology. In fact, there’s many different Node images to choose from<\/a>, many with different underlying base Linux distro’s.<\/p>\n\n\n\n