General questions

1

Hi Fly.io! Thanks for this wonderful service. I spent most of my day trying out this platform (hoping to move away from Heroku to something more scalable), and I’m very impressed thus far.

Few questions:

  1. For Node apps (koa), are VMs always available on re-deployment aka zero downtime? That is, if I deploy an update to my app, will all activity go to the old VM up until the new one is running? Similar to this: Preboot | Heroku Dev Center
  2. To get auto-scale to work, I tweak the default values of services.concurrency hard_limit and soft_limit and enable autoscale with the balanced mode?
  3. Likewise to question 1, if a new VM instance is created, traffic will only be routed to the VM instance when the Node app is listening on the localhost post?
  4. I deployed our app using the Run a Node App tutorial. What files do Run a Node App not upload to the builder? E.g will it not upload files in the .gitignore?

Thanks!

2

Hi! I’m glad it’s working out for you, hopefully it continues!

  1. By default, we do a canary deploy. We spin up a new VM and make sure it’s healthy before we remove the old ones. You can control this with the --strategy flag on the deploy command, rolling to skip the canary and immediate to abruptly replace everything.
  2. Right, soft_limit controls how many instances will run. You probably don’t want balanced, though, that’s only appropriate for some apps. standard will add and remove in the regions you’ve specified.
  3. Yes, the health checks determine whether traffic gets routed to the VM or not. They have to start passing before they’ll receive requests.
  4. The build is just a remote Docker daemon, so .dockerignore is the right way to prevent files from being sent to the builder.
3

Hi Kurt,

Thanks for the quick response here – it’s wonderful that you provide this level of technical support through this community channel. :slight_smile:

  1. Thanks!
  2. So if I remove the services.tcp_checks from the fly.toml and specify a services.http_checks, then Fly will only do HTTP health checks? My preference is to be using HTTP checks as they’re more reliable for what I’m hosting (a Next.js app).
  3. Is there any command to SSH into the remote VM to do an ls -l to manually check to see if the build system is ignoring the correct files?

Next.js has support for hosting all the static JS/CSS files generated by Webpack via a CDN: next.config.js: CDN Support with Asset Prefix | Next.js

I see that Fly does have support for this – I can map the .next/static/ directory to _next/static to take advantage of your Anycast system: App Configuration (fly.toml) · Fly

The configuration will look like this (e.g. test.fly.dev/_next/static/** maps to filesystem directory .next/static/**)?:

[[statics]]
  guest_path = ".next/static/"
  url_prefix = "_next/static"

Using this Anycast system will be great! Serving static content via these Next.js apps is a waste of compute cycles.

Thanks!

4

Yes that’s right! If you only have an HTTP check, that’s all we’ll use.

You can run fly ssh console to ssh to a running VM. You can pick a specific one with fly ssh console -s.

That config looks correct for statics!

5

Hi Kurt,

Wonderful! Thanks for the quick responses – it’s much appreciated. :slight_smile: