Platform · Compute

KERNSTACK Workers

Workers are KERNSTACK’s container processes for everything that outlives a request: transcoders, importers, report builders, queue drainers, your own HTTP servers. A worker declares its runtime — binary (a compiled Go program), nodejs, python, or php — plus memory and CPU sizing, an optional HTTP port, idle timeout, and instance limits, all in stack.json.

Container Workers

Talk to us Read Workers Docs → Software Lifecycle Cloud →

Why teams replace assembled cloud services with KERNSTACK Workers

Teams otherwise run a Kubernetes deployment, an ECS service, or a forgotten VM for every background job. On KERNSTACK the long-running half of a product is a declaration beside the functions, reviewed in the same plan and metered from the same balance.

How workers are shaped

A worker can serve HTTP on its own http_port behind a gateway route ({ "kind": "worker" }), receive workflow steps, and mount bucket volumes when large files should look like a filesystem (a model-data volume over a bucket prefix is the canonical case). Start commands can be overridden, system packages come from a platform catalog, and each invocation can carry a timeout.

Sizing and idling are declared, not discovered

Defaults are 512 MiB and 2 cores, up to 1024 MiB and 8 cores. idle_timeout_ms stops an instance after quiet; min_instances: 0 means scale to zero; max_concurrent bounds how much one instance pulls. Warmth is therefore a priced decision per workload — the latency-sensitive worker stays warm on purpose, the nightly one sleeps twenty-three hours a day on purpose.

Websocket routes cannot target workers — they belong to functions; everything else HTTP can
Worker storage and volumes follow the project’s bucket rules and zone
One-off and scheduled work usually pairs workers with workflow triggers and cron

SDKs & Language Integration

Every KERNSTACK environment vendors typed SDK packages into .kernstack/ so both engineers and coding agents in Agent Sandboxes can call Workers without external credentials:

Go SDK: github.com/coding-berlin/kernstack-sdk-go/sdk_workers
Node.js SDK: kernstack-sdk
Python SDK: kernstack_sdk
PHP SDK: Kernstack\Workers

Implementation guides for Workers

Node.js + Workers → PHP + Workers → Python + Workers →

Workers in the Project Graph

Declarestack.jsonworkers

RunWorkersinfrastructure

MeterOne credit balanceEU zone

stack.json — workers configuration plan · deploy

{
  "resources": {
    "workers": [{ "name": "jobs", "runtime": "nodejs",
      "memory_mb": 512, "cpu_cores": 2,
      "idle_timeout_ms": 300000, "min_instances": 0 }]
  }
}

Metering · compute, storage, or network 1 Shared Balance

Compute is 0.01 credits per GiB-second on the shared environment balance.

Replaces: AWS ECS · Cloudflare Containers · no direct equivalent

FAQ

Frequently asked questions

Is a worker a Kubernetes deployment in disguise?

No. There is no cluster, namespace, or YAML fleet to operate. You declare a process with a runtime and sizing; the platform runs it in the project’s zone and meters its GiB-seconds.

Can a worker run our existing Node.js server?

Yes — runtime nodejs with your start command and http_port. Framework servers, GraphQL servers, and legacy services land this way; the gateway route in front of them is one declaration.

Do workers have to run 24/7?

Only if you declare min_instances above zero. With min_instances: 0 and an idle timeout, instances stop when quiet and restart on the next invocation or workflow step.

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 →