Build Omega

Omega is a single Rust binary (omega-agent) plus a small stable supervisor (omega-launcher). What a given binary can do is decided entirely at build time by the Cargo features you enable. This page explains that feature system, how to compose a build (“SKU”) for a device class, and the full feature reference.

Build from source

git clone https://github.com/golain-io/omega-rs
cd omega-rs

# Default build — the standard agent
cargo build --release -p omega-agent

# A slimmed, purpose-built SKU (see below)
cargo build --release -p omega-agent --no-default-features --features ztna,keystore-cng

The release binary lands at target/release/omega-agent. Build the supervisor the same way:

cargo build --release -p omega-core --bin omega-launcher

For the smallest shipped binary, enable stripping in Cargo.toml’s release profile — it removes ~20% on its own, more than any single feature. Feature selection is about what a binary can do and its dependency/attack surface; stripping and opt-level="z" are the levers for raw size.

The feature model

Every capability beyond the always-present core is a Cargo feature. The rule is simple and strict:

A feature that is not compiled in does not exist in that binary. If a device profile lists a module or capability whose feature is off, Omega refuses to start with an exact error — it never runs half-configured.
The build is the source of truth. The profile declares what should run; the binary must be able to honor it.

So building Omega for a device class means choosing exactly the features that class needs — no more (smaller binary, smaller attack surface) and no less (or the profile won’t validate).

Always compiled (the core)

These are not features — every build has them:


`ota`	Over-the-air updates, self-update (A/B slots), and the inventory subsystem (SBOM / HBOM / PBOM collectors + node capabilities).
`service-runtime`	OS-service control and the self-update restart hook.
`sqlite-replication`	SQLite change-data-capture replication (SQLite sync). Always compiled — it is a core dependency, not a build-time choice, so even a `--no-default-features` build carries it.
(infrastructure)	MQTT transport, enrollment (JITR), certificate manager, module lifecycle.

Opt-in features

Enable these explicitly for a device class that needs them:

Feature	What it adds
`ocpp`	The OCPP bridge — connects a charge point to a Charge Point Management System (CPMS) over an OCPP-J WebSocket. Native to Omega (not deprecated). Pulls a tokio runtime + ZeroMQ.
`ztna`	Zero-Trust posture reporting (device posture → the platform). Pulls the gRPC-over-HTTP/2 stack.
`mqtt-quic`	MQTT-over-QUIC transport (in addition to TCP MQTT).
`keystore-cng`	Windows TPM 2.0 hardware-backed device keys (CNG).
`keystore-pkcs11`	Linux TPM / PKCS#11 / HSM hardware-backed device keys.
`keystore-secure-enclave`	macOS Secure Enclave hardware-backed device keys.
`fips`	Route all TLS through the aws-lc-rs FIPS module instead of ring. Needs a heavier build toolchain (cmake, go; nasm + ninja on Windows). Linking the FIPS module is not by itself a FIPS 140-3 claim.

Hardware-key backends are per-OS: build keystore-cng on Windows, keystore-secure-enclave on macOS, keystore-pkcs11 on Linux. Without a hardware backend compiled in, a device honestly reports a software key class and require_hardware cannot be satisfied.

Deprecated features

A set of modules ported from the previous (Go) generation of Omega remain buildable but off by default and are slated for removal. Do not build new work on them: app-reporting, device-control, file-watcher, heartbeat, http-server, ipc, metadata, network-stats, object-storage, registration, rpc, ssh, user-session, rtc (and rtc-jwt / rtc-streaming), robotics. Each is still available with --features <name> if a device genuinely needs it during migration.

Composing a SKU

A “SKU” is just a feature set. Start from --no-default-features and add exactly what the device class needs:

# A minimal device: the core only (OTA + SQLite sync + infrastructure)
cargo build --release -p omega-agent --no-default-features

# A managed (MDM-style) device: zero-trust posture + Windows hardware keys
cargo build --release -p omega-agent --no-default-features \
  --features ztna,keystore-cng

# A FIPS build of the above
cargo build --release -p omega-agent --no-default-features \
  --features ztna,keystore-cng,fips

Since SQLite replication is core, it is present in every one of these — you never add it as a feature. The device’s profile must then list only modules and capabilities that this feature set provides. Keep the two in step by validating (below) as part of your build.

Validate a build against a profile

Before shipping, confirm the binary can honor the profile it will run:

omega-agent --validate --client config.yaml

It prints ✓ config valid on success, or one ERROR: line per problem — each naming the exact module or capability that the profile requires but the build does not provide. Wire this into CI so a SKU/profile mismatch fails the build rather than a device. There is also a standalone profile validator, omega-codegen, for checking a client profile in isolation:

cargo run -p omega-codegen -- --client config.yaml

What a feature pulls in

Most features gate only Omega’s own code (smaller binary, no new dependency). A few pull real dependencies — worth knowing for build size and toolchain:

Feature	Notable dependencies / cost
`ocpp`	The `omega-ocpp-bridge` crate — a tokio runtime + a ZeroMQ transport for its internal session handler.
`ztna`	The HTTP/2 (`h2`) stack, for gRPC.
`mqtt-quic`	quinn (QUIC) + a tokio runtime.
`fips`	aws-lc-rs FIPS module; needs cmake + go (nasm + ninja on Windows).
`keystore-*`	The platform crypto crate for that OS.

Everything else compiles from Omega’s own source with no exclusive third-party dependency. The one core piece with a native cost is sqlite-replication: it brings bundled SQLite (C) + zstd (C). Because it is always compiled, that cost is in every build — there is no SKU without it.

Omega edge runtime

Device RPC

Edge SQLite sync

Edge agent (Omega)

Operate & query

Wire protocol reference

Build from source

The feature model

Always compiled (the core)

Opt-in features

Deprecated features

Composing a SKU

Validate a build against a profile

What a feature pulls in

See also

​Build from source

​The feature model

​Always compiled (the core)

​Opt-in features

​Deprecated features

​Composing a SKU

​Validate a build against a profile

​What a feature pulls in

​See also

Build from source

The feature model

Always compiled (the core)

Opt-in features

Deprecated features

Composing a SKU

Validate a build against a profile

What a feature pulls in

See also