Security & privacy

Atelier is self-hosted. Your source, your container images, your secrets, and the apps you run all live on hardware you control. This page explains what protects them, what Atelier deliberately does not do, and where the limits are. It is meant to be honest in both directions: the protections are real, and so are the caveats.

Nothing phones home

Atelier sends no telemetry, analytics, or usage data to its author or to any third party. There is no tracking, no licence check, and no background reporting.

The only network traffic Atelier makes outbound is what you configure:

pulling container images from registries you point it at,
calling an AI provider, and only if you add a provider key for the optional AI features,
delivering the alert channels and event webhooks you register,
talking to your own Git host for build sources.

Turn none of those on and the platform talks to nothing outside your cluster.

Source code and review

Atelier is proprietary, closed-source software. The source is not published publicly, and the licence does not permit copying, redistribution, or use as AI training data.

Closed source does not mean a black box. Independent review is welcome, and the licence already provides for it: the author can grant source access for authorized review. This is deliberately by invitation and limited in scope, offered to serious evaluators and security researchers on request, under the confidentiality terms of the licence, for inspection and assessment rather than reuse. If you find a security issue, responsible disclosure is appreciated.

Evaluating Atelier and want to look under the hood, or have something to report? Get in touch through Help & community.

How credentials are stored

Atelier treats different kinds of secret differently, according to whether it ever needs to read the value back.

User passwords are hashed with bcrypt and never stored or logged in plaintext. The platform can check a password but cannot recover it.
API tokens are stored only as a SHA-256 hash plus a short, non-secret prefix used for display. The full token is shown to you once, at the moment you create it, and is never written to the database. If you lose it, you mint a new one. Revoked and expired tokens are pruned automatically.
Your apps’ secrets (the environment variables your apps need) are held in Kubernetes Secrets and injected into your app pods as environment variables. The API never returns their values. It shows only the key names, so you can see which secrets are set without exposing them.
Provider keys and webhook secrets (an AI provider key, the HMAC secrets for inbound and outbound webhooks) are stored so the platform can actually use them: call the provider, and sign or verify webhook payloads. These are never returned to the browser. The UI shows only whether a key is set, not its value.

Who can do what

Role-based access control with three roles: Viewer, Developer, and Admin. Read-only users cannot change anything; only Admins manage users, API tokens, platform settings, and the audit log.
An audit log records who did what, when, and from which address. It is visible to Admins only.
The optional build agent runs with a per-user, scoped, expiring session token, not a standing admin credential. A Viewer gets no terminal at all, and the work an agent does is attributed to the human who started it. Disabling the agent revokes its tokens.

Build and supply-chain safety

Every build is a deterministic container build. The platform does not author or inject code into what you ship.
Built images are vulnerability-scanned. Under the Hardened profile, a critical CVE holds the deploy for you to review rather than shipping silently.
A pre-deploy lint gate can hold a risky deploy under the same profile.
Outbound event webhooks are HMAC-SHA256 signed, so your receivers can verify a payload genuinely came from your Atelier instance before acting on it.

The honest limits

Atelier is built for a single owner or a trusted team, on infrastructure you control. With that in mind:

It is not a multi-tenant security boundary. It does not isolate mutually distrusting users from one another. Everyone with access is assumed to be on the same side.
The database is not encrypted at rest. The SQLite database under /data holds the reversible secrets the platform must keep (provider keys, webhook secrets, and, while an app is archived, a snapshot of that app’s secrets). These are protected by the filesystem permissions of the volume, not by encryption. Treat read access to that volume as equivalent to access to those secrets, and restrict it accordingly.
The apps you deploy are yours to secure. Their network exposure, authentication, and firewall rules are your call. Atelier runs your apps; it does not police them.
It is early-access software, provided “as is”, with no warranty. For anything regulated, customer-facing, or revenue-bearing, get your own security and legal review first.

For the full legal position, see the Disclaimer & risks and the Terms of Use.

Your data is yours

You own everything you put into Atelier, and none of it is sent to the author. The flip side of self-hosting is that backups are your responsibility: the SQLite database under /data, your secrets, and any app data volumes are the things to back up if you cannot afford to lose them. Treat the cluster as you would any other dev or staging environment, not as a system of record.