Index
The engine runs next to logs, wherever they are produced. Find the estate below and follow its path.
-
Kubernetes
A sidecar in the forwarder pod, or a standalone DaemonSet alongside it.
-
VMs and bare metal
A process beside the forwarder, installed from a package or the single-line script.
-
AWS Lambda
A Lambda extension paired with the function's OTel collector, over loopback.
-
CloudWatch only
A subscription-filter Lambda that processes log groups before they ship.
Pick by where logs are produced
The question is not which cloud the account is in; it is what runs closest to the application.
| Estate | What the engine attaches to | Install path |
|---|---|---|
| Kubernetes, any distribution | Forwarder sidecar or standalone DaemonSet | Receiver |
| VMs, bare metal, edge hosts | A process beside Fluent Bit, Fluentd, Filebeat, Logstash, Vector, or an OTel collector | Install |
| AWS Lambda with an OTel collector extension | A second extension in the execution environment | Extension |
| AWS Lambda without one, or CloudWatch log groups | A subscription-filter Lambda | Lambda |
| Scheduled or event-driven batches | A cron job, or a trigger on object storage | Job, Trigger |
Eight forwarders are supported on the sidecar path, six of them natively: Fluent Bit, Fluentd, Filebeat, Logstash, OTel Collector, and Vector.
Other platforms
Container platforms that support sidecars run the engine the same way Kubernetes does, and the sidecar recipe applies unchanged. Verified on Azure Container Apps: the engine and collector run as peer containers in one app, consuming an Event Hub with the Streams configuration. Google Cloud Run is the same shape.
Serverless platforms with no place to run a second process, such as Azure Functions on the Consumption plan, stream their logs to a hub instead and let one central engine consume it. See Streams.
If an estate is not listed, ask the MCP: log10x_discover_env probes what is actually running and log10x_advise_install returns a plan for it.
Not sure which applies
Install the MCP server and ask it to scan. It reads the cluster, the AWS account, or the host, then names the estate and emits the matching plan, including the case where more than one applies.
Every launcher
The 10x Engine uses an extensible launcher framework to run apps in dev, edge, and cloud environments.
-
Dev/Test
Execute a 10x Engine locally on Nix, Win, or OSX for development and testing.
-
Function
Execute 10x Engines in orchestrated environments via REST.
-
Job
Schedule 10x Engine execution via Linux cron or k8s CronJob.
-
Trigger
Execute the 10x Engine in response to environment events (e.g., S3 trigger).
-
Sidecar
Run the 10x Engine as a log forwarder sidecar to process events at the edge.
-
Lambda
Run the 10x Engine as an AWS Lambda to optimize CloudWatch Logs before Datadog.
-
Extension
Run the 10x Engine as a Lambda extension paired with the function's OTel collector.