Node

Node is what you get when you don't configure a platform at all. It's also the only target that supports every Heximon feature natively — a long-lived process can run an in-process cron timer, poll a queue, hold a Durable Object shim, and run the workflow replay engine, none of which need a platform-specific primitive.

The zero-config default

Omit platform from heximon.config.ts and Heximon resolves NodeHostStrategy for you. Declaring it explicitly changes no wiring — it just makes the deploy target legible in the config file:

import { defineHeximonConfig } from "@heximon/build";
import { HttpPlugin } from "@heximon/http/compiler";
import { NodeHostStrategy } from "@heximon/node";

export default defineHeximonConfig({
  platform: new NodeHostStrategy(),
  plugins: [new HttpPlugin()],
});

NodeHostStrategy is a node-class strategy with no vendor identity (platformName: undefined) — it's not tied to any specific host provider, just "a long-lived Node/Bun/Deno process."

What vp build emits

vp build                 # → dist/server.js
node dist/server.js      # or: bun dist/server.js  /  deno run -A dist/server.js

The build synthesizes a one-line entry that hands the compiled fetch handler to @heximon/http/serve — the universal runner built on srvx, which picks node:http, Bun.serve, or Deno.serve automatically:

import { serve } from "@heximon/http/serve";
import { fetch } from "<generated fetch entry>";

await serve(fetch);

There's no on-disk artifact tree beyond that one file — the wiring is bundled straight into dist/server.js, externalizing @heximon/* and third-party deps so they resolve from node_modules at runtime (the standard Vite SSR default, unminified). No deploy-config artifact is written, because there's no vendor config to generate.

Feature support

NodeHostStrategy supports every PlatformFeatureSet flag: Durable Objects (via an in-process shim, single- instance — a caveat for a horizontally-scaled deploy), workflows (the full replay engine), cron (process-local croner timers), queue consumers, cross-service integration-event fan-out, and saga timeouts. Nothing fails loud here that would elsewhere.

Driver bindings

Node supplies concrete satisfiers for the platform-swap features so a feature compiler plugin never has to name a vendor: the schedule plugin resolves NodeScheduleDriver (self-starting croner timers on boot), and the durable/streaming namespace resolves DurableObjectShimNamespace — the in-process bridge over the generated <Name>DO class, used for both vp dev and a plain Node production deploy.

Dev

vp dev runs Node in-process — the same ViteDevHost every other target's dev fallback uses, with the full build-error page, JSON preview, recompile-on-change, and browser auto-reload. There's no emulator to boot, because Node dev already is the production runtime shape.

See also

• Deploy overview — picking a strategy and what vp build does across platforms.
• Hosts — Nitro, Nuxt, and other bundler integrations that also target Node.
• heximon deploy — the one-command build-and-ship path (reports the run command for Node; no upload).