Loading…
Topic
Fly.io
45 posts about Fly.io. Every summary links to the original.
- 45 posts
- 1 company
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Fly Answers More Questions
Fly Answers More Questions addresses three Fly usage questions: protection against malicious TCP connections that trigger runaway scaling, dedicated credentials for GitHub Actions, and selecting Dockerfiles in monorepos. For scaling abuse, Fly apps can impose per-region and global instance limits; requests beyond those limits are dropped, while networking protections are already in place. A configurable monthly maximum spend is described as in preview, and usage from an obvious DDoS or similar event may be waived. For continuous deployment, the suggested pattern is a dedicated user with a personal access token, added to a Fly organization so it can deploy to projects. For complex builds, updated flyctl adds deploy's --dockerfile option, allowing a selected Dockerfile instead of the default Dockerfile.
Scaling Fly for All
Fly makes its scaling controls available to all users, allowing them to manage application instance counts across regions and choose virtual-machine sizes. The default plan places an application in one region, while Fly’s autopilot can add an instance when a connection limit of roughly 20–25 is reached and select its location. The new flyctl scale regions command reports or sets regions and per-region minimum counts; for example, ams=1 hkg=1 sjc=1 keeps at least one instance in each location, with weights influencing where new instances are preferred. Users can also run flyctl scale vm to apply a VM size to all current and future instances, triggering a new app version and redeployment. Available sizes range from micro-1x with 128 MB to cpu8mem8 with 8 GB, while the article notes that the system was later superseded.
Fly Friday - Customizing with Dockerfiles
Fly Friday describes how to customize a Docker image before deploying it to Fly, building on an earlier example that deployed Docker’s official httpd image. The default image serves files from /usr/local/apache2/html and displays “It works”; replacing that content requires adding local HTML files to the image. A two-line Dockerfile uses FROM httpd:2.4 as the base and COPY ./public_html/ /usr/local/apache2/htdocs/ to place the contents of a public_html directory into the new image, which Fly then deploys. The post also notes that the directory must be created and populated with HTML, and points to a video and Fly Docs, including a hands-on path to a free account and first app deployment.
Simpler Fly deployments for NodeJS, Rails, Go, and Java
flyctl now supports building and deploying NodeJS, Rails, Go, and Java applications to Fly with two commands. The feature uses Cloud Native Buildpacks from buildpacks.io, turning an application into a Docker image during deployment without requiring users to understand Buildpacks. Cloud Native Buildpacks are described as an evolution of Heroku and Cloud Foundry systems, but are not compatible with their older buildpacks. After installing the latest flyctl, users can initialize an app with flyctl init --builder cloudfoundry/cnb:bionic and run flyctl deploy, then open it with flyctl open. Buildpack support complements Dockerfile-based image builds, while listed builders provide different language coverage and image sizes; the post recommends heroku/buildpacks:18 for its wider coverage.
Turboku - The Art Of Faster Heroku Apps
Turboku is a migration path that automatically turns Heroku web dynos into Fly applications, addressing how existing Heroku apps can move to Fly’s globally distributed edge network. Fly routes requests to the closest datacenter through one global IP address, or two with IPv6, while TLS terminates closer to users and modern ECDSA certificates are automatic for Fly domains. A benchmark around the world used an existing application to compare Heroku and Fly connection stages, full requests, and cached requests. Fly reduced DNS, TCP, TLS, network, and full-request times, with the largest reported improvement appearing when caching was used: 180.16 ms versus Heroku’s 817.75 ms, a 77.91% reduction; uncached full requests fell 35.39%, while TTFB was 1.24% higher.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.