Sovereignty & Compliance

lunos.tech runs on self-hosted EU infrastructure — the same sovereignty guarantee the project ships to its users.

Infrastructure we control

lunos.tech and api.lunos.tech run as two independently deployable sites on infrastructure Lunos actually controls — not US cloud infrastructure. That's a deliberate architecture decision, not an afterthought — the project's own site is a live, checkable demonstration of the sovereignty pitch it makes to its users.

Security posture

Both sites are HTTPS-only. The API's CORS policy is locked down to the site's own origin rather than left wide-open, and every request goes through standard input validation before it's persisted. There's no reverse proxy merging the two origins together — the marketing site and the API stay independently deployable and independently auditable.

What we don't collect

This site has no user accounts, no login, and no personalization. Lunos accounts live at app.lunos.tech, a separate app; this site only links to it. The only data the site captures is what a visitor explicitly submits through the contact form — an email address and a short note about what they're evaluating Lunos for.

Who this is for

This matters most to EU public-sector integrators and GovTech/civic-tech developers, and to EU regulated-enterprise engineering teams for whom US-hosted developer tooling is a procurement blocker. If sovereignty is a requirement in your own evaluation criteria, this page is meant to be checked, not taken on faith.

For reviewers

What this gives your compliance team

Lunos does not certify your deployment, and no one can: whether a given installation meets a given obligation depends on how you run it, what you connect it to, and what you do with the output. What the architecture can do is put those decisions in your hands rather than a vendor's — which is usually the part a compliance review has the hardest time establishing about a hosted tool.

Where data goes is your decision

Self-hosted means prompts, source code, and model traffic go where you configure them to go. No project data reaches anything Lunos operates, and there is no telemetry to negotiate away. The CLI's own background calls (a once-a-day update check against your npm registry, the model catalogue, and the marketplace catalogue from lunos.tech when you use marketplace commands) send no project data, and session sharing is off by default. From v1.18.41, LUNOS_OFFLINE=1 turns off every call Lunos makes on its own behalf, leaving only the endpoints you configured.

You can read what it does

The source is available and the deployment is yours, so a reviewer can inspect the behaviour directly rather than relying on a vendor's description. This site's own posture — HTTPS-only, CORS restricted to its own origin, no analytics, no third-party scripts — is meant to be verified the same way.

Two ways to run it

Self-hosted, or with a Lunos account

Self-hosted Lunos (no account)

Nothing changes: no project data reaches anything Lunos operates, and LUNOS_OFFLINE=1 turns off every call Lunos makes on its own behalf.

With a Lunos account

When you sign in (lunos login), each completed turn of a session syncs to your Lunos space on cloud.lunos.tech, run by ITService EOOD in its EU data centre in Bulgaria. Before anything leaves your machine, the contents of .env*, auth.json, *.pem, *.key, id_rsa* and any files you list in sync.exclude are replaced with a placeholder in tool calls, attachments and diffs. A second, best-effort pass masks credential-shaped strings elsewhere; it doesn't catch everything, such as a shell command like cat .env and its output.

Sync stops if your organisation's policy locks it off, if you run lunos sync off, if a folder sets "sync": false, or if your residency policy refuses the destination. It never runs signed out or under LUNOS_OFFLINE=1. Delete a session or your synced data, or export everything as JSON, at app.lunos.tech.

Honestly

What has not been done

The items below are real gaps, listed because a reviewer will find them anyway and would rather find them here.

Planned A formal assessment against the EU AI Act, including the provider/deployer classification that determines which obligations apply, has not been completed. Until it is, treat any AI Act question about Lunos as unanswered rather than as answered favourably.
Planned A published GDPR data-processing record and a data-processing agreement for the contact form. Today the honest description is the one above: an email address and a short note, stored on infrastructure the project controls, with no onward sharing.
Planned Independent certification or audit of any kind. None has been carried out, and this page will say so until one has.
Planned A data-protection review of synced sessions. Counsel has not yet assessed the controller and processor roles for sessions you sync with a Lunos account; the GDPR note covers self-hosted use without sign-in.

Now shipped in the agent

Data-residency controls and an egress audit log, from v1.18.39. A policy such as "residency": { "allow": ["eu"] } blocks any model provider outside the allowed jurisdictions before a request is made, and logs the destination of every outbound call, never its content. That controls which provider may be used and records what left; it is not EU-operated infrastructure, and it does not make any deployment compliant on its own. Releases before v1.18.39 did not enforce it for sessions, and up to v1.18.40 a provider pointed at another host with baseURL could pass an EU-only policy; from v1.18.41 an EU claim holds only for the provider's own API hosts. See the parity table.

If your evaluation needs a specific document — a DPA, a subprocessor list, a security questionnaire — ask. You will get either the document or a straight answer that it does not exist yet.