apache · kparisa · Sep 3, 2026 · Sep 3, 2026 · Sep 3, 2026
diff --git a/content/docs/ai/introduction.mdx b/content/docs/ai/introduction.mdx
@@ -1,5 +1,6 @@
 ---
 title: Introduction
+description: "The AI-related components of Apache Iggy, and where the MCP server is documented."
 ---
 
 This module contains the AI-related components of the Apache Iggy message streaming infrastructure.

diff --git a/content/docs/ai/mcp.mdx b/content/docs/ai/mcp.mdx
@@ -1,5 +1,6 @@
 ---
 title: MCP Server
+description: "Run and configure the Apache Iggy MCP server, including transport, Iggy credentials and TLS."
 ---
 
 The [Model Context Protocol](https://modelcontextprotocol.io) (MCP) is an open protocol that standardizes how applications provide context to LLMs. The Apache Iggy MCP Server is an implementation of the MCP protocol for the message streaming infrastructure. It is built using the `rmcp` crate and supports both **stdio** and **HTTP** transports.

diff --git a/content/docs/binary-protocol/cluster.mdx b/content/docs/binary-protocol/cluster.mdx
@@ -1,5 +1,6 @@
 ---
 title: Server-to-server
+description: "The replica-to-replica plane: its dedicated TCP port, command discriminants, and traffic that never reaches a client."
 ---
 
 Replicas talk to each other with the same 256-byte [framing](/docs/binary-protocol/framing) the client protocol uses, on a **dedicated TCP port**, with their own set of `command` discriminants. None of these frames ever appears on a client connection, and a client cannot reach this plane: it is a separate listener, gated by a handshake.

diff --git a/content/docs/binary-protocol/commands.mdx b/content/docs/binary-protocol/commands.mdx
@@ -1,5 +1,6 @@
 ---
 title: Commands
+description: "The catalog of command codes, their operation bytes, and which commands are replicated."
 ---
 
 ## Catalog

diff --git a/content/docs/binary-protocol/connection-lifecycle.mdx b/content/docs/binary-protocol/connection-lifecycle.mdx
@@ -1,5 +1,6 @@
 ---
 title: Connection lifecycle
+description: "How the protocol version is packed and checked, and the login-register handshake that authenticates a connection."
 ---
 
 ## Protocol version

diff --git a/content/docs/binary-protocol/encodings.mdx b/content/docs/binary-protocol/encodings.mdx
@@ -1,5 +1,6 @@
 ---
 title: Shared encodings
+description: "The primitives command payloads are built from: names, identifiers, consumers and the other shared encodings."
 ---
 
 Primitives the [command payloads](/docs/binary-protocol/commands) are built from.

diff --git a/content/docs/binary-protocol/framing.mdx b/content/docs/binary-protocol/framing.mdx
@@ -1,5 +1,6 @@
 ---
 title: Framing
+description: "The fixed 256-byte header every binary-transport message rides in, and the request, reply and eviction shapes it carries."
 ---
 
 Every message on a binary transport is a fixed **256-byte header** followed by an optional body. The header is a `#[repr(C)]` struct decoded by pointer cast (zero-copy), so field offsets are fixed and enforced at compile time in the server. Three header shapes cross the client boundary:

diff --git a/content/docs/binary-protocol/index.mdx b/content/docs/binary-protocol/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: Binary Protocol
+description: "Binary protocol 0.11.0: one wire format across TCP, QUIC and WebSocket, covering both the client and replica planes."
 ---
 
 Iggy speaks one binary protocol over its three binary transports: TCP, QUIC, and WebSocket. Commands, responses, data models, and status codes are the same on all of them. The HTTP transport is separate: it exposes the same operations as JSON REST endpoints, listed in [server.http](https://github.com/apache/iggy/blob/master/core/server/server.http).

diff --git a/content/docs/binary-protocol/messages.mdx b/content/docs/binary-protocol/messages.mdx
@@ -1,5 +1,6 @@
 ---
 title: Message batches
+description: "The batch layout messages travel and rest in, from the 256-byte batch header down to individual message frames."
 ---
 
 Messages travel and rest in exactly one layout, the **batch**: the `SendMessages` body, the replicated record, the persisted segment record, and the poll reply all share it. There is no other message encoding.

diff --git a/content/docs/cli/start.mdx b/content/docs/cli/start.mdx
@@ -1,5 +1,6 @@
 ---
 title: Iggy CLI
+description: "Install the Iggy CLI, connect to a server, authenticate, and manage connection contexts."
 ---
 
 The Iggy CLI is a command-line interface for managing an Iggy server: streams, topics, partitions, messages, users, tokens and more. It lives in the core repository under the `core/cli` directory. The crate is named `iggy-cli`, the installed binary `iggy`.

diff --git a/content/docs/connectors/introduction.mdx b/content/docs/connectors/introduction.mdx
@@ -1,5 +1,6 @@
 ---
 title: Introduction
+description: "The connector runtime: dynamically loaded source and sink plugins, how data flows through them, and what ships today."
 ---
 
 The highly performant and modular runtime for statically typed, yet dynamically loaded connectors. Ingest the data from the external sources and push it further to the Iggy streams, or fetch the data from the Iggy streams and push it further to the external sources. Create your own Rust plugins by simply implementing either the `Source` or `Sink` trait and build custom pipelines for the data processing.

diff --git a/content/docs/connectors/observability.mdx b/content/docs/connectors/observability.mdx
@@ -1,5 +1,6 @@
 ---
 title: Observability
+description: "Logs, Prometheus metrics, the stats endpoint, OpenTelemetry export and per-source state files for the connector runtime."
 ---
 
 The connector runtime exposes its health through logs, Prometheus metrics, a stats endpoint, OpenTelemetry export, and per-source state files.

diff --git a/content/docs/connectors/runtime.mdx b/content/docs/connectors/runtime.mdx
@@ -1,5 +1,6 @@
 ---
 title: Runtime
+description: "How the connector runtime loads plugins, resolves its configuration, and manages connector lifecycles."
 ---
 Runtime is responsible for managing the lifecycle of the connectors and providing the necessary infrastructure for the connectors to run.
 

diff --git a/content/docs/connectors/sdk.mdx b/content/docs/connectors/sdk.mdx
@@ -1,5 +1,6 @@
 ---
 title: SDK
+description: "The Sink and Source traits, the connector macros, and the decoders and encoders used to read and write Iggy streams."
 ---
 
 SDK provides the commonly used structs and traits such as `Sink` and `Source`, along with the `sink_connector` and `source_connector` macros to be used when developing connectors.

diff --git a/content/docs/connectors/sinks/clickhouse.mdx b/content/docs/connectors/sinks/clickhouse.mdx
@@ -1,5 +1,6 @@
 ---
 title: ClickHouse Sink
+description: "Insert messages from Iggy streams into ClickHouse tables over the HTTP interface."
 ---
 
 The ClickHouse sink connector consumes messages from Iggy streams and inserts them into ClickHouse tables over the HTTP interface. It supports three insert formats: `json_each_row` (default), `row_binary`, and `string` passthrough for pre-formatted CSV/TSV/JSON payloads.

diff --git a/content/docs/connectors/sinks/delta.mdx b/content/docs/connectors/sinks/delta.mdx
@@ -1,5 +1,6 @@
 ---
 title: Delta Lake Sink
+description: "Write messages from Iggy streams into Delta Lake tables on local disk, S3, Azure Blob Storage or Google Cloud Storage."
 ---
 
 The Delta Lake sink connector consumes messages from Iggy streams and writes them to Delta Lake tables on the local filesystem, AWS S3, Azure Blob Storage, or Google Cloud Storage. Each batch is flushed and committed as one atomic Delta transaction.

diff --git a/content/docs/connectors/sinks/doris.mdx b/content/docs/connectors/sinks/doris.mdx
@@ -1,5 +1,6 @@
 ---
 title: Apache Doris Sink
+description: "Load JSON messages from Iggy streams into a pre-created Apache Doris table through the Stream Load HTTP API."
 ---
 
 The Apache Doris sink connector consumes JSON messages from Iggy streams and writes them to a pre-created Doris table via Doris's Stream Load HTTP API. Batches are loaded under deterministic labels so that in-request retries deduplicate instead of doubling rows.

diff --git a/content/docs/connectors/sinks/elasticsearch.mdx b/content/docs/connectors/sinks/elasticsearch.mdx
@@ -1,5 +1,6 @@
 ---
 title: Elasticsearch Sink
+description: "Index messages from Iggy streams into an Elasticsearch index using the bulk API."
 ---
 
 The Elasticsearch sink connector consumes messages from Iggy streams and indexes them into an Elasticsearch index using the bulk API.

diff --git a/content/docs/connectors/sinks/http.mdx b/content/docs/connectors/sinks/http.mdx
@@ -1,5 +1,6 @@
 ---
 title: HTTP Sink
+description: "Deliver messages from Iggy streams to any HTTP endpoint, from webhooks and REST APIs to serverless functions."
 ---
 
 The HTTP Sink connector consumes messages from Iggy streams and delivers them to any HTTP endpoint: webhooks, REST APIs, serverless functions, or SaaS integrations. This is the transport-level, generic HTTP connector. It's distinct from sinks such as Elasticsearch or Quickwit, which use HTTP internally to talk to one specific system. You bring the URL, headers, and batching strategy, and the sink handles transport, retries, and metadata wrapping.

diff --git a/content/docs/connectors/sinks/iceberg.mdx b/content/docs/connectors/sinks/iceberg.mdx
@@ -1,5 +1,6 @@
 ---
 title: Iceberg Sink
+description: "Consume messages from Iggy topics and store them in Iceberg tables, with REST catalogs and S3-compatible storage."
 ---
 
 The Iceberg Sink Connector allows you to consume messages from Iggy topics and store them in Iceberg tables.

diff --git a/content/docs/connectors/sinks/influxdb.mdx b/content/docs/connectors/sinks/influxdb.mdx
@@ -1,5 +1,6 @@
 ---
 title: InfluxDB Sink
+description: "Write messages from Iggy streams to InfluxDB as line-protocol points, on both InfluxDB V2 and V3."
 ---
 
 The InfluxDB sink connector consumes messages from Iggy streams and writes them to InfluxDB as line-protocol points. It supports both InfluxDB V2 (OSS 2.x / Cloud) and InfluxDB V3 (Core / Enterprise), selected with the `version` option.

diff --git a/content/docs/connectors/sinks/meilisearch.mdx b/content/docs/connectors/sinks/meilisearch.mdx
@@ -1,5 +1,6 @@
 ---
 title: Meilisearch Sink
+description: "Index messages from Iggy streams as documents in a Meilisearch index through the official Rust SDK."
 ---
 
 The Meilisearch sink connector consumes messages from Iggy streams and indexes them as documents in a Meilisearch index through the official Rust SDK. It can create the index on startup and waits for Meilisearch indexing tasks to complete by default, so task failures surface as connector errors.

diff --git a/content/docs/connectors/sinks/mongodb.mdx b/content/docs/connectors/sinks/mongodb.mdx
@@ -1,5 +1,6 @@
 ---
 title: MongoDB Sink
+description: "Insert messages from Iggy streams into a MongoDB collection, one document per message."
 ---
 
 The MongoDB sink connector writes messages from Iggy streams to a MongoDB database. Each message is inserted as a document into the configured collection.

diff --git a/content/docs/connectors/sinks/postgres.mdx b/content/docs/connectors/sinks/postgres.mdx
@@ -1,5 +1,6 @@
 ---
 title: Postgres Sink
+description: "Store messages from Iggy topics in a PostgreSQL table, with optional table creation and configurable payload storage."
 ---
 
 The PostgreSQL sink connector consumes messages from Iggy topics and stores them in a PostgreSQL table, with optional automatic table creation and configurable payload storage.

diff --git a/content/docs/connectors/sinks/quickwit.mdx b/content/docs/connectors/sinks/quickwit.mdx
@@ -1,5 +1,6 @@
 ---
 title: Quickwit Sink
+description: "Send messages from Iggy streams to a Quickwit index over HTTP, creating the index when it does not exist."
 ---
 
 The Quickwit connector allows you to send data to the Quickwit API using HTTP. This sink will ensure that the index exists (create it if it doesn't) and will append the data to the index using the same batch size as specified in the Iggy configuration.

diff --git a/content/docs/connectors/sinks/s3.mdx b/content/docs/connectors/sinks/s3.mdx
@@ -1,5 +1,6 @@
 ---
 title: S3 Sink
+description: "Write messages from Iggy streams to Amazon S3 and S3-compatible object stores such as MinIO, R2, Spaces and B2."
 ---
 
 The S3 sink connector writes messages from Iggy streams to Amazon S3 and S3-compatible object stores (MinIO, Cloudflare R2, DigitalOcean Spaces, Backblaze B2). Messages are buffered in memory and uploaded as files, rotated by size or message count, under configurable path templates with offset ranges in the object names.

diff --git a/content/docs/connectors/sinks/sink.mdx b/content/docs/connectors/sinks/sink.mdx
@@ -1,5 +1,6 @@
 ---
 title: Sink
+description: "What sink connectors do, and the Sink trait every one of them implements."
 ---
 
 ## Overview

diff --git a/content/docs/connectors/sinks/stdout.mdx b/content/docs/connectors/sinks/stdout.mdx
@@ -1,5 +1,6 @@
 ---
 title: Stdout Sink
+description: "Print messages from Iggy streams to standard output, for debugging and verifying a connector pipeline."
 ---
 
 The stdout sink connector prints messages from Iggy streams to the standard output. This is useful for debugging, development, and verifying that your connector pipeline is working correctly.

diff --git a/content/docs/connectors/sinks/surrealdb.mdx b/content/docs/connectors/sinks/surrealdb.mdx
@@ -1,5 +1,6 @@
 ---
 title: SurrealDB Sink
+description: "Write messages from Iggy streams into SurrealDB over the HTTP API, one bulk insert per batch."
 ---
 
 The SurrealDB sink connector writes messages from Iggy streams into SurrealDB over the HTTP API. Each batch becomes one SurrealQL bulk `INSERT IGNORE`. Every record gets a deterministic record id derived from stream, topic, partition, offset, and message id, so replayed batches are idempotent and existing records are left untouched.

diff --git a/content/docs/connectors/sources/elasticsearch.mdx b/content/docs/connectors/sources/elasticsearch.mdx
@@ -1,5 +1,6 @@
 ---
 title: Elasticsearch Source
+description: "Poll documents from an Elasticsearch index into Iggy streams, incrementally when a timestamp field is configured."
 ---
 
 The Elasticsearch source connector polls documents from an Elasticsearch index and produces them to Iggy streams. With a timestamp field configured, each poll only fetches documents newer than the last one seen, giving incremental, restart-safe ingestion.

diff --git a/content/docs/connectors/sources/influxdb.mdx b/content/docs/connectors/sources/influxdb.mdx
@@ -1,5 +1,6 @@
 ---
 title: InfluxDB Source
+description: "Poll InfluxDB on an interval and produce the resulting rows into an Iggy stream, on both InfluxDB V2 and V3."
 ---
 
 The InfluxDB source connector polls InfluxDB on an interval and produces the resulting rows as messages into an Iggy stream. It supports both InfluxDB V2 (OSS 2.x / Cloud, Flux queries) and InfluxDB V3 (Core / Enterprise, SQL queries), selected with the `version` option. A timestamp cursor stored in persistent connector state tracks the position, so restarts resume where they left off.

diff --git a/content/docs/connectors/sources/postgres.mdx b/content/docs/connectors/sources/postgres.mdx
@@ -1,5 +1,6 @@
 ---
 title: Postgres Source
+description: "Stream rows from PostgreSQL into Iggy topics by incremental table polling or change data capture over logical replication."
 ---
 
 The PostgreSQL source connector fetches data from PostgreSQL databases and streams it to Iggy topics. It supports incremental table polling and Change Data Capture (CDC) via logical replication.

diff --git a/content/docs/connectors/sources/random.mdx b/content/docs/connectors/sources/random.mdx
@@ -1,5 +1,6 @@
 ---
 title: Random Source
+description: "Generate random messages into Iggy streams for testing, benchmarking and verifying a connector pipeline."
 ---
 
 The random source connector generates random messages and sends them to Iggy streams. This is useful for testing, benchmarking, and verifying that your connector pipeline is working correctly without needing an external data source.

diff --git a/content/docs/connectors/sources/source.mdx b/content/docs/connectors/sources/source.mdx
@@ -1,5 +1,6 @@
 ---
 title: Source
+description: "What source connectors do, and the Source trait every one of them implements."
 ---
 
 ## Overview

diff --git a/content/docs/connectors/transforms.mdx b/content/docs/connectors/transforms.mdx
@@ -1,5 +1,6 @@
 ---
 title: Transforms
+description: "Mutate, filter and convert messages as they pass through the connector runtime, and how each transform is configured."
 ---
 
 Transforms mutate, filter, or convert messages as they flow through the connector runtime. They run inside the runtime process, not inside the plugins. For source connectors they're applied after the plugin's messages are decoded and before producing to Iggy. For sink connectors, after consuming from Iggy and before handing the messages to the plugin.

diff --git a/content/docs/faq/faq.mdx b/content/docs/faq/faq.mdx
@@ -1,5 +1,6 @@
 ---
 title: FAQ
+description: "Common questions about Apache Iggy, including how it compares to Kafka and other message brokers."
 ---
 
 ## Q: What is the difference between Iggy and traditional message brokers like Kafka?

diff --git a/content/docs/index.mdx b/content/docs/index.mdx
@@ -1,5 +1,6 @@
 ---
 title: Welcome
+description: "Apache Iggy documentation: how Iggy organizes data into streams, topics, partitions and segments, and where to start."
 ---
 
 <DocsHero />

diff --git a/content/docs/introduction/about.mdx b/content/docs/introduction/about.mdx
@@ -1,5 +1,6 @@
 ---
 title: About
+description: "What Apache Iggy is: a persistent message streaming platform written in Rust, with QUIC, TCP, WebSocket and HTTP transports."
 ---
 
 **Iggy** is a persistent message streaming platform written in Rust, supporting QUIC, TCP, WebSocket (custom binary specification) and HTTP (regular REST API) transport protocols, **capable of processing millions of messages per second at ultra-low latency**.

diff --git a/content/docs/introduction/architecture.mdx b/content/docs/introduction/architecture.mdx
@@ -1,5 +1,6 @@
 ---
 title: Architecture
+description: "Inside the Iggy server: how work is scheduled across cores, how requests are routed, and how a message reaches disk."
 ---
 
 This page covers the internals of the Iggy server: how work is scheduled across CPU cores, how requests are routed, and how data ends up on disk. If you're looking for the domain model (streams, topics, partitions, consumer groups, message format), see [concepts](/docs/introduction/concepts) first.

diff --git a/content/docs/introduction/concepts.mdx b/content/docs/introduction/concepts.mdx
@@ -1,5 +1,6 @@
 ---
 title: Concepts
+description: "The domain model behind Iggy, and how an append-only streaming log differs from a message broker."
 ---
 
 Iggy is a persistent message streaming platform: messages are stored in a form of an **append-only log**. You can create multiple streams, consisting of topics, which might have one or more partitions assigned, e.g. to achieve the horizontal scalability between many independent consumers or higher system resiliency. You can think of Iggy as an alternative to Kafka or RabbitMQ streams.

diff --git a/content/docs/introduction/getting-started.mdx b/content/docs/introduction/getting-started.mdx
@@ -1,5 +1,6 @@
 ---
 title: Getting started
+description: "A first program with the low-level Rust SDK: create a stream and topic, send messages, then poll them back."
 ---
 
 ## Before we start

diff --git a/content/docs/sdk/connection-strings.mdx b/content/docs/sdk/connection-strings.mdx
@@ -1,5 +1,6 @@
 ---
 title: Connection Strings
+description: "The canonical reference for Iggy connection strings, covering every scheme, credential form and option."
 ---
 
 A connection string configures an Iggy client in a single line: transport, credentials, server address, and options. This page is the canonical reference for every scheme, credential form, and option key.

diff --git a/content/docs/sdk/cpp/intro.mdx b/content/docs/sdk/cpp/intro.mdx
@@ -1,5 +1,6 @@
 ---
 title: C++ SDK (WIP)
+description: "The C++ SDK, a CXX bridge over the Rust SDK, and how to build it from source with Bazel."
 ---
 
 The Iggy C++ SDK wraps the Rust SDK through a [CXX](https://cxx.rs) FFI bridge, so it can use all transport protocols (TCP, QUIC, HTTP, WebSocket) via connection strings. The source code is available at [github.com/apache/iggy/tree/master/foreign/cpp](https://github.com/apache/iggy/tree/master/foreign/cpp).

diff --git a/content/docs/sdk/csharp/examples.mdx b/content/docs/sdk/csharp/examples.mdx
@@ -1,5 +1,6 @@
 ---
 title: Examples
+description: "Producer and consumer samples for the C# SDK, built on the high-level publisher and consumer."
 ---
 
 These samples use the [High-level SDK](/docs/sdk/csharp/high-level-sdk) - the recommended way to build producers and consumers. For the low-level, per-call equivalents, see the [Guide](/docs/sdk/csharp/guide).

diff --git a/content/docs/sdk/csharp/guide.mdx b/content/docs/sdk/csharp/guide.mdx
@@ -1,5 +1,6 @@
 ---
 title: Guide
+description: "Client configuration and the full low-level IIggyClient API surface for the C# SDK."
 ---
 
 This guide covers client configuration and the full `IIggyClient` API surface - the low-level, per-call operations. For the ergonomic producer/consumer abstractions built on top of these, see the [High-level SDK](/docs/sdk/csharp/high-level-sdk).

diff --git a/content/docs/sdk/csharp/high-level-sdk.mdx b/content/docs/sdk/csharp/high-level-sdk.mdx
@@ -1,5 +1,6 @@
 ---
 title: High-level SDK
+description: "IggyPublisher and IggyConsumer for C#, with background batching, retries and automatic offset commits."
 ---
 
 The per-call [`IIggyClient`](/docs/sdk/csharp/guide) API is explicit but verbose - you manage partitioning, batching, retries, and offsets yourself. The high-level `IggyPublisher` and `IggyConsumer` wrap that surface with fluent builders that handle:

diff --git a/content/docs/sdk/csharp/intro.mdx b/content/docs/sdk/csharp/intro.mdx
@@ -1,5 +1,6 @@
 ---
 title: C# SDK
+description: "The async-first C# SDK for .NET applications over TCP and HTTP, from installation to creating a client."
 ---
 
 The Iggy SDK for C# is a modern, async-first client library for interacting with an Iggy message streaming server from your .NET applications. It supports TCP and HTTP transports. The package is available on [NuGet](https://www.nuget.org/packages/Apache.Iggy/) and the source code lives on [GitHub](https://github.com/apache/iggy/tree/master/foreign/csharp).

diff --git a/content/docs/sdk/go/examples.mdx b/content/docs/sdk/go/examples.mdx
@@ -1,5 +1,6 @@
 ---
 title: Examples
+description: "Runnable Go examples from the core repository, and how to start a server they can connect to."
 ---
 
 A runnable getting-started example lives in the [examples/go](https://github.com/apache/iggy/tree/master/examples/go) directory of the core repository. Its `go.mod` carries a `replace` directive pointing at the in-repo SDK, so the example always builds against the SDK source in the same checkout. The examples are exercised in CI via `scripts/run-examples-from-readme.sh --language go`.

diff --git a/content/docs/sdk/go/intro.mdx b/content/docs/sdk/go/intro.mdx
@@ -1,5 +1,6 @@
 ---
 title: Go SDK
+description: "The Go SDK, a blocking client speaking the VSR wire protocol over TCP, and which servers it pairs with."
 ---
 
 The Iggy Go SDK is a client library for interacting with the Iggy server from Go applications. It is a blocking client that speaks the VSR (Viewstamped Replication) wire protocol over TCP, with or without TLS. The package is available on [pkg.go.dev](https://pkg.go.dev/github.com/apache/iggy/foreign/go) and the source code lives in [foreign/go](https://github.com/apache/iggy/tree/master/foreign/go).

diff --git a/content/docs/sdk/introduction.mdx b/content/docs/sdk/introduction.mdx
@@ -1,5 +1,6 @@
 ---
 title: Introduction
+description: "The official Iggy client SDKs, their packages and registries, and the transports each one supports."
 ---
 
 Iggy provides official client SDKs in multiple languages. The **Rust SDK** is the most feature-complete, offering both a high-level API (with auto-batching, consumer groups, offset management, retry logic) and a low-level API for direct protocol operations.