Flavors
The 10x Engine ships as three flavors (i.e., binary distributions). All three read the same config files and run the same pipelines. Two axes separate them: what the distribution can do (compile and run, or run only), and how the distribution is built (a JVM build, or an ahead-of-time native image).
| JVM | Native | |
|---|---|---|
| Compile and run | Compiler | not buildable |
| Run only | Runtime (JVM) | Runtime |
Three of the four cells ship. The fourth cannot be built. Compiling loads code at launch: the jarfiles launch argument reads extensions out of .jar files, and the Compile pipeline generates symbol libraries while it runs. A native image is closed at build time: every class the binary will ever execute is compiled into it, and no class loader survives into the running process to add another one. So a distribution that compiles carries a JVM, and a native distribution runs only what was compiled into it before it shipped.
Older flavor names
The installers accept the old spellings and print a notice: cloud maps to compiler, native maps to runtime, and edge maps to runtime-jvm, the jpackage JVM build it has always named.
Bookmarks to the old #cloud, #edge and #jit-edge anchors still land on a live section. #edge lands on the native Runtime, the flavor the old Edge section documented, and #jit-edge lands on Runtime (JVM).
Compiler
A JVM distribution, shipped as a container image (log10x/compiler-10x) and as OS packages carrying a packaged JRE subset. The Compiler holds every capability the Runtime holds, and adds the capabilities that require code loaded at launch.
Compiler only:
- The Compile pipeline, which generates symbol libraries.
- Dynamic loading of input and event/time-series output extensions from .jar files, via the jarfiles launch argument.
- CloudWatch, Datadog, Elastic, Prometheus, log, and log10x time-series outputs.
- Log analyzer and object storage input extensions.
Employed by the dev, function, job, trigger and lambda launchers.
Install: the Docker image, --flavor compiler on the single line installer, TENX_FLAVOR=compiler on Windows, or the log10x-cloud cask on macOS.
Runtime
A single-artifact native binary built ahead of time, with a small footprint and a fast start. Every extension the Runtime can use is compiled into the binary, so the extension set is fixed at build time and the jarfiles launch argument does not apply.
The Runtime carries the reporter, receiver, retriever, MCP server, and CLI entry points, which covers the in-cluster and on-host apps.
The native binary is built for Linux and macOS only. Windows installs Runtime (JVM) instead.
Employed by the sidecar launcher.
Install: --flavor runtime (the default) on the single line installer, or Homebrew on macOS.
Runtime (JVM)
The same run-only build as the Runtime, delivered as an OS package with a bundled JRE rather than as a native binary: .deb and .rpm on Linux, .dmg on macOS, .msi on Windows. Same entry points, same pipeline stages, no Compile pipeline. Against the native Runtime it trades footprint and start-up time for a JVM.
Two cases call for it:
- Windows, which has no native Runtime artifact. Runtime (JVM) is the only way to run a reporter, receiver, retriever or MCP server on Windows without installing the Compiler.
- Linux and macOS hosts where the native binary will not run, and the Compiler is more than the job needs.
Install: --flavor runtime-jvm on the single line installer, TENX_FLAVOR=runtime-jvm on Windows, or the tenx-edge package from the releases page.
Platforms
| Platform | Compiler | Runtime | Runtime (JVM) |
|---|---|---|---|
Linux amd64 / arm64 |
.deb / .rpm |
native binary | .deb / .rpm |
| macOS Intel / Apple silicon | .dmg |
native binary | .dmg |
| Windows | .msi |
none built | .msi |
Windows has no native Runtime. No tenx-*-windows-*-native asset is built, so a request for runtime on Windows resolves to runtime-jvm.
The default flavor is the Runtime: the native binary on Linux and macOS, and Runtime (JVM) on Windows.
musl (Alpine)
None of the three run on musl. The native binary links against glibc, and the JVM builds ship as .deb / .rpm packages, which Alpine cannot install either. Run the engine in a glibc container instead.
Features
The following table outlines the capabilities each flavor provides:
| Feature | Compiler | Runtime | Runtime (JVM) 3 |
|---|---|---|---|
| OS | 1 | ||
| Compile pipeline | |||
| Forwarder Inputs | |||
| Analyzer Inputs | |||
| Storage Inputs | |||
| Custom Inputs | |||
| Time-Series Outputs | 2 | 2 | |
| Custom Outputs |
Flavor names and file names
The flavor name is what you type. The file name on the release page is a separate string, and that string does not change: published releases are immutable, and --version has to keep resolving every past one. The two differ on purpose, which is why --flavor runtime fetches a file called tenx-edge-<ver>-<arch>-native.
| Flavor | Release assets |
|---|---|
compiler |
tenx-cloud_<ver>_<arch>.deb, tenx-cloud-<ver>-1.<arch>.rpm, tenx-cloud-<ver>.dmg, tenx-cloud-<ver>-intel.dmg, tenx-cloud-<ver>.msi |
runtime |
tenx-edge-<ver>-<arch>-native, tenx-edge-<ver>-macos-<arch>-native |
runtime-jvm |
tenx-edge_<ver>_<arch>.deb, tenx-edge-<ver>-1.<arch>.rpm, tenx-edge-<ver>.dmg, tenx-edge-<ver>-intel.dmg, tenx-edge-<ver>.msi |
runtime and runtime-jvm share the tenx-edge file prefix and the /opt/tenx-edge install prefix. The native binary carries a -native suffix; the JVM build is an OS package.