Access
Two logins before the admin
On Google Cloud the admin and the MCP endpoint sit behind Identity-Aware Proxy. Only allowlisted accounts get through. Caelo's own login is the second line, not the only one.
Security
Visitors only ever see finished HTML.
Caelo keeps the place where your site is built away from the place where it is read. This page shows how that works, what protects the admin, and where the limits are today.
Two worlds
Your site and your admin never share a server.
The public site is a folder of static files on a CDN. Everything that can change it sits somewhere else, behind a login. There is no admin path on your domain to probe.
Public
What visitors reach
Static pagesHTML, CSS and images from a CDN. No server code runs when a page loads.
A narrow gatewayOnly the public actions plugins expose, such as a form or a comment, with captcha, honeypot and rate limits.
A small live databaseHolds what visitors send and what the public side needs to answer them, such as form entries, sessions and approved comments. The gateway connects only here. It has no login to your content database and refuses to start if offered one.
Private, behind login
Where your site is built
Editor and AIOn their own address. On Google Cloud also behind Identity-Aware Proxy, so a request needs Google's login before it reaches Caelo.
Your content databasePages, modules, history, users. On a private network address, with row-level security on every table.
The generatorTurns the content into the static site you publish.
A comment shows the idea. It waits in the small live database until someone reviews it behind the login. Once approved, it is written into the page at the next build. Data moves one way: the admin publishes what the public side needs, and the public side cannot reach your content.
Layers
More than one lock on every door.
No single control carries the whole load. If one layer fails, the next one still stands.
Data
Two databases, locked rows
Editing data and visitor data live in separate databases with separate roles. The public gateway has no login to the editing database at all. Row-level security is enforced on every table, for owners too. Content changes go through named, validated operations, each one audited.
Approvals
The AI asks before it acts
About 50 actions always wait for a human click: users and roles, domains, themes, layouts, plugins, site-wide rollbacks. The person who approves needs the same permission the action requires. Every AI action is written to the audit log.
Plugins
AI-written plugins in a sandbox
A plugin the AI writes runs in a Deno sandbox without access to files, network or environment. The owner grants each extra right for one exact version, and a new version asks again.
Supply chain
Signed releases
Container images are signed. The installer and every upgrade check the signature before anything runs, take a backup first and roll back if the new version fails its health check.
Code
Reviewed on every change
Every pull request runs CodeQL static analysis, a dependency review with a licence allow-list, and secret scanning with push protection.
Limits
What Caelo does not do for you yet.
Security claims are only useful if they say where they stop. These are the boundaries today.
Shipped pluginsThe seven plugins that come with Caelo run inside the admin process with fixed rights. They are reviewed and signed with each release. The sandbox covers plugins the AI writes.
Pre-1.0Interfaces still change between releases. Read the changelog before you upgrade.
DefaultsA new install starts small: database high availability is off to keep costs down. Switch it on before you rely on the site for production traffic.
Your serverA self-hosted install has no identity proxy in front of the admin; Caelo's login is the only one. You also run the server, the firewall and the operating system updates.
Found something?
Tell us privately. We answer within 72 hours.
Report vulnerabilities through GitHub's private reporting or by email. Nothing is made public before a fix is out.