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
Logbook: November 14 to December 5, 2022
An edition of Fly’s Logbook covering November 14 to December 5, 2022 collects updates and tutorials for building and operating applications on Fly. It features a real-time collaboration example that connects Replicache with WebSockets and Fly-Replay, plus a LiveWire walkthrough for streaming server content to browsers and another for unloading data during large-dataset pagination. A separate guide explains how to run Supercronic from Fly Dockerfiles when precise cron timing is needed beyond Fly Machines’ monthly, weekly, daily, and hourly scheduling options. The edition also recounts how Fly Postgres was built, despite Fly’s stated preference for off-platform database services such as RDS, CrunchyData, and PlanetScale. The post notes that the update followed a longer break while many Fly staff spent time with family over Thanksgiving.
How We Built Fly Postgres
Fly.io describes how it built Fly Postgres as an automated database app rather than a managed database service. After initially resisting durable storage and database work, the company added attached disk storage and designed a deployable Postgres application with convenience commands, using Postgres streaming replication, Stolon, and Consul to support high availability. A two-node cluster can designate a writable leader and asynchronous standby, while Stolon’s sentinels, keepers, and proxies coordinate state, elect a replacement leader, and route connections; Consul introduces an additional failure mode. Backups use point-in-time, block-level snapshots of the volume, a platform capability that can also support other file-system databases. The post concludes that automated Postgres serves many apps, while managed database partnerships may suit users seeking a simpler experience.
Real-Time Collaboration with Replicache and Fly-Replay
Distributed real-time collaboration becomes difficult when a single server coordinating document changes is overloaded and documents must be split across machines without exposing routing complexity to clients. This demo combines Replicache, a custom WebSocket endpoint, Fly Machines, and the Fly-Replay header to route each document’s connection through a shared router to the machine responsible for that document. The server keeps connections by spaceID, sends initial and incremental state, and tracks messages already delivered; the client overrides Replicache’s push and pull handlers to exchange data through the persistent socket. The resulting application has React frontend, Express router, and Replicache/WebSocket backend layers, with each todo list assigned to one backend machine. The author cautions that the approach is demonstrated only in a basic demo and should receive serious production testing and tuning.
Logbook: November 7 to November 14, 2022
The November 7–14, 2022 logbook presents updates intended to make Elixir applications easier to deploy and monitor in production, alongside documentation and storage guidance. Mark’s contribution explains how to set up Github Actions for Elixir CI, including the work needed to automate deployment workflows. A separate guide uses OpenTelemetry to monitor a production Elixir deployment and trace an N+1 query performance problem, while the Django section reports community progress toward more comprehensive Fly documentation. The logbook also points to a MinIO deployment guide for self-hosted, S3-compatible object storage, noting that colocating storage in the same datacenter as an application can matter although using an S3 host such as AWS S3 is described as easier in some cases.
Logbook: October 29 to November 6, 2022
This weekly logbook covering October 29 through November 6, 2022 reports updates across Elixir, Postgres, Laravel Livewire, Redis, and Fly Machines. Chris McCord describes how React inspired Elixir LiveView, while revamped Elixir documentation and Livewire tutorials cover client-side pagination, grouping, sorting, and browser notifications from the server. Fly’s revised Postgres documentation distinguishes the tools it provides for provisioning and managing a cluster from the responsibilities customers retain, and points readers to managed Postgres services. The Fly Redis dashboard command opens the Upstash Redis console with instance statistics and connection instructions, while a Fly Machines preview supports defining multiple processes to run inside one container; the log also notes updated documentation and a required CLI version update.
A love letter to React
React’s 2013 release had a lasting impact on frontend development and influenced Phoenix LiveView through its reactive component model, JSX colocation, and efficiency. Chris McCord explains how a component’s state and render function create a simple programming model, then shows LiveView adapting that model to a stateful server process with HTML-aware function components and slots. The discussion argues that tightly coupled markup and code should live together, while extensible components preserve HTML structure and support customization without bespoke templates. For rendering efficiency, React computes virtual DOM diffs, whereas LiveView tracks static and dynamic HEEx template parts, sends minimal diffs over the network, and applies client-side patches with morphdom. The conclusion credits React with shaping Phoenix’s direction and argues that backend frameworks should provide HTML-aware component systems.
Logbook: October 21 to 28, 2022
This weekly Logbook changes format from tracking every monthly change to an over-generalized weekly tl;dr of Fly.io updates intended to help with deploying or managing apps. It reports new Postgres documentation for performing failovers, regional failovers, setting up and attaching a database, and migrating one from Heroku, while warning that Fly Postgres is not fully managed and requires customer monitoring. The post also points to an example of integrating the Elastic Stack (ELK) with a Laravel app for user analytics and reporting, plus instructions for shutting down an idle Phoenix app on Fly Machines after a configurable period without requests. It explains that newly launched Fly apps do not yet deploy to Machines in the same way, while fly pg create does use Fly Machines, and directs readers to comparisons of the app versions. Finally, it notes colorblind-friendly dashboard improvements and previews more Postgres documentation work.
Introducing LiteFS
LiteFS is an open-source distributed file system for SQLite that addresses the durability, replication, availability, and latency limitations of deploying SQLite on a single server. LiteFS interposes a FUSE pass-through filesystem between an application and its database, identifies transactions from SQLite’s journal files, packages page changes into LTX files, and ships them to replicas without requiring application-code changes. A Consul-backed, time-based lease elects a primary writer, while local replicas serve reads; checksum state embedded in each LTX file helps detect out-of-order application and preserve byte-for-byte consistency. Because replication is asynchronous, the design trades some durability guarantees for performance and operational simplicity, while defensive checksum checks address potential split-brain failure modes. The project is described as beta-ready, with WAL-mode support, write forwarding, S3 replication, and encryption listed as planned features.
Scale-to-Zero Minecraft server with Terraform and Fly Machines
This tutorial presents a scale-to-zero Minecraft Java server built with Terraform and Fly Machines. It addresses the cost and resource burden of keeping a multiplayer server running when nobody is playing, while allowing it to restart when a player connects. The configuration provisions a Fly.io app, a Firecracker-based machine using Geoff Bourne’s itzg/minecraft-server Docker image, a 15GB persistent Fly Volume, an IPv4 address, and exposed TCP port 25565. Environment variables enable Autostop with estimated and initial timeouts of 120 seconds, while the machine receives four shared vCPUs and 8GB of RAM and mounts world data at /data. After terraform apply, the machine shuts down after the timeout and automatically starts again when Minecraft reconnects, though any TCP traffic can wake it and incur costs.
How the SQLite Virtual Machine Works
SQLite processes SQL through a parse-optimize-execute pipeline that turns query text into executable virtual-machine instructions. It tokenizes characters, parses them into an AST such as a Select struct, and uses table statistics to choose between a full table scan and index-based access. The source describes sqlite_stat1's coarse index and duplicate-value counts alongside sqlite_stat4's distributed samples, then traces bytecode that opens the persons table, compares favorite_color with "blue", and returns matching columns. Registers hold intermediate values, cursors iterate through tables, and sqlite3_step() resumes execution after each returned row; the VM has 186 opcodes as of writing, while bind parameters allow prepared statements to skip repeated parsing and optimization.
How SQLite Scales Read Concurrency
SQLite’s write-ahead log (WAL) is presented as the mechanism that overturns the common claim that SQLite is inherently single-user or unable to scale reads. Unlike the rollback journal, which blocks readers and writers from operating at the same time, WAL leaves original database pages in place and appends changed pages to a -wal file, allowing point-in-time snapshots to coexist with ongoing writes. SQLite tracks those entries in a shared-memory (SHM) index: 32KB blocks contain page-number lists and 8,192-slot hash maps, with slot positions calculated as (pgno * 383)%8192 while transaction position determines visibility. The post concludes that WAL mode benefits most applications, while noting that rollback journaling can remain preferable for edge cases such as multi-database transactions.
Building an In-Browser IDE the Hard Way
This tutorial builds a personal remote development environment: an in-browser IDE for Elixir/Phoenix work, deployed as a Fly Machine from a Dockerfile and managed with command-line tools. The image uses an official Elixir base, adds code-server, flyctl, build dependencies, and the Elixir Language Server extension, while a multi-stage build copies in Tired Proxy. A persistent volume holds working files, and the startup configuration can clone a repository, launch code-server behind HTTPS, and arrange for the machine to sleep after an hour without HTTP requests. From the IDE terminal, the walkthrough then creates and deploys a separate Phoenix hello-world application backed by SQLite, setting its secret and provisioning storage. The resulting setup can wake on browser access, but random HTTP traffic or an active code-server terminal may keep it running, and stopping or destroying the apps limits costs.
How SQLite helps you do ACID
SQLite’s rollback journal provides atomicity, isolation, and durability by preserving database state before a transaction changes the main file. Without journaling, an interrupted 4KB page write could corrupt the database; the journal instead records original pages, then permits recovery if commit steps fail. A journal header stores a nonce, the database’s pre-transaction page count, sector size, and page size, while each page record includes its page number, a copy of prior contents, and a 32-bit checksum. The mode allows concurrent readers but makes writers wait for readers and blocks new readers, using SHARED, RESERVED, and PENDING filesystem locks. Its simplicity brings a concurrency bottleneck; WAL and wal2 provide better support for concurrent readers, which the post says will be covered next.
Volume Expansion and Snapshot Restores
Fly.io introduces two improvements to its persistent storage volumes: extending an existing volume and restoring a regular volume from a snapshot. Previously, increasing capacity required provisioning an empty volume and copying data, whereas the new fly volume extend command resizes it after the attached app restarts; regular apps restart automatically, while Machines VMs require manual restarts. Individual restores are available from flyctl v0.0.363 by supplying --snapshot-id when creating a new volume, after listing snapshots and selecting the desired ID. Snapshots are taken daily, stored in object storage for five days, and can restore data only to a volume at least as large as the source.
SQLite Internals: Pages & B-trees
SQLite stores table rows as encoded byte arrays, and understanding that representation explains how a simple database preserves compact records and supports efficient growth. Using a sandwich table as an example, the post decodes a row’s varints, type values, UTF-8 text, IEEE-754 floating-point value, and integer count, then examines 4KB pages, cell-pointer indexes, and page headers. SQLite’s b+tree places records in leaf pages and key-range indexes in interior pages; page splits add levels as the database grows, while searches traverse only one page per tree level. The examples estimate that a depth-four tree can hold about 500³ leaf pages, or roughly 476GB, while requiring four page reads for a lookup. The discussion concludes that integer storage is more space-efficient than floating-point storage and that internals such as record encoding and PRAGMAs become less opaque when understood.
Launching Laravel Bytes
Fly is launching Laravel Bytes, a new publication focused on Laravel and on deploying Laravel applications across the globe. The announcement frames the site as a place for future discussions of global-user-base considerations, along with Laravel tips, strategies, how-tos, and coverage of Livewire and real-time apps. Laravel is supported by the fly launch command, and the documented quick start is to enter an existing Laravel app directory and run fly launch. A more comprehensive guide covers running Laravel on Fly with Redis, MySQL, queue workers, and cron tasks, while the post directs readers to deployment documentation and says a Laravel app can be launched in a few minutes.
How LiveView Took on a Life of Its Own
Phoenix LiveView began as an attempt to build dynamic server-rendered applications without writing JavaScript, using the server for interactions such as realtime reservation updates. Its initial design used stateful Phoenix Channels, a WebSocket connection, client event bindings, and full template re-renders sent back as HTML, a model that worked but produced redundant server work and large payloads. Adding Phoenix PubSub let LiveViews subscribe to reservation events and update all connected browsers through ordinary Elixir callbacks, without client changes. The implementation then evolved around diffing dynamic values, shared static template references, and cached live component templates, reducing transferred data and avoiding growing client bundles. The post concludes that this programming model sidesteps HTTP for dynamic features, with compact payloads and less client-side code.
Logbook - 2022-07-18
This Logbook entry records Fly.io product, platform, documentation, and interface changes on 2022-07-18. Highlights include $99 in usage credits for the Pro Plan, SOC2 compliance, persistent-volume expansion through fly volumes extend, SFTP access to apps over 6PN and WireGuard, and routing changes intended to improve latency. flyctl gained debug JSON formatting, expanded machine-app deployment and status commands, preserved mounted volumes during deployments, and added rolling deploys that wait for each VM to start. The entry also describes fixes for autoscaling, the Fly Redis image, GraphQL validation, Phoenix launches, and dashboard presentation, alongside updated Laravel and persistent-volume documentation and improved Heroku token-failure emails.
SOC2: The Screenshots Will Continue Until Security Improves
Fly.io’s SOC2 certification prompts an explanation of what the audit measures, when companies should pursue it, and what security value customers should assign to it. The post characterizes SOC2 as an accounting-style audit of documented company security processes, centered on an auditor-customized Document Request List (DRL) and screenshots, rather than adversarial product testing. It distinguishes Type I’s point-in-time snapshot from Type II’s multi-month confirmation and recommends doing the engineering work early, while delaying certification until customer demand justifies it. Fly.io prepared for more than a year and describes controls including Google SSO, certificate-based SSH access through Teleport, VPN gating, GitHub SSO, and session audit logs. The resulting certification improved processes but remains a weak positive security signal: SOC2 can miss much of a company’s technical security model, so penetration tests and clear security reporting still matter.
The Serverless Server
The post explains what “serverless” means by reconstructing the machinery beneath a Lambda-like platform. It starts with bare-metal x86 servers, a Type 1 hypervisor, and services for placement, VM management, request forwarding, and function execution; dedicated customer workers, shared warm pools, rate limits, and container-style isolation address multitenancy, cold starts, and bursty demand. The runtime design uses object storage for function code, chroot, privilege dropping, namespaces, seccomp, cgroups, and freezing to constrain idle instances and workloads. Its limits on initialization, invocation duration, and idle lifecycles support migration away from unhealthy instances but disadvantage applications with expensive startup, dynamic local caches, or uncertain response times.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.