---
title: "Playing Traffic Cop with Fly-Replay"
description: "Fly.io’s fly-replay response header lets the Fly Proxy replay an HTTP request on another app, region, or VM within the same organization. The post explains how this can send writes near a leader database, preserve request locality after uploads, wake Machines stopped on exit, or route customer traffic across apps. It then builds a small Go reverse-proxy application that looks up the request hostname in SQLite and returns either app=our-default-app or the registered customer’s app in the header. Local request handling and lookup took about 4 ms, while the real-world proxy-and-replay path added about 100 ms; private customer apps remained reachable because Fly services can be defined without public IP addresses. The post also mentions LiteFS and internal DNS as possible discovery mechanisms."
---

# Playing Traffic Cop with Fly-Replay

[Fly.io](https://yomu.fyi/company/fly-io) · May 15, 2023

**Type:** Tutorial

## Summary

Fly.io’s fly-replay response header lets the Fly Proxy replay an HTTP request on another app, region, or VM within the same organization. The post explains how this can send writes near a leader database, preserve request locality after uploads, wake Machines stopped on exit, or route customer traffic across apps. It then builds a small Go reverse-proxy application that looks up the request hostname in SQLite and returns either app=our-default-app or the registered customer’s app in the header. Local request handling and lookup took about 4 ms, while the real-world proxy-and-replay path added about 100 ms; private customer apps remained reachable because Fly services can be defined without public IP addresses. The post also mentions LiteFS and internal DNS as possible discovery mechanisms.

## Context

The Fly Proxy can replay requests according to a fly-replay response header, but the post focuses on using that behavior to route wildcard-domain traffic to customer-specific apps while keeping those apps private. It also describes routing requests near a leader database, to particular VMs, or across regions.

## Approach / What changed

A small Go HTTP application matches each request hostname against a SQLite customers table, then sets fly-replay to the customer’s app or a default app. Customer apps are created without public IP addresses while their services remain discoverable by the Fly Proxy. LiteFS and Fly internal DNS are presented as alternative approaches for distributed app discovery.

## Takeaways

- fly-replay can target a region, app, or VM, but replaying requests works only between sending apps in the same Fly.io organization.
- The proxy uses Go’s root HTTP handler, which prefix-matches every URI, and a SQLite lookup keyed by the request’s Host header to select the destination app.
- Creating Machines-based apps with --no-public-ips keeps customer apps private while still allowing the Fly Proxy to replay requests to their defined services.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Go](https://yomu.fyi/topic/go), [SQLite](https://yomu.fyi/topic/sqlite)

- Source: [Fly.io](https://fly.io/blog/how-to-fly-replay)
- Source URL: https://fly.io/blog/how-to-fly-replay
- Ingested by Yomu: 2026-09-02T11:59:53.316Z

[Read original post](https://fly.io/blog/how-to-fly-replay)