operations · decision guide
Choose the process boundary first.
Match LocalNika, nika serve, the OS bridge, model serve or the preview HTTP client to the job each one actually owns.
A product request, a project clock, a host scheduler, an inference endpoint and a workflow API are different boundaries. Choosing by job prevents the word server from turning them into one false architecture.
Use LocalNika when product code starts the run.
An API handler, worker or desktop application can check and spawn the released binary directly. The application owns cancellation and presentation. The engine owns the workflow, boundary and receipt.
const run = nika.run('workflows/support.nika.yaml', {
vars: { ticket: request.id },
signal: request.signal,
})Use serve or the OS when time starts the run.
A container or VM with no scheduler keeps nika serve resident. A host already governed by launchd or systemd can emit user units. Both consume the same arm registry and end at the same firer.
container / bare VM ── nika serve ──────┐
├── arm fire law
managed host ───────── launchd / systemd ──┘Use model serve only as an inference provider.
nika model serve listens on loopback with an OpenAI-compatible model API. The engine calls it for inference. It does not accept workflow jobs and application code should not confuse it with the SDK service horizon.
nika model serve --model Qwen/Qwen3-0.6B-GGUF --port 8712Keep the root SDK behind a preview gate.
The root Nika client types a future jobs, workflows, SSE, artifacts and webhook service. The reference engine does not ship that compatible HTTP API today. Build adapters against the types, but do not route production traffic to nika serve.