Docs

Introduction

What is rune

Philosophy

Why rune

Architecture

Getting Started

Installation

Quick start

Project structure

The dev loop

Tutorial: build an app

1. Create the app

2. Pages & routes

3. Layouts

4. State with Mimir

5. SSR & data

6. API routes

7. Styling

8. Build & deploy

Core Concepts

The application object

Rendering pipeline

Hydration

The build manifest

Configuration (ekko.json)

Permissions

Conventions

Routing

File-based routing

Dynamic routes

The router (useRouter)

Navigation & Link

Guards & redirects

Programmatic routes

Server-Side Rendering

Overview

The ssr() function

Strategies (eager/lazy)

SSR → hydration

Caching & invalidation

SEO

Mimir, state management

Overview

Atoms

Reading & writing

Selectors (derived state)

Subscriptions & the store

SSR & hydration

Persistence & sessions

Patterns & recipes

Pitfalls

Pages & Layouts

Pages

Layouts

Error & not-found

API Routes

Defining routes

Request & response

Middleware

Validation & options

Styling & Theming

SCSS

Theming (light/dark)

Asgard integration

No flash (no-FOUC)

Building & Deploying

The build

Static assets

Production deploy

API Reference

ekko:rune

ekko:rune/router

ekko:rune/mimir

ekko:rune/seo

ekko:ssr / css

ekko.json schema

CLI commands

Recipes

Dark mode

Forms

Data fetching

Authentication

Pagination

ekko:rune

rune is the full-stack application framework built into EkkoJS. It turns a folder of .tsx files into a server-rendered, instantly-navigable web application, with typed routing, a built-in state layer (Mimir), SSR caching, SEO, and a single-command production build, and no bundler config, no node_modules, no separate API server to wire up.

You write React components. rune renders them on the server for the first paint, ships a tiny hydration bundle, and from then on every navigation happens on the client with zero network round-trips. State lives in atoms that survive navigation and page reloads. The same server.tsx that serves your pages also serves your API routes. One runtime, one process, one mental model.

00000000001
2
3
4
5
6
7
8
// server.tsx , the whole backend
import "@ekko/react";
import "@ekko/react-dom/server";
import { createApp, scanRoutes, readManifest } from "ekko:rune";
 
const app = createApp({ port: 3000, manifest: readManifest() });
for (const r of scanRoutes("pages")) app.page(r.pattern, modules[r.pattern], { page: r.pageKey });
app.start();

00000000001
2
3
// pages/index.tsx , a page
export function ssr() { return { title: "Home" }; }            // runs on the server
export default function Home() { return <h1>Hello rune</h1>; }  // SSR'd, then hydrated

What you get

File-based routing , pages/about.tsx becomes /about, pages/blog/[slug].tsx becomes /blog/:slug.
Server-side rendering with three strategies (eager, background, lazy) and a built-in HTML cache with

tag and path invalidation.

Client-side navigation , after the first load the router swaps pages in place; no reloads, no flashes.
Mimir , an atom-based state store that is reactive, server-hydratable, and optionally persisted to

IndexedDB so it survives an F5.

Layouts , a root shell and nested per-segment layouts composed automatically.
API routes , app.api("GET", "/api/...", handler) in the same app.
SEO , createSEO() emits <title>, Open Graph, Twitter, canonical, robots and sitemaps.
A real build , ekko build --client produces a content-hashed, code-split browser bundle and a

manifest the server reads to wire up <script> and modulepreload tags.

How to read these docs

If you are new, start with What is rune and the Philosophy, then follow the Tutorial to build an app end to end. The Core Concepts and per-area chapters (Routing, SSR, Mimir, API, Styling) go deep, and the API Reference is the exhaustive, signature-level companion.

This site is itself a rune application. Everything you read here is server-rendered on first load and then navigated entirely on the client, the very behaviour the docs describe.

On this page

What you get How to read these docs