How is Fluent Bit's config format different from Fluentd's?

Fluent Bit uses a flat, INI-like [SECTION] format with Key Value pairs (no nested XML-like tags), which is intentionally simpler to parse since Fluent Bit is written in C and designed to run with a much smaller footprint than Fluentd, making it a common choice as a per-node or per-container log forwarder feeding a heavier Fluentd or Elasticsearch aggregator.

When should I use the systemd input instead of tail?

Use systemd when you need to collect logs directly from journald (for example a systemd-managed service like docker.service or a specific unit), since it reads structured journal entries rather than a plain text file. Use tail when your application writes to a conventional log file on disk.

What does the optional TLS block actually do?

When enabled, it appends tls On, tls.verify On/Off, and tls.ca_file to the [OUTPUT] section, which is how Fluent Bit encrypts and (optionally) verifies the connection to a remote destination like a hosted Elasticsearch or Loki endpoint over HTTPS.

Does the kubernetes filter automatically detect my cluster?

No, this generates only the Match pattern and Merge_Log toggle; the Kubernetes filter plugin needs additional runtime configuration (like the Kubernetes API server URL and service account token) that Fluent Bit normally reads automatically when running inside a pod, which this browser-based generator can't detect.

Fluent Bit Config Generator - Build fluent-bit.conf Visually

Overview

Introduction

Fluent Bit's classic configuration format is flat [SECTION] blocks of Key Value pairs, but it's still easy to mismatch an [OUTPUT]'s Match pattern against your [INPUT]'s Tag, or forget one of the fields a specific output plugin requires.

This tool builds a fluent-bit.conf from a form: choose an input, a filter, an output, and optionally a TLS block, and the sections come out with consistent tags and correctly named keys every time.

What Is Fluent Bit Config Generator?

A visual builder for fluent-bit.conf files covering the four sections a working pipeline needs: [SERVICE] (global Flush/Daemon/Log_Level settings), [INPUT] (tail or systemd), [FILTER] (kubernetes or grep), and [OUTPUT] (es, loki, or stdout), with an optional TLS block appended to the output.

It follows Fluent Bit's classic mode syntax (as opposed to the newer YAML configuration format), which remains the most widely deployed format in existing Fluent Bit installations and documentation.

How Fluent Bit Config Generator Works

Each section is emitted as a [SECTION] header followed by indented Key Value lines. The tail input's Tag and the filter/output's Match pattern are kept as separate fields you control directly, matching how Fluent Bit actually resolves routing (Match patterns support wildcards against Tag values).

The output section always includes Name and Match first, then that output type's specific fields (Host/Port/Index for es, Host/Port/Labels for loki, or none for stdout beyond Name/Match); if TLS is enabled, three additional tls.* keys are appended directly under the same [OUTPUT] section, matching how Fluent Bit expects transport security configured per-output.

When To Use Fluent Bit Config Generator

Use it when deploying Fluent Bit as a lightweight per-node or per-container log shipper, for example as a DaemonSet sidecar in Kubernetes forwarding container logs to a central Elasticsearch or Loki.

It's also useful for quickly sketching a TLS-enabled output block, since the exact tls.* key names are easy to get wrong from memory.

Often used alongside Fluentd Config Generator.

Features

Advantages

Produces Fluent Bit's actual classic [SECTION] syntax with correct key names per input/filter/output type, not a generic placeholder structure.
Covers the TLS block as a distinct, optional addition, since production deployments shipping to a hosted Elasticsearch or Loki endpoint almost always need it.
Keeps [SERVICE] global settings (Flush, Daemon, Log_Level) separate from the per-pipeline sections, matching how Fluent Bit itself separates global daemon behavior from data pipeline configuration.

Limitations

Only models one [INPUT], one [FILTER], and one [OUTPUT]; real deployments often chain multiple filters or fan out to multiple outputs, which this generator doesn't build.
Doesn't generate the newer YAML-based Fluent Bit configuration format, only the classic [SECTION] format.
The Kubernetes filter's Match and Merge_Log are the only fields generated; other Kubernetes filter options (like K8S-Logging.Parser or Annotations) need manual editing after generating.

Examples

Tailing a log file into Elasticsearch with TLS

Input

input: tail, path /var/log/app.log, tag app.*; filter: grep, match app.*, regex log_level ERROR; output: es, host es.example.com, port 9200, index app-logs; tls: on, verify on

Output

[SERVICE]
    Flush       5
    Daemon      Off
    Log_Level   info

[INPUT]
    Name    tail
    Path    /var/log/app.log
    Tag     app.*

[FILTER]
    Name    grep
    Match   app.*
    Regex   log_level ERROR

[OUTPUT]
    Name         es
    Match        *
    Host         es.example.com
    Port         9200
    Index        app-logs
    tls          On
    tls.verify   On
    tls.ca_file  /etc/ssl/certs/ca.pem

The grep filter only forwards records matching the regex, and the TLS keys are appended directly under the same [OUTPUT] section.

Best Practices & Notes

Best Practices

Keep [INPUT] Tag values specific and hierarchical (like app.access, app.error) so [FILTER] and [OUTPUT] Match patterns can target them precisely with wildcards.
Enable tls.verify in production; only disable it for local testing against a self-signed endpoint.
Set Daemon to Off when running under a supervisor like systemd or Docker, since those expect the process to stay in the foreground.

Developer Notes

The generator emits Fluent Bit's classic [SECTION] format as plain text using a small kv() helper that pads key names for readable column alignment, matching the style used throughout Fluent Bit's own documentation; the format itself is whitespace-insensitive so the padding is cosmetic only. Validation confirms each section's required fields are present (e.g. Path+Tag for tail, Host+Index for the es output) before generating, but does not attempt to open a network connection.

Fluent Bit Config Generator Use Cases

Configuring Fluent Bit as a Kubernetes DaemonSet log shipper collecting container logs
Setting up a systemd-based input to forward a specific unit's journal entries to a central log store
Producing a TLS-enabled output block to send logs securely to a hosted Elasticsearch or Loki endpoint

Common Mistakes

Setting an [OUTPUT] Match pattern that doesn't align with the [INPUT] Tag, causing the output to silently receive nothing.
Enabling TLS without setting tls.verify appropriately for the environment, leaving certificate verification off in production.
Using Daemon On during local testing, which detaches the process and hides log output from the terminal.

Tips

Use the Fluentd Config Generator afterward if this Fluent Bit instance is meant to forward into a central Fluentd aggregator rather than directly to Elasticsearch or Loki.
Start with Log_Level debug while testing a new pipeline, then switch back to info once it's confirmed working.

Fluent Bit Config Generator