OpenEng Labs

Open Engineering Executor · OEE

Any application, one signed binary, every limit enforced.

The Open Engineering Executor (OEE) is a Rust-native, polyglot runtime wrapper and OS-level sandbox supervisor that packages an application, its language runtime, and its security policy into one signed executable.

Go, Rust, C and C++, Python, JVM, and Node.js workloads ship as a single executable that verifies itself, sandboxes itself, caps its own CPU and memory, scales itself out under load, and stops cleanly on any exit event you define, with every file it wrote left intact.

Request early accessSee the benchmarks
./dist/my-servicesignature ok
  1. 1

    oee-stub supervisor

    native Rust · ELF / PE / Mach-O · ~2.2 MB

  2. 2

    Signed policy manifest

    Ed25519-signed oee.yaml · caps, sandbox, exit events

  3. 3

    Portable language runtime

    zstd · CPython, jlink JRE, Node, or 0 bytes for Go

  4. 4

    Guest application bundle

    zstd · Go binary, Python app, fat JAR, or JS bundle

  5. 5

    OEE! footer · 128 bytes

    offsets · BLAKE3 Merkle root · Ed25519 signature

one file · verified before the guest starts

Explore the Executor

Overview, benchmarks, downloads, and documentation.

What it is

A runtime wrapper, a sandbox supervisor, and an exit event engine in one binary.

Operated through one command-line toolchain, oee, the Executor packages a target application, such as a compiled Go binary running inside Docker, a multi-worker Python uvicorn service, a Java .jar application, or a Node.js server, together with its portable language runtime and security policy into a single standalone executable.

At run time that binary boots a lightweight native Rust supervisor, oee-stub. It validates the binary’s integrity, optionally enforces kernel-level sandboxing across filesystem, network, syscall, and compute boundaries, and launches the wrapped workload transparently. Alongside it, oee-stub runs an out-of-band lifecycle watchdog and exit event engine.

When any configured stop condition is met, whether a remote API response tag, a monotonic duration limit, a cron cutoff, or an application checkpoint, the Executor cleanly halts the entire guest process tree: the primary runtime and every spawned worker. Application files, logs, workspace state, and the binary itself remain intact on disk.

Status, as of November 11, 2026

  • Launching soon

    Executor (OEE)

    Launching soon for Linux, macOS, Windows, and OCI/Docker; early access on request

  • 100% memory-safe Rust core

    The oee CLI and the embedded oee-stub supervisor are written entirely in Rust and compile to compact static executables with no glibc coupling and no C or OpenSSL dynamic libraries.

  • Out-of-band supervision

    Timers, remote polling, and process-tree termination run in the native supervisor, outside the guest language VM, so stopping stays deterministic even when the guest hangs.

  • Decoupled control plane

    With network sandboxing on, the exit event poller runs in the supervisor’s network context, so an air-gapped or port-restricted guest is still governed by an external HTTPS exit event.

How it works

Configure once, receive one binary.

oee init --interactive walks through the configuration in order and writes a complete oee.yaml; oee build then produces the binary. Every answer can also be supplied by editing oee.yaml directly, and the wizard validates each answer with the same rules as oee validate.

  1. 01

    Application

    Point at the built application: a binary, a Python project, a JAR or WAR, or a Node project.

    workload.<adapter>

  2. 02

    Runtime

    The language and runtime version are auto-detected, and you confirm them.

    workload.adapter

  3. 03

    Start command

    The exact command line that starts the service, and whether extra CLI arguments pass through.

    workload.entrypoint

  4. 04

    Exit events

    Zero or more exit events of any category, each with its parameters and optional authorization.

    exit_events.rules

  5. 05

    Capping

    CPU and memory limits as a percentage or an absolute amount, each strict or flexible.

    resources

  6. 06

    Auto-scaling

    Whether to scale out, the lower and upper thresholds, the replica bounds, and the public port.

    autoscale

  7. 07

    Sandbox

    Whether to isolate the filesystem, the network, and system calls.

    sandbox

  8. 08

    Build

    Pick the target platform and the signing key; oee build produces one binary file.

    oee build

oee
$ oee init --interactive
$ oee validate -f oee.yaml --strict
$ oee build -f oee.yaml --target linux-x86_64 \
    --sign-key ./certs/oee.key -o ./dist/my-service
$ ./dist/my-service --log-level info

One deliverable. The journey ends in exactly one binary file that runs the application under every restriction you configured.

Why the Executor

Six gaps that per-language SDKs, container daemons, and orchestrators leave open.

Teams that deploy polyglot services across cloud containers, on-premise servers, and customer-hosted environments meet the same gaps again and again. Each one is closed inside the binary.

  • 01

    Exit logic per language

    The usual way

    Runtime revocation, maintenance cutoffs, and license lease checks need a custom SDK in every Go, Python, Java, and Node.js codebase, and an in-process thread cannot act when the runtime deadlocks on a hung C extension, an infinite loop, or garbage-collection thrashing.

    With the Executor

    Exit events are evaluated by the native supervisor outside the guest VM, for every language, without changing application code, and stopping stays deterministic even when the guest hangs.

  • 02

    Orphaned worker trees

    The usual way

    uvicorn --workers 4, Gunicorn, and subprocess-spawning tools build multi-level process trees; wrapper scripts that signal only the immediate child leave workers serving traffic, holding ports, and writing to disk.

    With the Executor

    The whole tree is contained (PID namespace, subreaper, and cgroups v2 on Linux; Job Objects on Windows; process group and kqueue on macOS) and stopped atomically, with zero orphaned workers.

  • 03

    Daemons just to sandbox

    The usual way

    Isolating paths, ports, or CPU and RAM on bare metal or a VM usually means installing a privileged container daemon such as Docker or containerd.

    With the Executor

    Kernel-native primitives sandbox the single binary directly, without root privileges, container daemons, or hypervisors.

  • 04

    Interpreter and dependency drift

    The usual way

    Python wheels, virtual environments, and JVM applications break across hosts on mismatched system Python or Java versions and missing shared libraries.

    With the Executor

    A relocatable CPython, a minimal jlink JRE, or a static Node runtime travels inside the binary and runs from a read-only, content-addressed cache.

  • 05

    Limits tied to the platform

    The usual way

    CPU and memory ceilings live in a container runtime, an orchestrator, or a systemd unit, so one application gets different limits, or none, on each host, and “10% of whatever machine it lands on” cannot ship with the application.

    With the Executor

    Caps are sealed into the signed binary as a share of the machine or an absolute amount and enforced on whatever host the binary runs on, with or without the sandbox.

  • 06

    Scaling needs an orchestrator

    The usual way

    Running a second copy under load and balancing traffic between copies normally needs Kubernetes, a process manager, and a separate reverse proxy, even on one host.

    With the Executor

    The supervisor starts and stops replicas itself and balances requests across them with a built-in load balancer: no orchestrator, sidecar, or external proxy.

Capabilities

Everything the binary enforces, natively.

No external tooling is needed for any of these: they are part of the supervisor embedded in every OEE binary.

  • Single signed binary

    oee build writes five integrity-protected segments into one executable: the supervisor, the Ed25519-signed policy, the zstd-compressed runtime, the application bundle, and a 128-byte OEE! footer.

    • BLAKE3 Merkle root
    • Ed25519 signature
    • zstd

  • Polyglot runtimes

    Native binaries, Python 3.10 to 3.13, JVM 17, 21, and 25, and Node.js, Deno, or Bun, each with its runtime bundled and CLI arguments, environment variables, standard I/O, and exit codes passed through.

    • Go · Rust · C · C++
    • Python
    • JVM
    • Node.js

  • Kernel sandbox in five dimensions

    One declarative toggle, sandbox.enabled, isolates process trees, filesystem paths, system calls, network ports and CIDRs, and resource quotas on Linux, Windows, and macOS.

    • Landlock
    • seccomp-BPF
    • AppContainer
    • Seatbelt

  • Native CPU and memory capping

    Declare a share of the machine ("10%") or an absolute amount ("1vcpu", "10GB"), strict or flexible per resource. The cap is sealed at build time and enforced on the whole process tree.

    • strict
    • flexible
    • cgroups v2
    • Job Objects

  • Exit events of any type

    Time, utilization, polled URLs, webhooks, files, probes, processes, signals, Kafka, MQTT, NATS, Redis, checkpoints, log patterns, and operator stops, combined under ANY or ALL, with or without authorization.

    • ANY / ALL
    • FAIL_OPEN
    • FAIL_CLOSED

  • State-preserving stop pipeline

    Five deterministic stages: latch and audit, graceful signal, bounded drain, hard tree termination, then flush and exit with a mapped code. Every file the application wrote stays on disk.

    • GRACEFUL
    • IMMEDIATE
    • exit codes

  • Auto-scaling with a built-in load balancer

    Above the upper threshold the supervisor starts another replica on a free port; below the lower threshold it scales back in. Its load balancer spreads traffic in tcp or http mode.

    • round_robin
    • least_connections
    • readiness gating

  • Containers and PID 1

    The binary runs as a proper container init process in scratch, distroless, and alpine images, forwarding signals and reaping zombies, and layers the sandbox primitives an unprivileged container allows.

    • FROM scratch
    • distroless
    • alpine

  • Security and integrity

    Any changed byte fails verification before the guest starts. Exit event endpoints use TLS 1.3 with SPKI pinning and optional signed responses, and their credentials are hidden from the guest.

    • TLS 1.3
    • SPKI pinning
    • scrub_from_guest_env

Kernel sandbox

Five dimensions of isolation on three operating systems.

Set sandbox.enabled: true and oee-sandbox builds a multi-layered OS boundary around the guest runtime without root privileges or external hypervisors. Set it to false and the application runs directly on the host, still under process-tree supervision, exit events, and resource caps.

  • Process tree containment

    Linux
    User and PID namespaces, PR_SET_CHILD_SUBREAPER, cgroups v2 PID tracking
    Windows
    Win32 Job Objects, kill on job close, breakaway disabled
    macOS
    Dedicated process group and kqueue fork and exec tracking

  • Filesystem access control

    Linux
    Mount namespace, read-only runtime bind mounts, Landlock LSM path allowlists
    Windows
    AppContainer SID with explicit NTFS DACL grants
    macOS
    Seatbelt profile restricting file reads and writes to declared paths

  • System call filtering

    Linux
    seccomp-BPF allowlist or denylist compiled in pure Rust
    Windows
    Process mitigation policies: DynamicCode, SystemCallDisable, ExtensionPointDisable
    macOS
    Seatbelt filters denying raw debugging and kernel extension calls

  • Network isolation

    Linux
    Network namespace with a user-space forwarder or an eBPF socket filter for allowed ports and CIDRs
    Windows
    Windows Filtering Platform rules per AppContainer
    macOS
    Seatbelt inbound and outbound socket rules

  • Resource quotas

    Linux
    cgroups v2 cpu.max, memory.max, pids.max, io.max, plus setrlimit
    Windows
    Job Object extended limits and CPU rate control
    macOS
    setrlimit for address space, CPU, open files, and processes

  • Read-only and read-write paths

    read_only_paths and read_write_paths name exactly what the guest may read or change. Files written to read-write paths persist after the application stops; reads of /etc/shadow, ~/.ssh, or ~/.aws outside the policy get an immediate kernel EACCES or ERROR_ACCESS_DENIED.

  • Language-aware syscall profiles

    strict, the default for Go and Rust static binaries, blocks ptrace, kexec_load, mount, bpf, unshare, chroot, init_module, and raw AF_PACKET sockets. runtime-managed, chosen for Python, JVM, and Node, keeps JIT memory transitions while blocking privilege escalation and host debugging. custom takes your own list.

  • Container-aware negotiation

    Inside an unprivileged Docker container or Kubernetes Pod, container_fallback: "auto" layers Landlock, seccomp-BPF, subreaper containment, and setrlimit quotas without --privileged; "strict" halts before launch if a requested primitive is missing.

Native CPU and memory capping

Limits that travel inside the binary.

Capping is independent of the sandbox. The limits are sealed into the signed policy and enforced by oee-stub on the complete guest process tree, every worker and descendant included, so forked workers share one budget.

mode: "strict"

default

A hard ceiling that is never exceeded and never changed.

CPU
The kernel throttles the tree so its total CPU time never exceeds the limit in any enforcement period.
Memory
The tree can never hold more than the limit; swap cannot be used to exceed it. An allocation past the limit ends in an in-tree out-of-memory termination and exit code 70.

mode: "flexible"

per resource

A soft target with optional bursting.

CPU
A proportional share under contention; idle CPU beyond it is usable up to burst_limit when one is set.
Memory
Above the limit the kernel throttles and reclaims memory instead of terminating; burst_limit, when set, is a hard ceiling.

  • "10%"

    Resource
    CPU
    Meaning
    A share of the logical CPU capacity of the machine the binary runs on: 1.0 core on a 10-core machine, 0.5 core on a 5-core machine.

  • "1vcpu", "0.5vcpu", "2"

    Resource
    CPU
    Meaning
    An absolute number of cores, used exactly as given on every machine.

  • "10%"

    Resource
    Memory
    Meaning
    A share of the physical memory of the machine: 2.4 GB on a 24 GB machine.

  • "10GB", "512MB", "2GiB"

    Resource
    Memory
    Meaning
    An absolute amount of memory, used exactly as given on every machine.

  • Resolved once, then fixed

    Percentages resolve once at startup against the host, or the enclosing container’s own limits when smaller, are recorded in the startup audit event, and never move for the life of the instance.

  • Strict means strict

    If the host offers no kernel hard limit to the current user, the supervisor refuses to launch with exit code 69 and never silently downgrades a strict cap.

  • Immutable at run time

    No environment variable, CLI argument, control-socket command, or remote exit event response can raise or disable a sealed cap. Changing it takes a new signed build.

Exit events

Any condition can end the run, cleanly.

Every exit event is a rule under exit_events.rules, evaluated asynchronously inside oee-stub. Rules combine under ANY (the default) or ALL, every rule may set its own stop_mode, and remote and message sources follow a FAIL_OPEN or FAIL_CLOSED outage policy.

  • Time

    • duration
    • cron
    • timestamp
    • idle

    A monotonic runtime limit such as after: "1h", a cron cutoff, a fixed ISO-8601 time, or an idle period. Durations run on hardware monotonic clocks, so a changed system clock cannot extend them.

  • Utilization

    • utilization

    CPU, memory, process count, disk used under a path, or free disk staying above or below a threshold for a sustained period.

  • External source

    • http_poll
    • webhook
    • file_watch
    • tcp_probe
    • process_watch
    • command
    • signal

    A polled URL, an inbound request, a deleted or changed file, an unreachable dependency, an exited parent or sidecar, any probe command, or an OS signal.

  • Message

    • kafka
    • mqtt
    • nats
    • redis

    A matching message on a topic, subject, or channel, over plaintext or TLS, with no authentication or the broker’s native mechanism.

  • Application

    • checkpoint
    • log_match
    • on_task_complete

    A named checkpoint sent over an authenticated local IPC socket, a sentinel pattern on stdout or stderr, or the primary command finishing its work.

  • Operator

    • oee stop

    An authenticated local stop command from an operator, graceful or immediate.

oee.yaml (excerpt)
exit_events:
  combinator: "ANY"
  rules:
    - id: "one-hour-max-ttl"
      type: "duration"
      after: "1h"

    - id: "remote-api-exit"
      type: "http_poll"
      url: "https://controlplane.example.org/api/v1/runtime/gate"
      interval: "1m"
      jitter: "5s"
      check_before_start: true
      stop_when:
        match: "ANY"
        conditions:
          - json_path: "$.ep_flag"
            in: ["ABC", "XYZ", "HALT"]
          - http_status: [410, 423]
      on_network_error:
        mode: "FAIL_OPEN"

    - id: "license-file-removed"
      type: "file_watch"
      path: "/var/run/payments/license.lock"
      events: ["deleted"]

Remote polling, hardened

  • GET, POST, or HEAD against any https:// endpoint at intervals such as "15s", "1m", or "5m", with jitter so thousands of binaries never poll in lockstep
  • Match on JSONPath fields, raw body text, regexes, HTTP status codes such as 410 or 423, or response headers
  • Bearer, custom header, Basic, HMAC-SHA256 request signing, mutual TLS, or no authorization at all
  • TLS 1.3 with SPKI SHA-256 pinning and optional Ed25519-signed responses against spoofing and replay
  • check_before_start blocks launch with exit code 78 when a stop tag is already active

State-preserving stop

Zero orphaned workers, 100% of disk state kept.

When any exit event matches, oee-lifecycle moves atomically into STOPPING and runs a deterministic five-stage pipeline. With auto-scaling active it covers every replica under one shared grace deadline.

  1. 01

    Latch and audit

    Set the state to STOPPING (idempotent when several triggers fire at once) and emit a structured stop event.

  2. 02

    Graceful signal

    Send SIGTERM or SIGINT to the whole process group, or CTRL_BREAK_EVENT on Windows, so servers and shutdown hooks drain. Skipped in IMMEDIATE mode.

  3. 03

    Bounded drain

    Wait up to grace_period_ms for every process to exit; if they all do, go straight to the last stage.

  4. 04

    Hard tree termination

    cgroup.kill on Linux, TerminateJobObject on Windows, SIGKILL across the tracked group on macOS, then reap until zero processes remain.

  5. 05

    Flush and exit

    Flush stdout and stderr, release sandbox handles, keep every file on disk, and exit with the mapped code.

Deterministic exit codes

For Docker restart policies, Kubernetes Jobs, systemd units, and CI pipelines. Every code is configurable.

  • guest

    Cause
    Normal guest exit
    Meaning
    The application’s own exit code, forwarded transparently

  • 0

    Cause
    Checkpoint stop
    Meaning
    The application reached its completion checkpoint and stopped cleanly

  • 78

    Cause
    Pre-launch gate block
    Meaning
    A remote exit event was already active before startup

  • 75

    Cause
    Lease lost (FAIL_CLOSED)
    Meaning
    The control API stayed unreachable past max_consecutive_failures

  • 69

    Cause
    Enforcement unavailable
    Meaning
    A strict cap or strict sandbox primitive cannot be enforced, so the guest never started

  • 70

    Cause
    Quota or policy violation
    Meaning
    The guest exceeded a strict memory cap or PID quota, or hit a fatal syscall trap

  • 124

    Cause
    Time-based exit event
    Meaning
    Duration, cron cutoff, timestamp, or idle timeout

  • 76

    Cause
    Utilization exit event
    Meaning
    CPU, memory, process count, or disk usage stayed past its threshold

  • 143

    Cause
    External or message exit event
    Meaning
    A polled flag, webhook, file event, message, probe, watched process, signal, or oee stop

Native auto-scaling

Replicas and a load balancer, inside the supervisor.

With autoscale.enabled: true the supervisor runs one or more replicas of the same service on one host and balances traffic across them itself. Each replica is a complete guest process tree with the same entrypoint, the same sandbox policy, and its own copy of the resource caps.

  • Thresholds with hysteresis

    Scale out when average usage stays above upper_threshold for scale_out_after; scale in when it stays below lower_threshold for scale_in_after. A cooldown follows every action, and one replica is added or removed per decision.

  • Readiness-gated traffic

    Each replica gets its own free loopback port through {{port}} or port_env and receives traffic only after a TCP or HTTP readiness check passes.

  • Built-in load balancer

    tcp mode balances connections for any TCP protocol; http mode balances individual HTTP/1.1 requests and adds X-Forwarded-For. round_robin or least_connections, with active and passive health checks.

  • Caps hold per replica

    Every replica is held to its own strict cap, the optional total_limits ceiling bounds all replicas together, and crashed replicas are replaced with backoff.

Security and integrity

Hardened against the ways a supervisor gets bypassed.

Every threat below is answered by a mechanism in the binary, not by a policy document.

  • A tampered binary

    How the binary answers it
    Any byte changed in the supervisor, the embedded policy, or the bundled runtime fails BLAKE3 and Ed25519 verification before the guest runs.

  • Double-fork escape

    How the binary answers it
    Subreaper, PID namespace, and cgroup.kill on Linux, and Job Objects with breakaway disabled on Windows, stop every descendant atomically.

  • A guest that ignores SIGTERM

    How the binary answers it
    The drain stage enforces a monotonic grace_period_ms deadline and escalates to SIGKILL or TerminateJobObject.

  • A guest reading the exit event key

    How the binary answers it
    With scrub_from_guest_env: true, the default, the supervisor reads the key at startup and strips it from the child’s environment.

  • A rolled-back system clock

    How the binary answers it
    Duration limits run on CLOCK_MONOTONIC_RAW, CLOCK_BOOTTIME, or QueryPerformanceCounter, unaffected by wall-clock changes.

  • DNS or proxy spoofing

    How the binary answers it
    TLS 1.3 SPKI pinning and optional Ed25519 response signatures reject unauthenticated keep-running responses.

The oee CLI

Nine subcommands, one workflow.

You interact with the Executor entirely through the oee binary: scaffold, validate, sign, build, inspect, and operate.

Standard developer workflow
# 1. Scaffold an OEE configuration for a Python uvicorn project
oee init --lang python --sandbox

# 2. Validate sandbox path policies and exit-event JSONPath expressions
oee validate -f oee.yaml --strict

# 3. Generate Ed25519 manifest signing keys
oee keygen --out-dir ./certs

# 4. Build a standalone single-binary executable for Linux x86_64
oee build \
  -f oee.yaml \
  --target linux-x86_64 \
  --sign-key ./certs/oee.key \
  -o ./dist/my-service

# 5. Inspect and verify signature of the compiled artifact
oee inspect ./dist/my-service --verify-key ./certs/oee.pub

# 6. Run the single binary directly
./dist/my-service --log-level info

  • oee init[--lang <auto|python|go|java|node|binary>] [--sandbox] [--interactive]

    Detects pyproject.toml, requirements.txt, go.mod, pom.xml, or package.json and scaffolds an annotated oee.yaml, or runs the guided flow.

  • oee validate[-f <oee.yaml>] [--strict]

    Checks manifest syntax, sandbox path permissions, cron expressions, JSONPath queries, and environment variable references.

  • oee keygen[--out-dir <dir>]

    Generates an Ed25519 keypair: oee.key to sign, oee.pub to verify.

  • oee build[-f <oee.yaml>] [--target <triple>] [-o <binary>] [--sign-key <path>]

    Packages the workload, its runtime, and the signed policy on top of oee-stub, including cross-platform builds.

  • oee run[-f <oee.yaml>] -- <cmd> [args...]

    Runs any local command under the sandbox and exit event engine without building a binary first.

  • oee inspect<oee-binary> [--verify-key <oee.pub>]

    Verifies the OEE! footer, Merkle root, and signature, and prints the embedded policy, target, and runtime versions.

  • oee status[--instance <id>] [--json]

    Reports process count, sandbox state, uptime, last poll, caps against usage, replicas, and backend health.

  • oee stop<instance-id | --all> [--mode <graceful|immediate>]

    Sends an authenticated local stop to a running instance.

  • oee runtimelist | fetch | verify

    Lists, pre-fetches, and checksum-verifies portable CPython, jlink JDK, and Node.js distributions in the build cache.

Reference scenarios

Three end-to-end runs.

A Go service in Docker, a multi-worker Python service under a time limit, and a capped Node.js API that scales itself.

  • A

    A Go service inside Docker

    PID 1 · seccomp · Landlock · remote exit event

    1. 1.CI wraps the compiled order-engine service with oee build -f oee.yaml -o order-engine-oee.
    2. 2.A distroless or alpine image starts it with ENTRYPOINT ["/app/order-engine-oee"], so the Executor is the container’s PID 1.
    3. 3.oee-stub forwards signals, reaps zombies, applies seccomp and Landlock rules, launches the Go binary, and polls the exit event URL every minute.
    4. 4.When the API returns {"ep_flag": "ABC"}, the Go process gets SIGTERM, connections drain, and the container exits with 143, logs and volumes intact.
  • B

    Python uvicorn writing 100 files under a time limit

    sandbox · after: "1h" · 4 workers

    1. 1.A FastAPI service and its .whl dependencies become one portable binary, analytics-api.
    2. 2.It boots uvicorn --workers 4 inside the sandbox, or directly on the host with sandbox.enabled: false, and writes 100 report files into ./reports/.
    3. 3.After one hour, or earlier if the one-minute exit event returns "XYZ", the master and all four workers stop cleanly.
    4. 4.The binary and all 100 files in ./reports/ remain untouched and immediately accessible.
  • C

    A capped Node.js API that scales itself

    10% caps · 1 to 3 replicas · port 8000

    1. 1.The API is built with strict 10% CPU and memory caps and auto-scaling from 1 to 3 replicas between 30% and 80% memory.
    2. 2.On a 10-core, 24 GB host each replica resolves to 1.0 core and 2.4 GB; on a 5-core host the same binary resolves to 0.5 core. The load balancer listens on port 8000.
    3. 3.Above 80% of its memory cap for the window, a second replica starts on another free port, passes readiness, and joins the load balancer.
    4. 4.When every replica stays below 30%, the newest one drains and stops; when the exit event fires, all of them stop. No replica ever exceeds its cap.

Platforms and runtimes

Five host targets, four runtime families.

oee build cross-compiles, so one CI host can produce binaries for every target. Each binary carries its own runtime, so the host needs nothing installed.

  • Linux x86_64
  • Linux aarch64
  • macOS aarch64
  • macOS x86_64
  • Windows x86_64
  • OCI / Docker

  • Native binaries

    Versions
    Go, Rust, C, C++
    Build inputs
    ELF, PE (.exe), or Mach-O executable
    Packaging
    The binary is zstd-compressed into the bundle; the runtime segment is 0 bytes.

  • Python

    Versions
    3.10 to 3.13
    Build inputs
    .py, .whl, requirements.txt, pyproject.toml, or a uvicorn, FastAPI, or Celery directory
    Packaging
    A relocatable python-build-standalone interpreter and site-packages, isolated from host Python with PYTHONNOUSERSITE=1.

  • Java and Kotlin

    Versions
    JVM 17, 21, 25
    Build inputs
    Fat .jar, .war, or a modular JAR directory
    Packaging
    jlink and jdeps assemble a minimal stripped JRE of about 35 to 50 MB, with sandbox-aware heap sizing.

  • Node.js, Deno, Bun

    Versions
    JavaScript and TypeScript
    Build inputs
    .js, .mjs, or .ts entrypoint with package.json and a lockfile
    Packaging
    A static runtime binary plus a deterministic node_modules bundle with module resolution rooted in the bundle.

The platform matrix and early access

Performance

Small, fast, and exact.

The Executor’s performance specifications, each stated with the conditions it is measured under on the benchmarks page.

All benchmarks and conditions
  • NFR-BIN-01

    Supervisor binary overhead

    < 3.0 MB

    Added to each wrapped executable by the core supervisor; under 6.0 MB for the extended variant

  • NFR-LAT-01

    Startup overhead

    < 15 ms

    Warm startup overhead; under 350 ms on the first, cold run

  • NFR-STP-01

    Immediate stop latency

    < 5 ms

    From exit-event evaluation to a fully terminated tree of 50 worker processes

  • NFR-CAP-01

    Strict cap accuracy

    ≤ 2%

    Maximum CPU overshoot over any 1-second window; memory never exceeds its cap

Requirements and fit

When the Executor is the right tool, and when it is not.

The limits below follow directly from how the Executor works. Read them before you choose it.

A strong fit when

  • You ship one service, or a few, to hosts you do not fully control: customer sites, on-premise servers, VMs, or containers
  • You need hard runtime cutoffs, license leases, or remote revocation without changing application code
  • You want CPU and memory limits, sandboxing, and scaling to travel with the application instead of the platform
  • Your workload is a native binary, Python 3.10 to 3.13, a JVM 17, 21, or 25 application, or Node.js, Deno, or Bun

Requirements and limits

Auto-scaling is single-host
Replicas run on the host the binary runs on, behind its built-in load balancer. Spreading a service across many machines remains the job of your platform.
Strict caps need a kernel hard limit
On Linux that is a delegated cgroups v2 subtree or a systemd user scope. Without one, a strict cap refuses to start with exit code 69 unless resources.allow_governor_fallback is set. On macOS caps are enforced by a supervisor governor that samples the tree, within a documented tolerance.
Auto-scaling needs caps
Scaling thresholds are percentages of the per-replica cap, so every metric used for scaling must have a cap.
Containers limit the sandbox
Unprivileged containers often block nested namespaces. auto mode layers what the container allows; strict mode refuses to launch instead.
Caps change only with a rebuild
A sealed cap is immutable at run time by design. Changing it means a new signed build.
Four brokers natively
Kafka, MQTT, NATS, and Redis are built in. AMQP and cloud queues are reached through the webhook or command exit events.

FAQ

First questions, answered.

All Executor questions

docs.openeng.ai (opens in a new tab)

What is the Open Engineering Executor (OEE)?

The Open Engineering Executor (OEE) is a Rust-native, polyglot runtime wrapper and OS-level sandbox supervisor that packages an application, its language runtime, and its security policy into one signed executable. You bring a built application, select its runtime, give the start command, configure exit events, CPU and memory caps, and auto-scaling, and receive one binary file that runs the application under every restriction you configured. It is operated through one CLI, oee.

Which languages and runtimes does OEE support?

Native binaries (Go, Rust, C, and C++ as ELF, PE, or Mach-O executables), Python 3.10 to 3.13 (a .py entrypoint, .whl wheels, requirements.txt, pyproject.toml, or a full uvicorn, FastAPI, or Celery directory), Java and Kotlin on JVM 17, 21, and 25 (fat .jar, .war, or a modular JAR directory), and Node.js, Deno, or Bun (.js, .mjs, or .ts with package.json and a lockfile). The language runtime is bundled into the binary, so the host needs no Python, Java, or Node installation.

Which platforms does OEE run on?

Linux on x86_64 and aarch64, macOS on aarch64 and x86_64, Windows on x86_64, and OCI/Docker containers, where the binary runs as PID 1 in scratch, distroless, or alpine images. oee build cross-compiles, for example building a windows-x86_64 binary from Linux CI.

Launching soon. Get early access.

Tell us which platforms and runtimes you run, and what the binary must enforce. Write to hello@openeng.ai, and we will reply with early access details.

Request early accessSee downloads