Fly.io

About

You can also connect your Fly.io account to Sazabi and have Sazabi discover apps and configure per-app log keys automatically. See Fly.io (connect your account) for that path.

This page covers the manual endpoint configuration: deploy a log shipper app inside your Fly organization that reads from Fly's internal NATS log stream and forwards logs to Sazabi. Fly.io has no managed log-drain API, so a shipper app is the standard approach.

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, shown above — open the log source at Settings > Log streams and copy the Intake URL from its setup screen. On this path Fly's shipper sends the public key as a bearer token, so also grab your project public key from Settings > Public keys.

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="<SAZABI_PUBLIC_KEY>"

Replace <shipper-app-name> with the name of your shipper app, <your intake URL> with the full intake URL shown above; keep the /fly-log-shipper path suffix, and <SAZABI_PUBLIC_KEY> with your project public key from Settings > Public keys.

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 same Sazabi project public key (from Settings > Public keys) as a bearer token.

See Vector setup for the OTLP sink configuration pattern.

Set up with the CLI

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

Registering the source mints the same intake URL and public key the dashboard shows above (Fly's shipper needs the key as a bearer token, so this path prints both):

sazabi log-sources create fly_io --mode connectionless

The command prints the intake URL and public key for the new source — set HTTP_URL to the intake URL and HTTP_TOKEN to the public key 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 — The HTTP_TOKEN secret must be your Sazabi project public key (from Settings > Public keys), not a Fly.io API token. Sazabi uses the token to authenticate the shipper.

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