> For the complete documentation index, see [llms.txt](https://docs.fluentbit.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fluentbit.io/manual/data-pipeline/inputs/mqtt.md).

# MQTT

{% hint style="info" %}
**Supported event types:** `logs`
{% endhint %}

The *MQTT* input plugin retrieves messages and data from MQTT control packets over a TCP connection. The incoming data to receive must be a JSON map.

## Configuration parameters

The plugin supports the following configuration parameters:

| Key           | Description                                                                                               | Default   |
| ------------- | --------------------------------------------------------------------------------------------------------- | --------- |
| `buffer_size` | Maximum payload size (in bytes) for a single MQTT message.                                                | `2048`    |
| `listen`      | Listener network interface.                                                                               | `0.0.0.0` |
| `payload_key` | Field name where the MQTT message payload will be stored in the output record.                            | *none*    |
| `port`        | TCP port where listening for connections.                                                                 | `1883`    |
| `threaded`    | Indicates whether to run this input in its own [thread](/manual/administration/multithreading.md#inputs). | `false`   |

{% hint style="info" %}

* `buffer_size` defaults to `2048` bytes; messages larger than this limit are dropped.
* Defaults for `listen` and `port` are `0.0.0.0` and `1883`, so you can omit them if you want the standard MQTT listener.
* Payloads are expected to be JSON maps; non-JSON payloads will fail to parse.
* In v5.1.3 or later, the plugin closes the connection when it receives a `PUBLISH` packet with an invalid QoS level (`3`), or when it can't write a reply to the client.
  {% endhint %}

### TLS / SSL

The MQTT input plugin supports TLS/SSL. For the available options and guidance, see [Transport Security](/manual/administration/transport-security.md).

## Get started

To listen for MQTT messages, you can run the plugin from the command line or through the configuration file.

### Command line

The MQTT input plugin lets Fluent Bit behave as a server. Dispatch some messages using a MQTT client. In the following example, the `mosquitto` tool is being used for the purpose:

Running the following command:

```shell
fluent-bit -i mqtt -t data -o stdout -m '*'
```

Returns a response like the following:

```
...
[0] data: [1463775773, {"topic"=>"some/topic", "key1"=>123, "key2"=>456}]
...
```

The following command line will send a message to the MQTT input plugin:

```shell
mosquitto_pub  -m '{"key1": 123, "key2": 456}' -t some/topic
```

### Configuration file

In your main configuration file append the following:

{% tabs %}
{% tab title="fluent-bit.yaml" %}

```yaml
pipeline:
  inputs:
    - name: mqtt
      tag: data
      listen: 0.0.0.0
      port: 1883
      payload_key: payload

  outputs:
    - name: stdout
      match: '*'
```

{% endtab %}

{% tab title="fluent-bit.conf" %}

```
[INPUT]
  Name   mqtt
  Tag    data
  Listen 0.0.0.0
  Port   1883
  Payload_Key payload

[OUTPUT]
  Name   stdout
  Match  *
```

{% endtab %}
{% endtabs %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.fluentbit.io/manual/data-pipeline/inputs/mqtt.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.