WHY EDITABLE?
Simple for your clients. Full control for you.
Most CMSs are too complex for clients and too restrictive for developers. Change every pixel of your site, create new content types, or integrate 3rd-party data. Everything you can do with Svelte, you can do with Editable.
Made for people who build websites
YOUR DATA MODEL
Model content your way
Testimonials, team members, events, recipes: define any node type and its properties in code, then write one Svelte component for it. That component is both the live page and the editor. No admin panel to configure, no preview to keep in sync.
MOTION
Make it move
Reveal sections as visitors scroll, animate what matters, and give every brand its own feel. Svelte has transitions and actions built in, and Editable comes with a scroll reveal you can use, tweak, or replace.
YOUR DESIGN SYSTEM
A design system, not a theme
Build your own modular blocks, give each the layouts it needs, and switch whole sections between color sets. It’s all Svelte and Tailwind, in code you can read. Clients compose pages from your blocks, so the design holds whatever they do.
3RD-PARTY DATA
Fetch data from anywhere
Show events from a ticketing service, products from a shop, or reviews from wherever they live. With Svelte’s async components and SvelteKit’s remote functions, a query runs on the server, and your component simply awaits it.
MORE THAN PAGES
Bookings, shops, members areas
When a client needs online booking, a small shop, or a members area, add it as a route like /book. It sits right next to the pages they edit and uses the same nav, footer, and components. It’s all SvelteKit, so anything you can build there fits in.
REUSE ACROSS CLIENTS
Your own starting point
Turn your best work into a starter: your blocks, layouts, and conventions. Start every new client from it, pull in Editable releases with git, and spend your time on what makes each site unique.
WHITE LABEL
Build your own product on top
Think of a white-label website builder for restaurants that a hosting company runs under its own brand. Or a site kit for architects. Editable can serve many sites from one process and plug into your own sign-in, so you can tailor an edition to exactly one audience.
Products like these need a separate license agreement. Let’s talk.
YOU OWN IT
One codebase. That’s it.
A headless CMS means two systems, an API between them, and someone else’s roadmap. With Editable, the editing infrastructure and the components that make up the website live in one codebase. You depend on no one: it’s your code and your data.
Questions developers ask
How is Editable different to a CMS?
The editing infrastructure (Svedit) becomes an integral part of your website (at runtime). As a developer, all you do is define content types (e.g. Figure) and implement components (e.g. Figure.svelte) — they are editable by default.
Can I still update Editable after changing everything?
Yes. Your site keeps Editable as its upstream remote, so new releases are one git merge away. Conflicts only happen in files you changed, and you resolve them like any other merge.
What do I need to know?
Svelte, SvelteKit, and Tailwind. Everything else is plain TypeScript in your repo: the schema, the components, and the storage on SQLite.
How about React, Vue, Solid, or Remix?
Editable is built on Svelte, but its codebase is small enough that your coding agent can port it to the framework of your choice. We’ve tried it, with great results. Just know that you then own the build and keep it in sync with new Editable releases yourself. That’s manageable with an agent, too.
Where does it run?
Anywhere Node.js runs. Content lives in SQLite and a folder of assets. The repo includes a Dockerfile and fly.toml for one-command deploys to Fly.io, and the same Dockerfile works on any platform that supports Docker.
Where is the data stored?
All content lives in a single data directory — an SQLite database (db.sqlite3) and uploaded assets (data/assets). Locally this defaults to ./data. On Fly.io it's a persistent volume at /data. To back up your site, copy this directory.
Why no static builds?
There's no point for static builds with Editable. The whole idea is that users edit content live, without having to wait for a rebuild to finish. SQLite is fast. Very fast. Web-optimized images are generated client-side before upload: resizing happens in the browser via canvas and toBlob(), and WebP encoding is done with @jsquash/webp. It still makes sense to enable a proxy (like Cloudflare) for images, so they can be delivered from a CDN.
Can I use plugins?
Editable is modular and you can and should reuse code across projects. However, I purposely don't want to establish a community-maintained plugin repository. I want to encourage you to own all your code, for the benefit of simplicity, safety, and control. Share specifications and code snippets, not plugins.
Hack it to the core
Editable is your starting point to build anything. Install it, dig into the code, and change whatever you like.