@enfyra/kernel

Enfyra kernel runtime package.

Dynamic context

The isolated executor snapshots cloneable $ctx keys into the sandbox automatically. Runtime platforms can expose new data fields from their own context factory without changing the kernel, while protected runtime capabilities such as $helpers, $cache, $repos, $socket, $throw, $trigger, $logs, $req, and $res stay kernel-managed. $env is readable inside the sandbox when provided by the host application, but sandbox mutations to $env are not merged back to the host context.

Use

import { createEnfyraKernel } from '@enfyra/kernel';

const kernel = createEnfyraKernel({
  knexService,
  mongoService,
  databaseConfigService,
  runtimeMetricsCollectorService,
  lazyRef,
  getPackageCacheService: () => packageCacheService,
  getPackageCdnLoaderService: () => packageCdnLoaderService,
});

container.register({
  queryBuilderService: asValue(kernel.queryBuilderService),
  isolatedExecutorService: asValue(kernel.isolatedExecutorService),
  executorEngineService: asValue(kernel.executorEngineService),
});

Executor lane tuning

The executor selects up to two runner processes and sizes physical isolate lanes from the effective CPU and memory limits. CPU establishes a baseline of two lanes per effective CPU and a flexible ceiling of four lanes per effective CPU. Available RAM can raise the target from the baseline toward that ceiling. The memory bound uses its raw safe lane count, reserving at most 25% of effective memory for isolate limits, with an absolute ceiling of 128 lanes per runner.

Each physical isolate admits up to six concurrent task contexts. This bounded multiplexing raises I/O throughput without recreating the old all-or-nothing worker failure domain: cancellation, native execution timeout, or isolate OOM disposes the affected isolate and fails only its sibling tasks with ERR_EXECUTOR_ISOLATE_LOST. The runner stays available for new work. This is a kernel policy, not a deployment environment setting.

Run yarn bench:executor-lanes --tasks-per-isolate 1,2,4,8 on the target hardware to sweep physical lane counts and task fan-in using I/O-bound and CPU-bound scripts. Use the smallest fan-in whose I/O queue wait has materially improved while CPU p95, runner RSS, and the isolate failure blast radius remain within the deployment budget.