One project. Several apps. One backend and one login.

How the pieces fit

Three apps, one shared backend, one login — and a database that is yours to choose.

Why it exists

Caching and data flow you can read in the route file, not infer.

Security follows the same philosophy: a default, not a plugin.

To be fair to Next.js: version 16 can move the same way. With cacheComponents: true caching is opt-in through "use cache" and data fetching is dynamic by default; its docs say both become the default in the next major release. The left card describes the App Router without that flag.

import { defineProject } from "@devorajs/core/config";

export default defineProject({
  apps: [
    { name: "marketing", dir: "apps/marketing", domain: "marketing.example.com", auth: "shared" },
    { name: "dashboard", dir: "apps/dashboard", domain: "dashboard.example.com", auth: "shared" },
    { name: "admin", dir: "apps/admin", domain: "admin.example.com", auth: "shared" },
  ],
  shared: {
    core: "packages/core",
    backend: "packages/backend",
    auth: "shared",
  },
});

That file is what npm create devora@latest writes. devora dev runs every app, devora build builds each one, and a function in packages/backend is imported by whichever app needs it. CSP and HSTS headers are on by default, and sessions are revocable for apps that use auth; render modes are chosen per route in the route file.

How it compares

Fair trade-offs, not a scoreboard — these are different tools solving overlapping problems.

	Next.js	Turborepo / Nx	Plain React	Devora.js
What it is	Framework	Build/task tool	UI library	Framework
Multiple apps, one project	Multi-Zones — separate deployments, one domain	Wire it yourself, any framework	Separate project per app	Native — one config, shared core; separate deployments
Navigating between apps	Full page load	—	Full page load	Full page load — same as Multi-Zones
Shared backend	Per-app API routes / Route Handlers	Not its job	You build it	One shared packages/backend
Client JS on a static page	132 kB gzip of JavaScript on the static page of our benchmark app	—	The whole client bundle	None in the same benchmark; island() opts in one component
Security headers (CSP/HSTS)	Manual — middleware/config	—	Manual	On by default, every app
Adding a second app	New zone + rewrites/assetPrefix	New app + wire the tooling yourself	New Vite config + router	devora add <name>

What you get

Six things the framework handles so your app code doesn't have to.

One shared backend

Every app in the project calls the same functions — no API layer to write between them.

// packages/backend/notes.ts
export const addNote = serverFn(async (input, ctx) => {
  ctx.requireAuth();
  return db.notes.insert(input);
});

// apps/dashboard/routes/notes.tsx  (a form action)
// apps/api/endpoints/notes.ts      (JSON for mobile)
import { addNote } from "@devorajs/backend/notes";

Built with Devora.js

Real products running on it today.

YallaDo↗

Personal and team task tracking: a private board plus shared team workspaces.

• SSR pages
• Islands
• Sessions + CSRF
• JSON API routes
• Security headers (custom CSP)
• Vercel

Khepra↗

Landing page and early-access waitlist for a daily habits and workouts app.

• Islands
• JSON API routes
• Default security headers
• Vercel

These docs↗

This site: every page pre-rendered, with Pagefind search. The source is on GitHub.

• ssg pages
• Head API
• Sitemap
• Custom CSP
• Vercel

What each one uses is read from the deployed site (headers, cookies, markup, API responses), checked October 14, 2026.

What's next. Desktop and native mobile apps are planned goals, not started, and there are no dates. See the roadmap (also as ROADMAP.md on GitHub).

Where to go next