---
icon: material/car-side
---

Sidecars execute the 10x Engine as a [sidecar process](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar){target="\_blank"} to read and events from a target process (e.g., Fluentd/Bit) running on the same node. This architecture enables 10x to integrate with other observability products without requiring custom builds or code integrations.

In-mem outputs (e.g., [Unix](https://doc.log10x.com/run/output/event/unix/), [Forward](https://doc.log10x.com/run/output/event/forward/) sockets) can write regulated and [compact](https://doc.log10x.com/run/transform/#compact) events back to the originating process for processing and shipping.

:material-ice-cream: This launcher employs the [Runtime flavor](https://doc.log10x.com/engine/flavors/#runtime).

***Use-case***:

[:simple-fluentbit: Forwarder inputs](https://doc.log10x.com/run/input/forwarder/) report, regulate and optimize log/trace events before they ship from edge nodes to their output destination (e.g., Elastic, Splunk). 

## :material-car: Benefits

Sidecar deployment provides several technical advantages for integrating the 10x Engine with log forwarders:

### :material-kubernetes: Native Kubernetes Support

Kubernetes pods co-locate the 10x Engine with your forwarder, sharing the pod's network namespace and lifecycle. Depending on the forwarder, 10x runs either as a [sidecar container](#sidecar-container) or as an [embedded child process](#embedded-process), see [Deployment Models](#deployment-models) below.

### :material-arrow-collapse: Efficient Inter-Process Communication

Sidecars enable low-latency protocols like [stdio streams](https://doc.log10x.com/run/input/stdin/) for direct piping, [Unix domain sockets](https://en.wikipedia.org/wiki/Unix_domain_socket) for zero-copy transfers, [Fluent Forward protocol](https://docs.fluentd.org/input/forward) for reliable event forwarding, and [OTLP](https://opentelemetry.io/docs/specs/otlp/) for OpenTelemetry metrics/traces. These minimize overhead compared to network-based alternatives.

### :material-car-multiple: Process Isolation and Management

Decouples 10x from the forwarder process, enabling independent monitoring via tools like Prometheus, separate restart policies, and fault isolation. If the 10x process exits, Kubernetes restarts the sidecar container automatically while the forwarder keeps running and buffers events until 10x is back.

### :material-speedometer: Resource Optimization

Shares host resources efficiently. In the [sidecar container](#sidecar-container) model, CPU and memory requests are set independently for 10x and the forwarder. In the [embedded](#embedded-process) model, 10x shares the forwarder container's resource allocation, so raise the forwarder's existing memory limit by the engine's resident footprint.

### :material-shield-car: Security Boundaries

In the [sidecar container](#sidecar-container) model, 10x runs with a separate security context (non-root, read-only root filesystem), allowing distinct capabilities and namespaces while sharing volumes for data exchange. In the [embedded](#embedded-process) model, 10x inherits the forwarder container's security context. Both models reduce the attack surface compared to plugin-based integrations by avoiding custom code within the forwarder runtime.

## :material-swap-horizontal: Deployment Models

Two integration models depending on the forwarder:

|  | Sidecar Container | Embedded Process |
|---|---|---|
| **Forwarders** | Fluentd, Fluent Bit, Logstash, OTel Collector, Vector | Filebeat |
| **Containers per pod** | 2 | 1 |
| **IPC mechanism** | Loopback TCP (Fluentd, Fluent Bit, Logstash, OTel Collector, Vector) | Stdin/stdout pipe (Filebeat) |
| **Resource limits** | Independent per container | Shared with forwarder |
| **Security context** | Separate (non-root, read-only rootfs) | Inherited from forwarder |
| **10x lifecycle** | Managed by Kubernetes, the kubelet restarts the container on process exit | Managed by the forwarder process |

### Sidecar Container

Fluentd, Fluent Bit, Logstash, OTel Collector, and Vector run 10x as a separate [Kubernetes sidecar container](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/){target="\_blank"} within the same pod, using the `log10x/edge-10x` image. Each container has its own image, `resources` block, and `securityContext`. Integration uses the forwarder's official upstream Helm chart plus a values overlay that injects the sidecar (Fluentd via a Helm post-renderer / kustomize overlay). All share the pod's network namespace and exchange events over loopback TCP.

Kubernetes owns the sidecar lifecycle: if the 10x process exits, the kubelet restarts the container automatically. Each container is monitored, scaled, and rolled independently.

### Embedded Process

Filebeat runs 10x from a single swapped image (`log10x/filebeat-10x`), no separate container. Filebeat launches the 10x binary as a child process of its entrypoint within the forwarder container, with events flowing via stdin/stdout pipes and a unix-socket return. The forwarder process handles 10x's lifecycle. The engine ships as a native binary with no JVM in the image, so there is no heap to size: at 1.1.39 an idle sidecar holds about 190 MiB resident across 23 threads. No separate container image, no additional scheduling overhead.

## :material-hexagon-multiple-outline: Architecture Flow

<div style="text-align: center;">

```mermaid
graph LR
    A["🪵 Log Forwarder<br/>(Fluentd/Fluent Bit/Filebeat)"] -->|"🔗 IPC<br/>(stdio, socket, forward)"| B["🏎️ 10x Engine<br/>(Sidecar or Embedded)"]
    B -->|"🔄 Transform<br/>into TenXObjects"| C["⚡ Process<br/>(Report/Regulate/Optimize)"]
    C -->|"📤 Return<br/>Processed Events"| D["🔗 IPC<br/>(stdio, socket, forward)"]
    D --> A
    A -->|"📡 Ship to<br/>Destinations"| E["🏭 Analytics Platforms<br/>(Splunk, Elasticsearch, etc.)"]
    
    classDef forwarder fill:#3b82f6,stroke:#1d4ed8,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef tenx fill:#059669,stroke:#047857,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef process fill:#ea580c,stroke:#c2410c,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef ipc fill:#8b5cf6,stroke:#7c3aed,color:#ffffff,stroke-width:2px,rx:8,ry:8
    classDef destination fill:#6b7280,stroke:#4b5563,color:#ffffff,stroke-width:2px,rx:8,ry:8
    
    class A forwarder
    class B tenx
    class C process
    class D ipc
    class E destination
```

</div>

<div class="diagram-controls">
    <button class="md-button md-button--primary enlarge-diagram" 
            onclick="enlargeDiagram(this)" 
            data-diagram="sidecar"
            data-tooltip="Click to enlarge diagram">
        <span class="twemoji">
            <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="16" height="16">
                <path d="M10 2c4.42 0 8 3.58 8 8 0 1.85-.63 3.55-1.69 4.9L20.59 19l-1.41 1.41-4.09-4.09A7.84 7.84 0 0 1 10 18c-4.42 0-8-3.58-8-8s3.58-8 8-8m0 2a6 6 0 1 0 0 12 6 6 0 0 0 0-12m1 3h2v2h-2V7m-4 0h2v2H7V7m2 4h2v2H9v-2Z"/>
            </svg>
        </span>
        Enlarge Diagram
    </button>
</div>
<!-- Mermaid enhanced diagram functionality loaded via external files -->


🪵 **Forwarder → 🏎️ 10x**: Events flow from log forwarder to 10x Engine via efficient IPC protocols

🔄 **Transform**: 10x Engine [transforms](https://doc.log10x.com/run/transform/) raw events into structured TenXObjects

⚡ **Process**: Engine applies reporting, regulation, or optimization logic

📤 **Return**: Processed events flow back to forwarder via the same IPC channel

📡 **Ship**: Forwarder sends processed events to final destinations

The circular flow ensures zero disruption to existing forwarder configurations while enabling 10x optimization at the edge.