Loading…
Fly.io
Global application platform enabling developers to deploy and scale applications with edge computing capabilities.
- 199 posts summarised
- latest
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.
From their blog
Latest articles
Deno on Fly
Deno on Fly explains how to package and deploy a Deno 1.0 application using a Dockerfile rather than a buildpack. The example uses the hellodeno-dockerfile project, with an Alpine Linux and Deno 1.0.0 base image, port 8080, a non-root deno user, and separate dependency and application caching layers. A deps.ts file pins imported package versions, while the Dockerfile runs deno cache deps.ts and deno cache server.ts before starting server.ts with deno run --allow-net server.ts. After local Docker testing, the deployment flow uses flyctl init to create the Fly app and fly.toml, then flyctl deploy to build and push the image. The resulting application is available at a Fly hostname, with HTTP and TLS routing to port 8080, automatic HTTPS redirection, and the option to scale globally and add domains with generated certificates.
Updating Scale
Fly introduces a new scaling model and command set intended to simplify how applications distribute instances across regions and manage global load. Instead of assigning instance counts to a fixed regional list, the system uses a pool of allowed regions plus global minimum and maximum instance counts, with Standard and Balanced models determining placement. Standard distributes instances evenly through the minimum and adds demand-driven instances without relocating them, while Balanced can move instances from other regions once the maximum is reached to match regional demand. The new flyctl regions command manages the pool, and flyctl scale show, standard, balanced, set, and vm commands configure or inspect scaling mode, counts, and VM size. Regional allocation can still fall back to a nearby region when the selected region cannot create an instance.
Fly Changelog 1st May 2020
Fly’s 1 May 2020 changelog records enhancements to flyctl, a new Open Source page, and a revised load-balancing allocation algorithm. Version 0.0.117 added flyctl auth docker, allowing deployments of images directly to Fly by adding registry.fly.io to Docker’s authenticated registries, and introduced --image-label for selecting a specific image label at deployment time. The release also increased the timeout at the end of deployment monitoring to prevent erroneous “No Deployment” messages and changed deploy version negotiation to resolve API compatibility errors. For global applications with large numbers of instances, the new algorithm directs each incoming connection to an instance from the closest least-loaded service among three randomly selected healthy services in the app’s three nearest regions.
Imaginary on Fly, just One-click
Fly announces a one-click launcher for Imaginary, an open-source image service that is among Fly’s popular global image-service use cases. The launcher is intended to let users create a running, production-ready version without infrastructure by pasting button code, and Imaginary’s creators added it to the project’s GitHub README. The post says users can get started with operations including converting and resizing images faster, while scalable SVG buttons are designed to work on pages. It also presents one-click launchers as a possible funding channel through revenue sharing and invites other open-source projects to help develop a process for launching applications on Fly.
Fly Changelog 17th April 2020
This changelog records updates to Fly’s infrastructure, flyctl tooling, and web experience during the week ending 17 April 2020. Version 0.0.116 improves diagnostics for invalid fly.toml files by listing problematic sections and settings, adds Homebrew upgrade instructions to the README, provides basic names for flyctl scale vm sizes, and packages flyctl for Arch Linux through flyctl-bin. On the platform, new applications receive their app.fly.dev certificate “instantly,” while Fly Proxy can serve replacement certificates two weeks before expiration when possible. The site also adds a dedicated ChangeLog page that consolidates recent entries, alongside an RSS feed containing changelog posts. The flyctl changes include contributions from Lars Lehtonen and Simon Willison.
Powerbuilding with Fly
Powerbuilding with Fly explains how flyctl controls Docker-image builds when deploying applications to Fly infrastructure. It covers selecting the application configuration with --config, choosing an alternate Dockerfile with --dockerfile, and passing build-time values through --build-args. Using NGINX_PORT as an example, the post shows how Docker ARG can receive a default or command-line value and how ENV=${NGINX_PORT} carries that value into the running image; flyctl deploy --build-args NGINX_PORT=4000 overrides 8080. Build arguments are intended for non-sensitive data because values are baked into the image and may be retrievable, while Fly Secrets are recommended for sensitive application data and are injected as environment variables when the image starts.
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.
Making Datasets Fly with Datasette and Fly
Datasette makes SQLite datasets accessible through a web interface, with SQL queries, JSON and CSV export, and a REST/JSON API. This tutorial imports New York Central Park Squirrel Census CSV data into SQLite, runs it locally with Datasette, and publishes the database to Fly using the datasette-publish-fly plugin. It then renames the database’s X and Y columns to Longitude and Latitude, installs datasette-cluster-map, and redeploys with the plugin to produce an interactive map of squirrel sightings. The deployments expose Datasette online at Fly hostnames, with HTTPS, automatically generated Let’s Encrypt certificates, custom domain support, global deployment options, and edge networking with SSL termination. The mapped deployment lets users inspect individual sightings and view their details.
Continuous Deployment with GitLab
The guide shows how to set up continuous deployment from GitLab CI/CD to a Fly application, using the small Go hellofly example. GitLab supplies the repository contents to a Runner defined by the golang:1.13 image, while a before_script installs curl and downloads flyctl through Fly’s installation script. A deploy job then runs flyctl deploy, which builds and deploys the application from a committed fly.toml file. Authentication is configured by obtaining a token with flyctl auth token and storing it as a protected, masked FLY_API_TOKEN CI/CD variable in the repository settings. After .gitlab-ci.yml is committed and pushed, GitLab starts the deployment job, while the guide notes that more advanced pipeline structures and triggers remain available.
Fly Answers Questions
Fly Answers Questions compiles responses about custom domains, configuration recovery, Turboku deployment, database latency, TLS termination, global databases, continuous deployment, and idle-app scaling. Fly allows multiple custom hostnames per application and automatically provisions Let’s Encrypt certificates after validation; a deleted fly.toml can be restored with flyctl config save -a , with -c supporting another filename. For Turboku, Heroku slugs run as containers in a nearby datacenter rather than at the edge, while region selection can reduce database latency and retain edge SSL termination. The service supports TLS-only termination up to HTTP/1.1, GitHub Actions deployment, Redis for local caching, and a replication system for distributing changes, while keeping one running instance for idle apps instead of scaling them to zero.
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.
How to do Custom Domains with Fly
Custom Domains with Fly is an application guide for using Fly to proxy traffic or serve applications across multiple custom domains. It explains how to configure an NGINX server for external sites and how to attach host and domain names to Fly applications with the flyctl command line. For automated workflows, it describes the Fly GraphQL API operations for adding, removing, checking, and deleting hosts and associated certificates, and points to a repository of ready-rolled Node applications demonstrating the API. The guide's speed run retrieves an app's IPv4 and IPv6 addresses, adds corresponding A and AAAA DNS records, creates a certificate with flyctl, and uses another command to monitor issuance. The resulting setup provides auto-renewing Let's Encrypt TLS certificates, edge TLS, and HTTP/2 support; the guide also states that Fly applications have no limit on attached certificates and can scale on demand.
Fly Friday - News and Tips
This Fly weekly update collects product news, community announcements, and a flyctl usability improvement. It points to guidance for building GraphQL APIs with Fly and for running a private DNS over HTTPS (DoH) service, while noting Firefox’s default DoH rollout in the USA. It also announces a new Fly user community portal with GitHub or social-media sign-in, alongside Turboku’s Product Hunt launch for faster Heroku apps. The technical note covers flyctl 0.0.96’s -c/--completion option: supplying bash or zsh generates a completion file, with zsh users able to redirect it to $fpath[1]/_flyctl and Bash users required to choose a location and source it from .bashrc.
GraphQL, Hasura and Fly
Hasura provides an open source GraphQL backend for accessing PostgreSQL, mapping database schemas and roles to simplify queries. It can also query other GraphQL services, allowing multiple services to be combined, and includes an interactive console for analysis and exploration. The post presents deploying Hasura on Fly using its Docker image to create a global GraphQL backend, with configuration required for the database location, secrets, and interactive-console availability. It points to a published deployment guide that walks through those steps and frames Fly as a simpler way to run Hasura, while directing readers to Fly Docs and a hands-on path for deploying a first app.
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.
Fly Friday - Flyctl and Ports
Flyctl adds a new -p option to flyctl apps create, allowing users to set an app’s internal port during initial creation. The numeric value is written to the generated fly.toml configuration, replacing the default port of 8080. This addresses workflows using prebuilt Docker images, where users may not control the port and previously had to create the app, edit fly.toml, and change the internal port manually. Available from Flyctl release 0.94, the flag removes that edit and is shown in the first Fly Friday video. The post defines the internal port as the port an application uses to communicate with the world, while the command-line setting supplies that value before deployment configuration is generated.
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.
Command Lines, Flyctl and Fly
Fly presents the Fly Global Application Platform as a command-line-first service and introduces flyctl as the way to sign up for free and manage an application's entire lifecycle. The post argues that command-line interfaces integrate directly with modern workflows, are simple and expressive, and keep developers in their terminal and current directory. To replace its Node-based command-line technology, Fly built flyctl in Go as self-contained binaries for macOS, Linux, and Windows, and adopted Cobra for familiar command/subcommand behavior and contextual help. Web interfaces remain intended for rich dashboards and metric displays, alongside interactive terminal use. The command-line approach also makes instructions self-contained, scriptable, and repeatable, which the post identifies as valuable for support and operations, while the open GitHub repository invites feedback.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.