Documentation — version 1, scope frozen
Content lives in files.
The client edits on the page.
inline is a front-end editing system for static sites. Content is written in JSON files validated by Zod, injected into the HTML at build time by Astro, and editable directly on the page through an overlaid interface — no CMS, no database, no application server.
In three minutes
A fresh site, editable locally, with no remote repository and no host, in four commands:
npm create inline@latest my-site -- --nom "My site" --courriel contact@example.com
cd my-site && npm install
npm run mock:git # fake local repository, in a first terminal
npm run build # build the site
npm run serve:functions # serve the site AND the functions
Open http://127.0.0.1:8788/admin, enter the key printed at creation time, click a
piece of text, change it, publish. Step by step:
Local setup.
Where to start
Understand
Why this tool exists
The real problem, the options ruled out, and the decisions that follow.
Understand
How it works
Two flows, two coupling points, eleven absolute rules.
Get started
Local setup
Requirements, scaffolding, site key, fake repository, first publish.
Tutorials
A complete site, A to Z
Three pages, two languages, every content type. From the first “npm create” to the first publish.
Tutorials
Porting an HTML site
An existing site — pages, stylesheet, script, images — ported file by file.
Build
The content model
Three field types, lists with stable ids, one Zod schema.
Build
Adding a page
From the JSON file to the component on the page, routing included.
Build
Theme and styles
One file to adapt, and why the client never picks a free-form colour.
Ship
GitHub, end to end
Repository, machine account, restricted token, CI, deployment.
Ship
GitLab, end to end
Actual support status, the implementation to write, CI and deployment.
Edit
Editing simulator
The client journey reproduced in the page: key, overlay, publish, conflict.
What you will not find here
No dashboard, no content tree, no approval workflow, no per-user permissions. These are not gaps: they are refusals, and the first chapter explains which ones and why. If one of these needs is real in your case, an off-the-shelf CMS will fit better — and saying so early costs less than discovering it in the third month.
The documentation is written to be read in order once, then consulted in pieces. If you are taking over an existing project, How it works, Anatomy of a project and Troubleshooting are enough to get going.