---
icon: material/server-outline
title: "Deployment Options"
---

Supported clouds, EU regions, required network access, and running on-premises or air-gapped.

??? tenx-deploy "Which cloud providers are supported"

    **Reporter (DaemonSet) and Receiver (sidecar)** run anywhere: on-premise, any cloud, Kubernetes, VMs.

    **Retriever** supports AWS (S3, CloudWatch Logs).

    **Optional hosted metrics** (Grafana + Prometheus) run on AWS Managed Services. The agent, engine, and your TSDB run anywhere.

??? tenx-deploy "Is Log10x available in EU regions"

    The agent, engine, and your metrics store all run wherever you deploy them, including any EU region, today. Your data's residency is set by where your time-series database lives, which is yours.

    Nothing is US-bound: the agent, the engine and your metrics store all run where you deploy them.

??? tenx-deploy "What network access do edge apps require"

    **No service endpoint is configured by default**, and an engine without one calls log10x for nothing: there is no address for the startup license check, none for engine telemetry, and none for the per-pattern metrics the shipped configs point at log10x. A metrics push to a backend you name yourself does not need that endpoint and happens regardless. The artifact pull in the last row is a deploy-time fetch, not a runtime connection.

    The engine stays fully observable to you: it emits its complete metric set either way, to whichever [time-series backend](https://doc.log10x.com/run/output/metric/){target="_blank"} you point it at (Prometheus, Datadog, CloudWatch, Elastic). That is the audit trail: you hold it, on your own infrastructure, and log10x has no copy.

    | Connection | Destination | Port | Protocol | Required |
    |------------|-------------|------|----------|----------|
    | Metrics push | your TSDB, or `prometheus.log10x.com` if you point at it | 443 | HTTPS / TLS 1.2+ | Only with a configured endpoint |
    | License enrichment | the endpoint you configure | 443 | HTTPS / TLS 1.2+ | Only with a configured endpoint, and best-effort |
    | Artifact pull | GitHub / Docker Hub | 443 | HTTPS | Deploy-time only |

    **Airgapped mode:** Set `airgapped: true` in your Helm values (or `TENX_AIRGAPPED=true` in the engine environment) and the engine makes **zero** outbound calls to the log10x gateway, no startup validation, no metrics reporting, no user-attribute enrichment. Leaving the endpoint unset gets you the same silence by default; airgapped mode is the explicit form, and it holds even if an endpoint is set later. The license JWT is verified locally against the public keys embedded in the engine. After initial image pull to your private registry, edge apps require zero external connectivity in this mode. Configure [metric output](https://doc.log10x.com/run/output/metric/){target="_blank"} to your local TSDB if you still want telemetry. Airgapped mode is honored for every license type, including `demo` and `limited`.

??? tenx-deploy "Can I run 10x fully on-premises or airgapped"

    Yes. The engine, the agent and MCP server, and the Retriever all run entirely in your infrastructure with no external dependency. Metrics go to a time-series backend you already operate, so nothing reaches log10x systems; see [Compliance](compliance.md) for what that means for your audit.

    - **Private container registry** support for fully disconnected environments
    - **10x** requires zero external connectivity when set to `airgapped: true` (see "What network access do edge apps require" above) and configured to output metrics to your local TSDB
    - [Helm values](https://github.com/log-10x/helm-charts){target="_blank"} carry the airgapped switch directly