platform

Neutron Web

Four deploy targets, one codebase. Edge, Node/Bun, serverless, static — the adapter is one line in your config.

Build once. Deploy where it fits.

Available

4Deploy Targets

1 lineConfig Change

ViteSame Build Tool

SSR+StaticPer-Route

The deploy target isn't a rewrite.

Most frameworks assume one infrastructure. Neutron Web assumes the opposite: that you'll prototype locally, ship the first version to a static CDN for $0, move to edge when latency matters, and eventually land on a Node box for WebSocket fan-out — and you shouldn't have to rewrite anything. The only thing that changes is a single line in neutron.config.ts.

neutron.config.ts
import { defineConfig, adapterStatic, adapterNode, adapterCloudflare, adapterVercel } from "@neutron-build/core";

export default defineConfig({
  runtime: "preact",
  // adapter: adapterStatic({ precompress: true }),
  // adapter: adapterNode({ port: 8080 }),
  adapter: adapterCloudflare({ compatibilityFlags: ["nodejs_compat"] }),
  // adapter: adapterVercel({ regions: ["iad1"] }),
});
Swap adapters in one line. Everything else stays the same.

Edge

Cloudflare Workers, Vercel Edge, Deno Deploy, Fastly. Instant cold start, global deploy, KV & D1 bindings where available.

Node / Bun

Long-running servers for full WebSocket and SSE support, connection pooling to Nucleus, and anything that outgrows a cold-start budget.

Serverless

AWS Lambda, Vercel Functions, Netlify Functions. Pay-per-request auto-scaling. Per-route split between static and function targets.

Static

Cloudflare Pages, Netlify, GitHub Pages, S3 + CloudFront. Pre-rendered HTML with islands that hydrate — zero server cost.

Target	Cold start	Global latency	WebSockets	Nucleus access	Sweet spot
Static	N/A	<20ms (CDN)	No	Build-time only	Marketing sites, docs, blogs
Edge	~0ms	<20ms worldwide	Durable Objects	Via connection pooler	Dynamic pages, global APIs
Node / Bun	Always on	50–200ms (1 region)	Full support	Direct pool	Long-running APIs, real-time
Serverless	50–200ms	50–200ms	Limited	Pooler recommended	Spiky workloads, webhooks

Hybrid by default.

The same app can split itself across targets. Static-render the marketing pages to a CDN, ship the app shell to the edge, keep the WebSocket server on Node. Per-route config = { mode: "static" } vs { mode: "app" } controls this, and the deploy step emits the right artifact for each target.

src/routes/docs/[...slug].tsx
export const config = { mode: "static" };
// Pre-rendered to HTML at build. Zero JS. CDN-served.
Static-rendered doc page.

src/routes/chat.tsx
export const config = { mode: "app", runtime: "node" };
// Long-running, keeps WebSocket connections open, hydrates in the browser.
App-mode WebSocket handler.

What it's for

Any web app where you don't yet know which deploy target will win. Marketing sites that need to be free. APIs that need to be fast. Apps that need WebSockets. Things that start static and grow into something else — without rewriting the router, the data layer, or the build.

Why per-route adapters?

Because the answer to "edge or server" is rarely the whole app. Product pages belong on a CDN; the checkout belongs on a server. Docs belong static; search belongs at the edge. Neutron builds all of them from one source and hands your deploy target exactly what it knows how to run.

Part of a bigger system

Whatever target you pick, your app reads from Nucleus through the same wire protocol. Add a Rust service for hot paths, a Python MCP server for AI tools, a Go worker for jobs — all reading the same database. Neutron Web is one client among many.