This page gives a quick user-focused overview of the main changes in the Fluent Bit v5 line, grouped by minor release with the newest release first.
For migration-impacting changes, see Upgrade notes.
Fluent Bit v5.1 focuses on network ingestion throughput, adds several new inputs and outputs, and hardens TLS and FIPS compliance options.
The TCP, UDP, and Forward inputs add a workers setting that lets a single listener accept and decode traffic across multiple worker threads. This mirrors the shared HTTP listener worker support introduced for HTTP-based inputs in v5.0.
The OpenTelemetry input reduces allocation overhead when decoding large batched Protobuf payloads, improving throughput for high-volume OTLP/HTTP workloads. There's no new configuration setting for this: it applies automatically to payloads over an internal size threshold.
Every input plugin can now enable a rate gate to pause ingestion once it exceeds a configured byte or record rate, and resume once the rate falls back under a hysteresis threshold. See rate_gate and rate_window in Buffering.
Fluent Bit can start in FIPS mode with --enable-fips, which validates on startup that the linked OpenSSL library has an active FIPS provider. This blocks non-FIPS-approved hashes, such as MD5, in outputs like Amazon S3 and Azure Blob. See Configuring Fluent Bit.
TLS-enabled inputs and outputs now detect changes to their configured certificate and key files and reload them automatically, without a restart. See Certificate reload.
Output plugins connecting through an HTTPS proxy can now configure the proxy leg's certificate verification independently from the destination's own TLS settings, using tls.proxy.ca_file, tls.proxy.ca_path, tls.proxy.verify, and tls.proxy.verify_hostname. See HTTP proxy.
The Syslog output mode setting now accepts tls and dtls, both of which automatically enable TLS, in addition to the existing tcp and udp values. Datagram Transport Layer Security (DTLS) over UDP is supported for the first time.
The Event Tracing for Windows input collects events from ETW providers or the Windows kernel logger on Windows hosts.
The GPU metrics input adds NVIDIA GPU collection through NVML, including automatic discovery of Multi-Instance GPU (MIG) devices, alongside its existing AMD support.
The Node Exporter Metrics input adds:
- a
timexcollector foradjtimex(2)system call statistics on Linux, enabled by default - macOS support for the
filesystemcollector TcpExtandIpExtcounters in thenetstatcollector
The Google Cloud Storage output uploads records to a GCS bucket with service-account OAuth 2.0 authentication and optional gzip compression.
The Kafka output can resolve Avro schemas directly from a Confluent Schema Registry with schema_registry_url and related settings, instead of requiring a schema to be configured inline.
The File output adds size-based log rotation with rotate, rotate_max_size, and rotate_max_files, with optional gzip compression through rotate_gzip.
The output name elasticsearch is now a built-in alias for the Elasticsearch output plugin es, so either name works in configuration files.
Windows container images add a Server Core variant for Windows Server 2025 and a new, smaller Nano Server variant. See Docker.
Upgrading the fluent-bit Debian or Ubuntu package now reloads systemd unit files and restarts an already-running service. See Debian and Ubuntu.
Event timestamps at or after the 2038 32-bit time_t rollover now round-trip correctly through the internal msgpack EventTime encoding that Fluent Bit uses, instead of overflowing.
Fluent Bit v5.0 adds new inputs and processors, expands authentication and TLS options, and standardizes configuration for HTTP-based plugins. It also delivers an important round of performance and scalability work, especially for pipelines that ingest logs, metrics, and traces through HTTP-based protocols. This section gives a quick user-focused overview of the main changes since Fluent Bit v4.2.
Fluent Bit v5.0 continues the move toward a more unified runtime for logs, metrics, and traces. In practice, this means the same core engine improvements benefit more of the pipeline, instead of individual signal paths evolving separately.
For end users, the result is a more consistent behavior across telemetry types and a better base for high-throughput pipelines that mix logs, metrics, and traces in the same deployment.
One of the most important v5.0 changes is the refactoring of the HTTP listener stack used by several input plugins. Fluent Bit now uses a shared HTTP server implementation across the major HTTP-based receivers instead of maintaining separate code paths.
This work improves:
- concurrency through shared listener worker support
- consistency of request handling across HTTP-based inputs
- buffer enforcement and connection handling
- maintainability, which reduces drift between plugin implementations
The biggest user-facing beneficiaries are:
If you run large HTTP or OTLP ingestion workloads, v5.0 isn't only a feature release. It's also a meaningful runtime improvement.
HTTP-based inputs now use a shared listener configuration model. The preferred setting names are:
http_server.http2http_server.buffer_chunk_sizehttp_server.buffer_max_sizehttp_server.max_connectionshttp_server.workershttp_server.ingress_queue_event_limithttp_server.ingress_queue_byte_limit
Legacy aliases such as http2, buffer_chunk_size, and buffer_max_size still work, but new configurations should use the http_server.* names.
Affected plugin families include:
Input plugins that support TLS can now require client certificate verification with tls.verify_client_cert. This makes it easier to run mutual TLS (mTLS) directly on Fluent Bit listeners.
See TLS.
The built-in HTTP server exposes /api/v2/health, which returns health status as JSON and uses the HTTP status code to indicate healthy (200) or unhealthy (500) state.
See Monitoring.
The Fluent Bit logs input routes Fluent Bit internal logs back into the pipeline as structured records. This lets you forward agent diagnostics to any supported destination.
The HTTP input adds:
add_remote_addrremote_addr_key
These settings let you attach the client address from X-Forwarded-For to each ingested record.
HTTP-based receivers can validate incoming bearer tokens with:
oauth2.validateoauth2.issueroauth2.jwks_urloauth2.allowed_audienceoauth2.allowed_clientsoauth2.jwks_refresh_interval
This is available on the relevant input plugins, including HTTP and OpenTelemetry.
The OpenTelemetry input in v5.0 expands user-visible behavior with:
- shared HTTP listener worker support
OAuth 2.0bearer token validation- stable JSON metrics ingestion over
OTLP/HTTP - improved JSON trace validation and error reporting
The Kubernetes events input documents additional SQLite controls:
db.journal_modedb.locking
These settings help tune event cursor persistence and database access behavior.
The cumulative to delta processor converts cumulative monotonic metrics to delta values, which helps when scraping Prometheus-style metrics but exporting to backends that expect deltas.
The topological data analysis processor adds a metrics processor for topological data analysis workflows.
The sampling processor adds legacy_reconcile for tail sampling, which helps compare the optimized reconciler with the previous behavior when validating upgrades.
The HTTP output now supports built-in OAuth 2.0 client credentials with:
basicpostprivate_key_jwt
You can configure token acquisition directly in Fluent Bit with the oauth2.* settings.
Several outputs gained additional compression support in the v4.2 to v5.0 range:
- Amazon Kinesis Data Streams:
gzip,zstd,snappy - Amazon Kinesis Data Firehose:
snappyadded alongside existing codecs - Amazon S3:
snappyadded alongside existing codecs - Azure Blob:
zstdsupport for transfer compression
The fluentbit_hot_reloaded_times metric changed from a gauge to a counter, which makes it safe to use with PromQL functions such as rate() and increase().
v5.0 adds output backpressure duration metrics so you can observe time spent waiting because of downstream pressure.
See Monitoring.