Pydantic Logfire Fleet lets teams change telemetry settings live

Live controls for running services

The guide connects a FastAPI service called checkout-api to Fleet using the Logfire SDK. The service is configured with fleet=True, although setting LOGFIRE_FLEET=true provides the same behavior without a code change. Fleet support requires Logfire 5.5.0 or later with the fleet extra.

After the application is added in the Fleet management interface, it receives a Fleet connection key and uses the OTEL_OPAMP_ENDPOINT and OTEL_OPAMP_HEADERS environment variables. The application continues sending telemetry with its existing write token, while the connection key manages settings.

Pydantic says the same steps also work with Node.js, Java, .NET and Go, with language-specific installation and startup changes. If no Fleet endpoint is available, the application warns and runs unmanaged, allowing the code to be deployed before Fleet settings are configured.

Filtering, redaction and sampling without a restart

In the example, checkout-api is producing debug logs, recording a card token on a span and handling a sudden increase in traffic. From the SDK policy, an operator can set the minimum log level to Warn. According to Pydantic, debug and info records stop arriving in the Live view within seconds, while the process keeps running. Fleet drops those records during export, so a later policy can restore them.

The policy can also mask attributes matching *token*. The SDK replaces matching values with [REDACTED] before exporting the span, meaning the value does not reach Logfire or another backend used by the SDK. A separate scrubbing feature can match values as well as keys.

For traces, the example sets a sampling rate of 10% and adds a rule that drops /health* traces entirely. The first matching rule determines a new trace's rate, while spans with sampled parents remain sampled so traces stay whole. Traces that are not sampled never reach Logfire.

Collectors, staged rollouts and operational visibility

Fleet also manages an OpenTelemetry Collector on a Linux host. The guide adds host monitoring, then changes the Collector policy to collect nginx log files from /var/log/nginx/*.log. The Collector installs as a service, and a version it cannot run is rejected while its current configuration remains active. Fleet reports the failure reason.

Rollouts are currently in early access. When enabled, a published policy is sent to no instances until an operator starts a rollout, which can begin with a selected number of instances. Fleet tracks instances that applied the version and those that failed. Operators can expand the rollout or restore an earlier policy version.

For Kubernetes, Fleet provides a bridge that drives the OpenTelemetry Operator. Existing Collectors can instead be connected in report-only mode, allowing Fleet to show their health, components and running configuration without changing that configuration. Overview compares Collector volume with the preceding period, while Flows shows where data is received and sent.

What this means for Logfire users

The guide presents Fleet as a way to respond to changing telemetry needs without waiting for an application deployment or restarting a service. Teams can reduce log and trace volume, protect sensitive attributes and test policy changes on a small group of instances. Pydantic also emphasizes that Fleet does not carry telemetry itself, so users still need the correct write token and region when troubleshooting missing data.