Atelier v0.26.0-beta

This release is about getting real apps running faster. There’s now a catalogue you can install ready-made apps from in one click — and apps can finally bring a database along with them, declared in a single file, so the common “app plus Postgres” shape just works. Underneath, a broad round of performance and reliability polish.

Coming from v0.25.x? Straight upgrade — one command, and everything here is additive. Your apps, folders, pins, secrets, alert channels, public-access config, and webhooks carry over untouched. Nothing you already run changes.

Install an app from the catalogue

The + Create menu has a new entry: Browse the Catalogue. It’s a curated list of apps that are known to work on Atelier — pick one, click Install, and the platform does the rest, streaming the build and deploy in the same progress view every other creation path uses.

If an app needs configuration — an API key, say — a short form appears first. Required fields are marked, secrets are masked as you type, and whatever you enter is written to the app’s configuration before the first deploy, so an app that needs a key comes up working straight away instead of crash-looping until you set one. Secret values are stored in the app’s Kubernetes Secret — never in a manifest, in the database, or in the build logs.

Each entry is tagged with how it installs: source apps are cloned and built, so afterwards you own the code and can push changes; image apps run a published container as-is, which is the route for large or third-party software that’s far too big to clone.

The catalogue ships with two apps to start: FlowCal, a visual node-editor and calculator (which brings its own database — see below), and OpenClaw, a self-hosted personal AI assistant.

Apps that ship with a database

Until now, Atelier worked out an app’s shape from its Dockerfiles — which can say “build this”, but not “…and also run a Postgres alongside it”. So an app that needed a database meant standing up a second app by hand and wiring the two together.

Now an app can declare its whole shape in one file at the root of its repo, atelier-spec.yaml — the services it’s made of, which are built from a Dockerfile and which run a stock image like postgres:16-alpine, the storage each one needs, and the environment it expects. It’s entirely optional: an app without one is inferred from its Dockerfiles exactly as before.

The details that make it painless:

Services find each other automatically. Your app reaches its database at a predictable in-cluster address, and because the address is derived from the app’s name, the same repo works whatever you install it as.
Passwords you never have to invent. A database password or a session-signing key can be marked to generate on first deploy — Atelier mints a strong random value, stores it as a secret, and neither you nor anyone else ever has to type or read it. Values Atelier can’t invent, like a third-party API key, are prompted for on the Secrets tab instead.
Pushing code doesn’t disturb the database. A git push rebuilds and rolls only the parts of the app Atelier built — a bundled database keeps running, its data untouched.
The database gets proper storage at the engine’s own data path, on its own volume — not shared with the app.

FlowCal in the catalogue is the first app to use this: install it, and it comes up complete with its own Postgres, ready to sign in to.

If you already run a separate database app, note that a bundled service takes a name derived from its app — so an app called myapp with a db service claims the name myapp-db. If an app of that name already exists, Atelier refuses the install rather than overwrite it; install under a different name.

Smaller improvements

Recover a stuck MCP server without deleting it. An MCP server that lands in an error state now has a Redeploy button — one click re-applies it, instead of removing and re-adding it and re-entering its configuration.
Large build logs download cleanly. Fetching the full log of a big build now streams rather than buffering the whole thing at once, so it stays responsive however long the build ran.
--dry-run works on every install path. The installer’s preview mode could trip over its own multi-part manifests on some setups; it now validates them the same way a real install applies them.

Under the hood

A wide round of performance and reliability work that you won’t see directly but will feel: faster app and build-history queries, lighter database writes, tighter and more consistent permission checks across the API, and a good deal of internal tidying that makes the platform easier to keep solid. Every source commit in the history is now also scanned for accidentally-committed secrets, as a standing safeguard.