Node.js · Workers Implementation

Node.js with KERNSTACK workers

Node.js runs on KERNSTACK as workers: container processes with "runtime": "nodejs", declared with their sizing, optional HTTP port, and idle behaviour. Existing servers land as-is behind a gateway route; background processors pair with workflows; and the JavaScript a team already writes becomes the long-running half of a declared project instead of a service on somebody’s VM.

Container Workers stack.json IaC

Talk to us Read Technical Documentation → Software Lifecycle Cloud →

Node.js Workers

The declaration is the operations manual: runtime, memory (512 MiB default, up to 1024), CPU cores (2 default, up to 8), an invoke timeout, and the idle policy. min_instances: 0 with an idle timeout means the API sleeps between uses and bills storage; a customer-facing server keeps min_instances at 1 and pays for exactly one warm process, knowingly.

Frameworks keep their habits — an Express, Fastify, or Nest server listening on its port, a BullMQ-style processor as a non-HTTP worker. The platform adds what the framework never had: the same plan review, the same secrets injection (environment variables resolved from ref-secret references), and the same per-project meter as the Go functions beside it.

TypeScript teams should note the platform’s one firm line: handlers in TS become workers, never Wasm functions. In practice this is liberating — the entire npm ecosystem is available, and function-versus-worker becomes a duration decision instead of a language negotiation.

CLI

Plan Node.js Workers, then deploy.

Terminal — CLI workflow kernstack cli

kernstack add worker --name api --blueprint work-nodejs-minimal
kernstack plan
kernstack deploy

Docs for Node.js Workers. Workers on the platform.

nodejs-workers.txt Node.js

kernstack add worker --name api --blueprint work-nodejs-minimal
# or bring an existing server: workers/api with your start command + http_port
kernstack plan
kernstack deploy --only worker:api

stack.json — Node.js + workers plan · deploy

{
  "gateway": { "routes": [{ "name": "api", "target": { "kind": "worker", "name": "api" } }] },
  "resources": {
    "workers": [{ "name": "api", "runtime": "nodejs", "http_port": 3000,
      "memory_mb": 512, "idle_timeout_ms": 300000, "min_instances": 0 }]
  }
}

FAQ

Frequently asked questions

Can we deploy an existing Express/Fastify app unchanged?

In almost all cases yes: point the worker at the app, set http_port, add the gateway route. Environment variables arrive from declared secrets; the code keeps reading process.env as it always has.

How do background jobs work in Node?

As non-HTTP workers triggered by workflow steps or schedules. Pair them with declared workflows for ordering, retries, and human steps rather than hand-rolling a queue consumer’s discipline.

What does an idle Node worker cost?

With min_instances: 0, nothing on compute after its idle timeout. The next invocation starts it again; customer-facing APIs usually keep one warm instance as a deliberate, visible line.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →