Skip to content
Atelier

Atelier v0.20.0

Public Access lands, the licensing structure is cleaned up, and the bring-your-own-code path gets the polish it needed for prime time. Many of the BYOC fixes were driven by an external agent running a real end-to-end session against v0.19 — pushing code, hitting the rough edges, and writing them up in detail. The rough edges are now sanded down.

Coming from v0.19.x? Straight upgrade — one command. Heads up for existing users: the Terms of Use have been restructured (the LICENSE now governs the source code only; a separate Terms of Use document governs running an Atelier instance), and existing users will be prompted to review and accept the new Terms on their next sign-in.

Public Access — your apps, on a hostname you own

Atelier instances are no longer LAN-only. Any app you build can now be reached on the internet at a hostname you own — blog.example.com, internal.example.com, anything that maps to a domain in your Cloudflare account.

How it works. Configure a single Cloudflare Tunnel once in Settings → System → Public Access: paste the tunnel credentials and a Cloudflare API token, and the platform takes it from there. For each app, the new Public Access panel on the App Detail page exposes a toggle and a hostname field. Flip it on, type the hostname you want, save — within a few seconds the route is live: Cloudflare DNS points at the tunnel, the tunnel forwards to the in-cluster Service, and TLS is handled at the Cloudflare edge.

Why it’s clean. Atelier drives the Cloudflare API directly to manage the tunnel ingress config and DNS records. There’s no manual dashboard juggling per app, no per-route YAML to edit on the cluster — toggle on, toggle off, archive an app, and the tunnel and DNS state stay in sync.

What works without it. Apps you build still run on your cluster and are still reachable from the portal (/apps/<name>) regardless. Public Access is an opt-in extra surface for the apps you want on the public internet — typically blogs, demos, internal tools you’d otherwise stand up behind a separate reverse proxy.

SSR / Next.js / Vite apps. These emit root-absolute URLs (/_next/..., href="/about") that don’t round-trip cleanly through the portal’s /apps/<name> proxy. Public Access is the recommended way to reach them — a dedicated hostname serves at root, so the same URLs resolve correctly. The portal proxy works fine for relative-path SPAs (Vite-SPA, plain HTML, single-image admin tools).

A new dedicated-subdomain mode for LAN access (no Cloudflare required) is planned for a future release.

Licensing & Terms of Use — split, clearer, with re-acceptance

Two distinct artifacts now, with different scopes:

  • LICENSE governs the Atelier source code: no redistribution, no public uploads of substantive source, no AI/ML training-set uploads. As before.
  • Terms of Use (new, separate document) governs running an Atelier instance: what you can do with the apps you build, the persistence guarantees, and crucially what you’re free to share publicly — screenshots, blog posts, the apps you build on top.

The new Terms of Use explicitly permit publicly sharing apps you build with Atelier — on social media, in customer-facing products, in demos — and you can sell those apps commercially. The Atelier platform itself is still not yours to host as a service for third parties; the apps you build are. The previous app-signup terms had a confidentiality clause that, taken literally, prevented social-media posts; that’s now gone.

A new §4 Pricing and future versions clause acknowledges that Atelier may introduce paid tiers, license keys, or subscriptions for future versions — with a non-retroactivity carve-out: a version you’ve already installed stays usable under the Terms you accepted at install time.

For existing users: the new Terms carry a version number. The platform now tracks per-user acceptance, and on your next sign-in you’ll be shown the new Terms with a checkbox + I Agree. After that, future Terms revisions will use the same flow — you re-accept before continuing. Programmatic access via atl_ API tokens is unaffected (re-acceptance is a human-interactive concept; agents using API tokens keep working).

Bring-your-own-code polish

A batch of changes that make the scaffold → git push → build flow feel less like “first try” and more like a path you’d ship a real app on:

  • /data writes work out of the box. Generated app deployments now include a fix-data-ownership init container that aligns /data ownership with the running container’s user. Apps using non-root base images (the default for node:*, and most modern stacks) can write to their SQLite database or upload directory without permission errors.
  • The agentic “fix me” loop respects the BYOC contract. When a direct build fails, the platform no longer tries to rewrite your Dockerfile or source. You get a plain error in last_error and the build log explaining what failed — fix it and push a corrected commit. Agentic fix is still available for description-driven apps where it’s expected.
  • The original build log survives. The post-failure diagnostic pass used to wipe the build log and replace it with its own progress chatter. Now it appends, with a labelled separator, so the underlying Docker / BuildKit error stays visible.
  • The + Create dropdown is always open. If no LLM is configured, only the agentic New App entry is greyed; Import Image, Clone Repo, Upload Local, and From Gitea are always available — BYOC users no longer need to configure an LLM they don’t plan to use.
  • The welcome modal stops nagging once you have apps. Previously it popped up on every page load if no LLM was configured. Now it appears only for genuinely first-run users (no apps, no LLM).
  • Public-access tunnel correctly targets the app’s Service port. The tunnel origin URL now reads the actual port the app’s Ingress uses, not a hardcoded :80. Resolves a class of issue where the public URL returned 502 while the portal worked fine.
  • GET /api/apps/{name} returns structured access URLs — portal_url, public_url (when exposed), and in_cluster_url — so consumers don’t have to reconstruct them from convention. The legacy url field is preserved.
  • PATCH /api/apps/{name} no longer silently drops unknown fields. Sending fields that belong to a different endpoint (e.g. trying to toggle public access through the wrong path) now returns 422 with the unknown field named, instead of 200 with the field quietly ignored.
  • current_build_number is set at build start. Failed builds keep their build number, so logs and last_error are correlated to a specific build attempt even when it never completed.

Other improvements

  • Direct-mode builds skip the LLM pre-build review. Build pipeline emits a clear “Pipeline profile” line so the active configuration is visible in the log.
  • A few apps’ dropdowns / panels updated to reflect the changes above — the empty state now offers an “Or import an existing app” affordance when no LLM is configured.

Skills bundle

The atelier-build skill picks up two additions ($0.2.5$):

  • Secrets API body shape is now documented in full — the canonical { "secrets": { "KEY": "value" } } envelope, including the PUT method, the matching DELETE { "keys": [...] } shape, and GET for listing the keys (values are never returned).
  • A known-good Next.js standalone Dockerfile snippet under the direct build requirements section, covering the missing-public/ COPY trap that bites every first Next.js BYOC build. Also flags the portal-proxy / SSR caveat with a pointer at Public Access as the recommended path for SSR / Vite apps.

The skills bundle (latest/skills.tar.gz) is republished automatically on every change, separately from the platform release.

Under the hood

  • The tunnel orchestrator runs cloudflared in token mode and drives ingress + DNS through the Cloudflare API. Faster propagation, cleaner failure modes, no per-app dashboard work.
  • A new audit log action auth.terms_accepted records each user’s Terms-of-Use acceptance with version + timestamp for traceability.

Upgrade

For everyone — one command:

Terminal window
curl -Lo upgrade.sh https://tryatelier.blob.core.windows.net/tryatelier/latest/upgrade.sh
chmod +x upgrade.sh
./upgrade.sh v0.20.0

It rolls atelier-core, atelier-ui, and the MCP server pods. Your running app pods aren’t touched on the upgrade itself — but any app that’s subsequently rebuilt (push, redeploy, or anything that regenerates the manifest) will pick up the new fix-data-ownership init container automatically. Folders, pins, alert channels, public- access configuration, and MCP server deployments carry over unchanged.

The first sign-in after upgrade will prompt you to re-accept the new Terms of Use. Same for every existing user on the instance. The modal blocks navigation until accepted; programmatic access via atl_ tokens is unaffected.

Bug reports and feedback in the testers Discord channel. Thanks for testing.

Need help? Join the Discord or read the help page.

© 2026 Atelier — early access · Disclaimer & risks