Devora.js
A lightweight, Vite-based, security-first web framework whose headline feature is native multi-app support — one project, multiple sites or panels (marketing site, main app, admin panel), sharing a core, deployable independently.
npx create-devora@latestWhy it exists
Two problems, solved at the framework level instead of papered over with tooling.
Most teams building a marketing site, a product app, and an admin panel end up either bolting three separate repos together with a monorepo tool, or cramming all three into one Next.js app and fighting its App Router for the seams between them. Devora.js treats multi-app as a first-class concept: apps live side by side in one project, share one core and one backend by default, and each can still be deployed independently.
The other half of the pitch is a direct reaction to Next.js: explicit over implicit. Caching, data flow, and server/client boundaries are visible in your route files, not inferred from file-naming conventions or hidden behind multiple layers of framework-managed revalidation.
- Caching layered and inferred across fetch, route segment, and framework defaults
- Server/client boundary guessed from directives and file position
- Revalidation timing lives inside framework internals
renderModedeclared per route:ssr/ssg/csr/isrloader/actionexported explicitly for data and mutationsrevalidate: { seconds }written in the route file itself
Security follows the same philosophy: it's a default, not a plugin. CSP and HSTS headers are on for every app out of the box, and there's no dynamic eval/require path anywhere reachable from user input.
What you get
Six things the framework handles so your app code doesn't have to.
Multi-app, first-class
Marketing site, product app, and admin panel live side by side in one project, sharing a core — not bolted together with a separate monorepo tool.
Explicit over implicit
Render mode, data loading, and server/client boundaries are declared right in the route file — nothing caches on a schedule you didn't write down.
Security by default
CSP, HSTS, and signed sessions are on for every app out of the box — you opt out, not in.
Bring your own backend
One shared backend for server functions and your DB client of choice — no built-in ORM or auth provider forcing your hand.
Four render modes
ssr, ssg, csr, and isr, chosen per route — this page itself is ssg, pre-rendered once at build time.
Islands, not full hydration
Opt a single component into client hydration while the rest of the page stays static HTML — the real fix for React's hydration cost.