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

helmet

cors

rateLimit

bodyLimit

validateContentType

csrf

requestId

timeout

errorHandler

httpsRedirect

secureCookies

ipFilter

safePath

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

Guides

Rune app from scratch

Recipes

Dark mode

Forms

Data fetching

Authentication

Pagination

FAQ (use cases)

`cors()`

Let browsers on other origins call your API routes, and handle the preflight request they send first.

cors request flow

Use case

The browser blocks cross-origin requests unless the server opts in. If your front-end runs on a different origin than your rune app (a separate SPA, a mobile web client, a partner site), it cannot read your API responses until you send the Access-Control-* headers. cors sends them, and answers the preflight OPTIONS request the browser fires before the real one.

How it works

For a preflight OPTIONS request it short-circuits with 204 No Content plus the allow headers. For a real request it sets the headers and calls next(). With an origin allow-list, only listed origins are echoed back in Access-Control-Allow-Origin; everything else simply receives no CORS header (and the browser blocks it).

Configuration

Option	Default	Notes
`origin`	`"*"`	A string, an array of allowed origins, or `"*"`. With an array, only listed origins are allowed and echoed back.
`methods`	`GET, POST, PUT, DELETE, OPTIONS`	Allowed methods.
`headers`	`Content-Type, Authorization`	Allowed request headers.
`credentials`	`false`	Set `Access-Control-Allow-Credentials: true` (required for cookies).
`maxAge`	`86400`	Preflight cache seconds.

Example

00000000001
2
3
4
import { cors } from "ekko:web";
 
app.use(cors());                                            // allow any origin (dev only)
app.use(cors({ origin: ["https://app.example.com"], credentials: true })); // allow-list + cookies

Notes

Do not combine origin: "*" with credentials: true, browsers reject it. Use an explicit allow-list when you need cookies. And if your front-end is the same rune app (the common case), you do not need CORS at all, same-origin requests are never blocked.

Next: rateLimit.

On this page

Use case How it works Configuration Example Notes