Fly.io

All Fly.io integration capabilities

About

Fly.io has no managed log-drain API, so you deploy a log shipper app inside your Fly organization. The shipper reads Fly's internal NATS log stream and forwards logs from every app in the organization to your Sazabi intake URL.

Two shipper options are available depending on your preference.

Prerequisites

• A Fly.io organization with at least one deployed app
• The flyctl CLI authenticated and configured for your organization
• Your Sazabi intake URL and shipper token — add the Fly.io log source in Settings > Log streams and copy both from its setup screen. The intake URL already identifies your log source; the shipper also sends the token because Fly's shipper requires one.

Set up in the dashboard

Option A: fly-log-shipper (recommended)

Deploy the superfly/fly-log-shipper app into your organization and configure it to forward to Sazabi:

fly secrets set \
  -a <shipper-app-name> \
  HTTP_URL="<your intake URL>/fly-log-shipper" \
  HTTP_TOKEN="<your shipper token>"

Replace <shipper-app-name> with the name of your shipper app, <your intake URL> with the intake URL from the setup screen (keep the /fly-log-shipper path suffix), and <your shipper token> with the HTTP_TOKEN value from the same screen.

The shipper connects to Fly's internal NATS log stream and begins forwarding logs from all apps in the organization.

Option B: Dedicated OTLP Vector app

For richer OTLP resource attributes, deploy a dedicated Vector app inside your Fly organization that reads from the Fly NATS log stream, wraps each event in an OTLP resourceLogs envelope, and POSTs it to your intake URL with the /v1/logs suffix. Send the shipper token from the setup screen as a bearer token.

See Vector setup for the OTLP sink configuration pattern.

Hand off the change

If this configuration is version-controlled, commit it on a new branch, push it, and open a pull request. Otherwise apply it directly to your shipper app. Keep the intake URL and any keys in environment variables or a secret store, and commit only configuration that references them.

Set up with the CLI

You can also register the Fly.io log source with the Sazabi CLI (installed and authenticated — see CLI reference):

sazabi log-sources create fly_io --mode manual

The command prints the intake URL and the token for the new source — set HTTP_URL to the intake URL and HTTP_TOKEN to the token using the configuration shown above. Run sazabi log-sources get <log-source-id> at any time to reprint them, or sazabi log-sources list to see every log source in the project.

Verify

After deploying the shipper app, trigger activity in one of your Fly apps (for example, make an HTTP request to a service). Open the Intake page in the Sazabi dashboard and confirm records from the Fly.io source appear within a minute or two.

Troubleshooting

No records after deploying the shipper — Check the shipper app logs with fly logs -a <shipper-app-name>. Look for authentication errors or connection failures when connecting to the NATS log stream or the Sazabi intake endpoint.

HTTP_TOKEN misconfigured — HTTP_TOKEN must be the token from the Fly.io log source's setup screen, not a Fly.io API token.

Only some apps forwarding — The fly-log-shipper connects to the organization-level NATS stream, which includes logs from all apps in the organization. If some apps are not appearing, confirm the shipper app is in the same Fly organization as those apps.

Further reading