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
Maps, Apps, and Tracks
Maps, Apps, and Tracks describes how to build an online map that tracks a marathon runner from a mobile device and deploys it with Fly. The route is drawn and exported as GPX, imported into Google My Maps, enriched with mile markers, and exported as KML for display through Leaflet.js and the leaflet-kml plugin. An Express server accepts OwnTracks HTTP POSTs at /log/, filters location messages by a hard-coded topic, stores latitude and longitude in memory, and exposes them through /where/. Browser code places or moves a marker by polling that endpoint every 30 seconds, while static files are served from the mappages directory. Local testing uses a shell script with mock OwnTracks JSON, and Fly deployment uses flyctl, fly init, and fly deploy; the post notes authentication, Redis persistence, and multiple runners as possible additions.
The September Fly Changelog: New Names and Easier Updates
September’s Fly CLI changes focus on easier installation, updates, and Windows 10 use while also adding static-site deployment options and app-initialization controls. The installer still installs flyctl but now creates a symbolic link for fly, beginning a planned migration to fly as the CLI’s actual name; fly version update now downloads and installs the latest release. New hugo-static and staticplus builders support static websites, with hugo-static running a Hugo build before deployment and staticplus adding HTTPS redirection for custom domains, though staticplus is slated for retirement. Windows received PowerShell-based installation and updating, while fly init gained --overwrite and --nowrite for controlling fly.toml changes and supporting deployments under alternate app names recorded in fly.alias. The release also included DNS and domains command updates, Alpine avoidance for builtins, a Deno builder change removing the deps.ts requirement, and improved allocation displays.
Using Heroku Postgres From A Fly App
A Fly application can use Heroku Postgres without migrating the application itself, with Heroku hosting an add-on-only app that provides the database. The setup provisions a Hobby Dev Heroku Postgres database, retrieves its URI credentials, and passes DATABASE_URL to the Fly deployment as a secret. A Node REST API using Sequelize parses that URI with pg-connection-string, then supplies the database, user, password, and host while enabling SSL and setting rejectUnauthorized to false for Heroku’s certificate-chain issue. After fly deploy, the app connects externally to Postgres, but the Hobby plan limits it to 20 connections unless upgraded. The article presents Heroku’s US and Europe data-center choices as a way to keep the database relatively close while Fly places the application near users, and warns that credentials rotate periodically without notification.
Migrating Heroku Database Apps To Fly
Migrating a Heroku application to Fly requires attention to database connectivity because Heroku Postgres must be accessed over SSL from outside Heroku. The post uses the DATABASE_URL environment variable, parses it with pg-connection-string, and passes a configured connector to Massive.js, setting sslmode to require and rejectUnauthorized to false to accommodate self-signed certificates in Heroku Postgres’s certificate chain. It also shows a local-development fallback that uses a non-SSL localhost Postgres connection when DATABASE_URL is undefined. With these changes, Turboku can migrate the app and convert DATABASE_URL into a Fly secret, while the application retains its database connection and can use Fly’s region and scaling controls. Database latency still depends on proximity to Heroku’s US or European database regions, so caching within Fly regions may matter for mission-critical performance.
Always Be Connecting (with HTTPS)
The post explains how to ensure users reach an HTTPS version of an application running behind Fly’s edge proxies, particularly when a custom domain and certificate are attached. Fly’s default fly.dev behavior redirects HTTP automatically, but custom certificates do not activate that upgrade because connection behavior remains under the application owner’s control. The recommended method checks the X-Forwarded-Proto header, which records whether the original client connection used http or https, and returns a 301 redirect to the same URL with an https scheme when needed. Examples implement the check in Go middleware, Express middleware for Node, and Nginx configuration; the post also notes that non-Fly deployments can inspect the request and URL scheme instead, while Fly was considering future automation.
More Fly Answers To Questions
This Q&A addresses three operational questions about Fly: running non-HTTP applications, identifying connection IP ranges, and renaming applications. Non-HTTP apps need a network service for Fly’s default TCP or optional HTTP health checks; otherwise, Fly may kill them, although Worker process support is planned. For connectivity controls, Fly says AS40509 ranges may not match source addresses seen by servers and advises treating Fly IPs as changeable, while client certificates over TLS offer improved authentication. Future IPv6 per-application addresses could support firewall allowlists. Renaming currently requires creating a new app with flyctl init, claiming the desired name, changing fly.toml, redeploying, and manually restoring secrets, certificates, hostnames, scaling, regions, and other configuration, while sacrificing the original app’s history.
Flyctl Builtins - The Fly Changelog for August
Flyctl v0.0.139 adds built-in builders for Node, Ruby, Deno, Go, and static web servers, allowing an app to be initialized and deployed without a Dockerfile. The release also lets flyctl init select a public Docker image, stores that choice in fly.toml, and supports repeatable image builds with configurable ports and health checks. Region visibility improves through backup-region listings and a (b) marker in flyctl status, while guided certificate creation supplies DNS instructions for traffic direction and ownership verification. Additional changes include --import, --local-only, timestamped JSON status output, orgs and dns commands, and clearer deployment and authentication messaging. The changelog notes that orgs and dns remain works in progress, and version 0.0.139 fixes an issue with builtin init.
Sandboxing and Workload Isolation
Workload isolation makes it harder for a vulnerability in one service to compromise the rest of a platform, and becomes especially important when hosting other people’s code. The post surveys isolation mechanisms from chroot and privilege separation through namespaced containers, mandatory access control, seccomp-bpf, capabilities, and language runtimes, before considering virtualized approaches. It emphasizes that network exposure is often the most consequential attack surface, while chroot alone leaves access to ptrace, procfs, device nodes, and networking. Firecracker is presented as the selected VMM: a small Rust implementation that limits itself with seccomp-bpf and runs under an external jailer providing chroot, namespaces, and dropped privileges. The closing menu includes nsjail, unprivileged Docker with tighter filtering, gVisor, and Firecracker or Kata; absent hostile code, the author would tune nsjail for return on investment.
Serve small with Fly.io and GoStatic
The post shows how to deploy a tiny static signpost site on Fly.io using GoStatic, with the aim of keeping the application’s footprint and running cost low. GoStatic is a self-contained web server that can run in a bare Docker image; the described image is 6MB, while the completed deployment reports 7.7MB. The setup uses fly init examplegostatic -p 8043, a two-line Dockerfile based on pierrezemb/gostatic, and an index.html copied to /srv/http/index.html; Fly routes ports 80 and 443 to GoStatic’s port 8043 and provides HTTPS. After deployment reaches one healthy instance, the post reduces the default micro-2x VM from 512MB RAM to micro-1x, which provides 128MB. This matches the small workload and is presented as a way to reduce running costs.
Hugo's There - Flying with Hugo and Caddy
A new community venture’s website is built with Hugo, served by Caddy, and deployed on Fly, with a custom makeroni.cc domain added after the initial deployment. The process initializes a Fly app on port 80, uses Hugo’s Quickstart and Ananke theme, and employs a multi-stage Docker build based on klakegg/hugo:0.74.0-onbuild, copying generated files into caddy:2.1.1. Caddy serves the static files with file_server while auto_https is disabled because Fly handles certificate management; separate rules serve makeroni.cc and redirect the old fly.dev hostname. DNS A and AAAA records connect the domain to Fly, and flyctl certs create requests a Let’s Encrypt certificate through DNS validation, leaving the site ready to serve securely after redeployment.
Flyctl Evolved - Fly Changelog
Flyctl v0.0.137 introduces an app-centric command structure while deprecating the apps subcommand, whose operations now have top-level equivalents such as init, destroy, move, restart, resume, suspend, and list apps. The release changes move, restart, resume, suspend, and status to accept an app name as a final argument, while retaining status -a; list also gains app-name fragments and status or organization filters, and list orgs shows accessible organizations. The init flow offers builders or Dockerfile use, can generate a simple hello-world deployment, and supports --dockerfile to skip the builder query, while info and version gain scripting-oriented output controls. Secret changes block operations on suspended deployments and can monitor deployments unless --detach is used. Platform fixes concatenate multiple HTTP/2 cookie headers during HTTP/1 downcasting, add Via headers to requests and responses, and improve deployment image optimization.
Run Apollo Server Close to Your Users
Run Apollo Server Close to Your Users presents an edge deployment pattern for GraphQL APIs. The post argues that, much like serving JavaScript and markup from a CDN, placing API servers and an application cache near users can improve application speed. Its approach combines Fly.io’s platform for running API servers close to users with a global Redis cache service, then uses Apollo Server’s cache capabilities and first-class Redis support. A demo GraphQL API built from the Open Library REST API accompanies the guide, with both a guide and source code available. The author frames the design through a newly adopted GraphQL perspective, emphasizing static typing and describing the resulting setup as CDN-like infrastructure for an API.
How CDNs Generate Certificates
Fly describes how its CDN automatically generates TLS certificates for customer hostnames with Let’s Encrypt and ACME, focusing on why the older tls-sni-01 validation method was unsafe on shared hosting. ACME authenticates an account with an ECDSA/EdDSA key, creates an order, and verifies domain control through challenges; Fly uses tls-alpn-01, which avoids requiring DNS access or port 80. For validation, Fly requests a challenge, creates a self-signed certificate containing Let’s Encrypt’s token, stores it in distributed certificate storage, and signals the CA to connect with a ClientHello selecting acme-tls/1 via ALPN. The Rust proxy recognizes that ALPN case, retrieves the challenge certificate, and serves it to Let’s Encrypt, which completes the challenge and permits certificate issuance. Fly assigns each application a unique routable IPv6 address and requires CNAME resolution to it for ALPN validation; wildcard certificates instead use DNS challenges.
Flyctl meets JSON
Flyctl adds a --json, or -j, flag that presents command output as JSON to support automation around Fly applications. For GraphQL-backed commands it emits the API data, while logs become structured JSON and deployment progress arrives as a stream of Source/Status/Message objects. The post demonstrates piping flyctl list apps --json through jq to filter fields, convert hostnames and statuses to CSV, and select undeployed apps whose names feed xargs flyctl info --json -a; jq -s then gathers the resulting objects into an array. Because deployment output currently mixes JSON with non-JSON messages, the post recommends using --detach and polling flyctl status or running flyctl monitor instead of relying on the JSON stream for deployment monitoring.
Fly Changelog for 9th June
The 9th June Fly Changelog describes updates to flyctl, Fly platform tooling, and related web sites, centered on installation, application management, monitoring, and Deno builds. New installation instructions support macOS and Linux through a shell script, while a PowerShell command provides native Windows installation and flyctl now installs under $HOME/.fly/bin or configured $FLYCTL_INSTALL/bin. New commands let users restart applications, list accessible apps and organizations with text, organization, and status filters, or resume deployment monitoring with flyctl monitor. The open command accepts a URL path, secret updates automatically start monitoring for redeployment, and upgrade messages move to stderr for CI tooling. The Deno Buildpack now reads configuration from a required .config file, which also allows selecting the Deno version; an empty file is valid, while its absence produces an explanatory error.
Fly Changelog for 29th May
This Fly Changelog records significant changes to the Fly platform, tooling, and websites for the week of 29 May 2020. flyctl 0.0.124 adds apps pause and apps resume commands, which remove all running instances or start one running instance, respectively; regions set replaces the regions in a region pool list; and -v/--verbose provides more detailed command output. The release also improves flyctl apps list by displaying each application's status, while the Deno Buildpack supports unstable Deno builds when an .unstable directory is added to the application directory. Earlier in the month, flyctl 0.0.123 introduced open, which finds a deployed application's hostname and instructs a web browser to open it.
Fly - Now With Power Pause
Fly introduces Power Pause, a way to mothball applications when development pauses, schedules slip, or running costs need management. The new flyctl suspend command saves an application's state and reduces its running instances to zero while retaining networking configuration, IP addresses, and certificates; flyctl resume restores service by starting one instance first, even for applications deployed across multiple regions. Operators can then use flyctl scale set min=n to increase the minimum count, while flyctl regions list shows the region pool and the new regions set command replaces manual region additions and deletions. The release also adds application status to account listings and a flyctl open command that opens a deployed application's hostname in a browser.
WebSockets and Fly
Fly supports WebSocket connections, and the post demonstrates that support with flychat-ws, a small chat application built from raw WebSockets and Express. Deployment requires cloning the example, running npm install, then using flyctl init, flyctl deploy, and flyctl open, with no application-specific configuration changes. Its fly.toml maps internal TCP port 8080 to HTTP port 80 and TLS/HTTP port 443, sets concurrency limits of 20 soft and 25 hard, and checks the service every 10 seconds with a two-second timeout. The Node server broadcasts each received message to every connected client, while the browser selects ws or wss from the served protocol and sends JSON messages. TLS terminates at Fly’s network edge, and the app can also run locally or in Docker.
Mux, Fly, Wocket and RTMP
Wocket is a proof-of-concept application for sending live video from a browser to an RTMP server, potentially avoiding a local encoder such as OBS or Ecamm Live. Built with Next.js and a custom WebSocket server, it captures webcam video, renders it onto a canvas, and uses ffmpeg to support streaming to a Mux live stream through an RTMP ingest URL. The post documents local setup with npm, production commands, and deployment to Fly.io via flyctl and a Dockerfile, while noting that ffmpeg must be available on the PATH. The intended integration uses the MediaRecorder API to send video when dataavailable fires. Mux test streams are limited to five minutes, watermarked, and deleted after 24 hours when no credit card is entered, and the author cautions against relying on the demo for important production workloads.
Fly Changelog May 15th 2020
Fly’s May 15, 2020 changelog records changes to the Fly platform, flyctl, and related websites since the previous update. The main release was a new scaling system based on region pools, accompanied by new scaling commands in flyctl 0.0.122; the earlier autoscale command from version 0.0.121 was removed. The platform also rolled out an HTTP2-only backhaul for traffic between the Fly edge and datacenters, with the changelog reporting improved performance and stability for applications using the http handler. Other entries document new autoscale and regions commands in 0.0.121, consistent naming for flyctl binary artifacts, removal of references to 32-bit Windows and Linux builds during deprecation, and a fix for custom Dockerfile mapping.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.