Fly.io
Connect your Fly.io organization so Sazabi can discover your apps and provision a dedicated intake URL for each one.
About
Fly.io has no managed log-drain API, so a log shipper must run inside your Fly organization to read Fly's internal log stream and forward it to Sazabi. Connecting your Fly.io account lets Sazabi discover your apps and provision a per-app intake URL — you still run the shipper yourself.
Fly.io also has a Send to an endpoint path where you set up the shipper without connecting an account. See Fly.io endpoint page for that setup.
Prerequisites
- A Fly.io organization with at least one app.
- A read-only organization token scoped to the organization you want to monitor.
- A place to run a log shipper inside that same Fly organization — the shipper must be in the same org to read Fly's internal NATS log stream.
Set up in the dashboard
Create a read-only organization token
Create the token using either the Fly CLI or the Fly.io dashboard.
CLI:
flyctl tokens create readonly -o <org-slug>Dashboard: Open the org's Tokens tab in your Fly.io dashboard and create a read-only token.
Copy the token; it starts with FlyV1 .
Connect in Sazabi
Go to Settings > Log streams, click Add source, and select Fly.io. Enter your API token and your organization slug (the short name visible in your Fly dashboard URL), then click Connect. Sazabi validates the token by listing apps for the organization.
Add log streams
After the connection is confirmed, click Add log stream to open the app picker. Select the apps you want to forward. Sazabi provisions a per-app intake URL for each selected app.
Configure the log shipper
The shipper must run inside your Fly organization. Configure it to send logs to the intake URL Sazabi provides. The two supported formats are:
fly-log-shipper (simplest): Use the stock superfly/fly-log-shipper image with its generic http sink. Set HTTP_URL to the intake URL (including the /fly-log-shipper path suffix) and HTTP_TOKEN to the Sazabi public key as a bearer token.
Dedicated OTLP Vector shipper (richer attributes): Build a Vector app that wraps events in an OTLP resourceLogs envelope and POSTs to the OTLP logs endpoint with the public key as a bearer token.
Set up with the CLI
You can also connect the Fly.io log source with the Sazabi CLI (installed and authenticated — see CLI reference).
Create a managed connection by passing your read-only organization token and org slug as metadata:
sazabi log-sources create fly_io --mode managed \
--metadata '{"apiToken":"'"$FLY_API_TOKEN"'","organizationSlug":"<your org slug>"}'Sazabi validates the token against the Fly.io API for that organization and creates the log source; note the log source ID it prints.
Add a log stream — one per Fly app — with sazabi log-streams create, passing the Fly app name in --config:
sazabi log-streams create --log-source-id <log-source-id> \
--config '{"appName":"<your Fly app name>"}'Run sazabi log-sources list to confirm the source and its streams.
Verify
Deploy or send traffic to a connected Fly app, or redeploy the log shipper to confirm it is receiving events.
Open the Intake page in the Sazabi dashboard and confirm that records attributed to the Fly.io source appear. Logs typically arrive within one to two minutes after the shipper starts forwarding them.
Troubleshooting
Token validation fails — Confirm the token is a read-only organization token (not a personal or deploy token) and that the organization slug matches the org the token was issued for.
No apps appear in the picker — Verify the organization slug is correct. If the org has no apps, create one in Fly.io first.
Logs not arriving after shipper is deployed — Confirm the shipper app is running in the same Fly organization as the apps you want to monitor. The shipper reads Fly's internal NATS log stream, which is org-scoped.
HTTP_URL path matters — When using fly-log-shipper, the HTTP_URL must include the /fly-log-shipper path suffix. Omitting it causes intake to attempt OTLP parsing on the native Fly event format, which will fail.