Why rune

There is no shortage of web frameworks. rune exists because the EkkoJS runtime makes a different set of trade-offs possible, ones that remove whole categories of tooling and ceremony.

No install step, no node_modules

rune is part of the runtime. @ekko/react, @ekko/react-dom, and component libraries like @ekko/asgard come from the EkkoJS package store and are declared in ekko.json. There is no node_modules folder to balloon to hundreds of megabytes, no lockfile drift, no "works on my machine" caused by a transitive dependency. The packages you ship are the packages you declared.

The backend and the frontend are the same program

In a conventional stack, your React app talks to an API server over HTTP, and the two are separate codebases, deployments, and type boundaries. In rune, the page that renders and the API route that serves data are functions in the same process. A value computed once at startup is shared by import, not refetched.

SSR and SPA without choosing

Frameworks usually ask you to pick: a static-export SPA (great DX, bad first paint and SEO) or a server renderer (good first paint, heavier). rune gives you both, in sequence, with no configuration: every page is server-rendered for the first paint and crawlers, then the same page becomes a client-navigated SPA after hydration. You do not opt in per route; it is the default behaviour of createApp.

State that survives the things that usually destroy it

Navigations and refreshes are where most apps lose their UI state. rune's Mimir keeps state in atoms outside the component tree, so a client navigation preserves it, and a session-backed atom is restored from IndexedDB after a reload. The server can also pre-seed atoms so the hydrated page already has the right values. You stop writing the same "load from localStorage in a useEffect" boilerplate on every component.

Security you do not have to bolt on

The runtime is deny-by-default. A rune app cannot read the filesystem, open sockets, or read environment variables unless its ekko.json (or a --allow flag) grants that capability, and grants can be scoped (fs: "./data/**", net: "localhost:*"). A compromised dependency cannot quietly exfiltrate files or call home. This is the runtime's model; rune just inherits it.

A production story that is a runbook, not a research project

Deploying a rune app is: build the client on your machine, ship the folder plus the runtime to a Linux box, run it under systemd, and put nginx + Let's Encrypt in front. That is the whole list. There is no build farm on the prod host, no container orchestration required, no edge-function vendor lock-in. See Production deploy for the exact, copy-pasteable steps, the same ones used to put this very site on the internet.

When rune is a good fit

• Content and product sites that need real SSR + SEO and app-like client navigation.
• Dashboards and tools where state should survive navigation and refresh.
• Anything you want to run as a single, auditable process with explicit capabilities.

When it might not be

• If you need a sprawling microservice mesh, rune is the app tier, not the mesh.
• If your team is committed to the npm/webpack ecosystem and its plugins, rune's "no node_modules" model is

a different world (a better one, we think, but a change).

Next: a picture of how it all fits together, Architecture.