Nordcraft
Build high-performance server-rendered web apps with a visual editor, formula engine, and self-hostable backend — all in TypeScript.
Nordcraft is an open-source web development engine that provides the core packages powering the Nordcraft visual editor and runtime. Built as a TypeScript monorepo, it delivers a complete stack for creating performant web applications with server-side rendering, dynamic component composition, and a reactive formula system for data transformation.
The engine is organized into focused packages: core defines shared types and the formula evaluation system, ssr handles server-side rendering of components and API proxying, runtime drives client-side hydration and state, lib ships built-in formulas and workflow actions, search powers the issue detection panel via web workers, css-parser parses and stringifies CSS in the style editor, and backend wraps it all into a deployable Hono server that runs on Cloudflare Workers, Node.js, or Bun.
Nordcraft is progressing toward full open-source availability with a goal of enabling complete self-hosting. The v2.0 release brought the backend and editor packages into the repository, making it possible to self-host the SSR layer and serve Nordcraft-built apps from your own infrastructure using Docker or Cloudflare Workers.
The project publishes all packages to npm under the @nordcraft scope and follows a rapid release cadence — over 130 tagged releases since launch — with active contributions and a growing community on Discord.
What You Get
- Core Package - Shared TypeScript types, formula evaluation engine, component schemas validated with Zod, and utility functions used by every other package in the monorepo.
- SSR Package - Server-side rendering logic that converts Nordcraft component trees into HTML, resolves data from APIs during render, handles cookies and themes, and generates sitemaps and speculation rules.
- Runtime Package - Client-side hydration layer that synchronizes the live DOM with component state, runs workflows triggered by user interactions, and manages reactive data bindings.
- Std-Lib Package - Built-in formulas (math, string, array, object, JSON, date/time, ID generation) and workflow actions (fetch, cookie set, navigation) available in the visual editor and SSR pipeline.
- Search Package - Issue-rule engine that traverses a Nordcraft project graph to detect unused packages, invalid CSS variables, animation problems, and workflow misconfiguration — runs in a web worker in the editor.
- CSS Parser Package - Parses and stringifies shorthand CSS properties (flex, font, border, animation, transition, gap, etc.) to power the style panel in the Nordcraft visual editor.
- Backend Package - Production-ready Hono server with routes for SSR page rendering, API proxying, cookie management, custom elements, fonts, robots.txt, sitemap, and service workers — deployable to Cloudflare Workers or packaged as a Docker container.
Common Use Cases
- Self-hosting a Nordcraft app - A team exports a project from the Nordcraft editor, drops the JSON into the
__project__folder of the backend package, builds a Docker image with the included Dockerfile, and deploys it to their own server with full SSR and API proxying. - Deploying to Cloudflare Workers - A developer runs
bun run deployfrom the backend package to push a minified Nordcraft backend to Cloudflare’s edge network, serving SSR pages globally with sub-millisecond cold starts. - Embedding Nordcraft components as custom elements - A frontend team registers individual Nordcraft components as standard Web Components using the
/.toddle/custom-element/:filename.jsendpoint and embeds them in an existing site without a full page reload. - Building reusable formula libraries - A developer extends the
libpackage with domain-specific formulas (currency conversion, data normalization) and consumes them in Nordcraft workflows and SSR rendering. - Detecting project issues in CI - A team wires the
searchpackage into a CI pipeline to run issue rules against exported Nordcraft project JSON and fail builds when unused components or invalid CSS variables are detected. - Parsing and transforming CSS programmatically - A tooling author uses the
css-parserpackage to parse shorthand CSS from a design token file and convert it into per-property values for a downstream build tool.
Under The Hood
Architecture
Nordcraft is structured as a strictly layered monorepo where dependency direction flows from core outward: core → lib → ssr → search, with the backend package consuming ssr and core to serve HTTP traffic via Hono. Each package owns a single responsibility and exposes only a typed public API, enforced by TypeScript project references and workspace-scoped isolation. The backend uses a factory function (getApp) that accepts injected loaders for page files, stylesheets, and custom code, decoupling the server routing logic from the file-system or edge-storage mechanism used by each deployment target. This makes the same server code run identically on Cloudflare Workers (via wrangler), Node.js (via @hono/node-server), or Bun’s native HTTP runtime. The CSS parser, editor types, and search packages are strictly optional build-time dependencies that never load at SSR request time.
Tech Stack
The entire codebase is TypeScript using the new tsgo compiler for incremental builds across packages. Hono provides the HTTP server layer with middleware for timing, powered-by headers, and cookie injection. Bun is the runtime and package manager, with its native test runner (bun:test) and happy-dom providing a browser-like DOM environment for unit tests. esbuild handles bundling for production deployments. The backend ships as either a compiled single-binary Bun executable or as a Cloudflare Worker bundle via wrangler. Zod 4 is used in the core package for runtime schema validation of component and formula structures. There is no traditional database; project data is loaded from JSON files (or Cloudflare Durable Objects in hosted mode) at request time.
Code Quality
The repository has extensive automated test coverage across 248 test files, covering formula evaluation, component traversal, CSS parsing, SSR rendering, API proxy behavior, routing logic, and cookie handling. Tests use bun:test with describe/expect conventions and happy-dom for DOM-dependent assertions. Each formula type (and, or, switch, path, record, array, apply, function) has a dedicated test file with edge-case coverage. Linting is enforced via ESLint with TypeScript and HTML-specific plugins, and Prettier with organize-imports keeps formatting consistent across the monorepo. The codebase consistently uses explicit TypeScript generics, null/undefined guards, and typed handler patterns throughout the backend and SSR layers.
What Makes It Unique Nordcraft’s most distinctive technical trait is treating every application artifact — components, formulas, workflows, API calls, styles — as serializable JSON that can be evaluated server-side and client-side from the same data structure. The SSR package does not template HTML strings; it walks the same component graph the runtime uses on the client, applying the same formula engine at render time, which means server and client behavior are structurally identical with no hydration mismatch risk. The backend’s proxy route performs template interpolation on outgoing API URLs and headers using cookie values at the server edge, functioning as an embedded API gateway without a separate service. The CSS parser handles shorthand expansion bi-directionally, enabling the visual editor to parse existing CSS into editable fields and reconstruct it without loss of specificity.
Self-Hosting
Nordcraft is released under the Apache License 2.0, a permissive open-source license that allows commercial use, modification, distribution, and private use without requiring derivative works to be open-sourced. There are no copyleft obligations: you can embed Nordcraft packages in a proprietary SaaS product, modify the source code without contributing changes back, and redistribute compiled binaries in commercial software. The only requirements are attribution (preserving copyright notices) and including the license text.
Self-hosting the Nordcraft backend requires running the backend package as a Hono server on your own infrastructure. The project ships a Dockerfile using a distroless Debian base image that compiles the TypeScript into a standalone binary — making deployment straightforward on any container platform. Alternatively, the wrangler.toml in the backend package supports deployment to Cloudflare Workers for edge hosting without managing servers. You are responsible for supplying project JSON (exported from the Nordcraft editor), managing static assets (CSS and custom-code JS files), and handling uptime, TLS termination, and scaling. There is no bundled database or persistent storage layer; state lives in the project JSON files you provide.
Compared to the hosted Nordcraft cloud platform, self-hosting means you manage upgrades manually by tracking npm releases under the @nordcraft scope (the project publishes over five releases per month). The hosted cloud tier provides the full visual editor, collaborative branching, version history, preview environments, and managed SSR infrastructure with zero operational burden. Self-hosters get SSR serving and the published runtime packages but do not get the proprietary editor, the Durable-Object-based preview system, or the managed deployment pipeline. Community support is available via the project’s Discord server; there is no enterprise SLA or commercial support offering for self-hosted deployments at this time.