What is Atelier?

Atelier is an opinionated, self-hosted deployment platform: it takes application code, written by you or by an AI agent you connect, and turns it into a running, monitored web application on infrastructure you own. It is opinionated about the part that should be boring and consistent (build, deploy, route, scan, operate) and deliberately open about who writes the code.

You bring the code; Atelier owns everything after that. It stores the source in your own Git server, builds the container images, generates the Kubernetes plumbing, deploys to a small cluster, gives the app a URL, and then helps you keep it running. There is no SaaS in the middle: the platform, the code, the container images, and the deployed apps all live on your own machine or server.

Atelier deliberately does not write application code itself. Code authoring is what AI coding agents are good at and getting better at every month, so Atelier is built to be driven by them (or by plain git push), and to be excellent at the part they’re missing: the build-deploy-operate lifecycle.

Because everything is driven through one public surface (scoped tokens, portable skills, MCP, and plain git), anything an agent builds is just another app on the platform. Some of those apps are tools in their own right: an MCP server, an internal API, a service your agent then turns around and uses. So Atelier is self-extending. You can ask an agent to build the very thing that makes your agent more capable, and it runs on the same substrate as everything else, with no platform changes required. The capability surface grows from the inside, and the guardrails that keep ordinary deploys safe (scoped tokens, scanning, deploy gating, approvals) are the same ones that keep that growth in check.

What it does

There are three ways to get an app in:

Push your own code — Atelier creates a private Git repository and a build webhook for the app. Push code containing a Dockerfile and every push is built and deployed automatically.
Clone a repository — point Atelier at a public Git URL containing a Dockerfile. It copies the source into your own Git server, builds it, and deploys it.
Import an image — deploy any existing container image with no build at all.

However the code arrives, the same pipeline runs:

Build — container images are built in-cluster with BuildKit and pushed to your own registry. The Kubernetes plumbing — Deployments, Services, ingress routing — is generated by the platform from vetted templates, so routing and wiring mistakes don’t creep in via hand-rolled YAML.
Gate — a pre-deploy lint gate, vulnerability scanning, and optional deploy holds on findings. Pick a fast profile while iterating, a hardened one for anything real.
Operate — once it’s running, Atelier keeps watching. A built-in assistant, Nova, diagnoses crashes and walks you through fixes, and a background supervisor flags problems with the platform and your apps before they bite.

You write a Dockerfile, not Kubernetes. A Dockerfile with an EXPOSE line is the whole contract. Atelier turns it into the full deployment: a Deployment, a Service, an Ingress with portal and LAN host rules, the Traefik middleware, and a /data PersistentVolumeClaim with an ownership init-container. That is around 150 lines of manifests you did not write, and (more to the point) do not have to keep in sync across every app you run. Nothing is hidden: the generated manifests sit on every build record, and your source stays exactly as you pushed it, because Atelier never commits generated files back into your repo.

Why containers

Every app on Atelier is a container, and most real setups end up as a handful of small services rather than one large app. That is not incidental. The container-and-microservice shape is what makes everything else on the platform work, and it is an especially good fit for an environment where apps are built by agents, run on your own hardware, and extend each other.

One uniform contract. Whatever the language or framework, an app is just “a container that listens on a port.” That single contract is what lets Atelier (and any agent driving it) treat a Python API, a Node frontend, and a Go worker identically: same build, same generated manifests, same routing, same scanning. There is no bespoke deploy logic per app, so automation stays simple.
Isolation without conflict. Each container carries its own dependencies and runtime, so two apps that need different versions of the same library never fight. An agent can stand up a dozen services without a global dependency matrix to reason about.
Independent lifecycles. Each service builds, deploys, scales, fails, and rolls back on its own. A crash in one app does not take the others down, and Atelier operates each one separately, with its own logs, metrics, redeploys, and crash diagnosis.
Composability is what makes self-extension work. When a new capability is a new container rather than a change to a monolith, your agent extends the system by deploying another small service: an MCP server here, an internal API there, each reachable over the cluster network. The architecture is additive, so the platform grows by accretion instead of rewrites.
The image is the unit of trust. Because the artifact is a container image, there is one clear thing to scan for vulnerabilities, gate on, version, and roll back to. Provenance and blast radius are well defined, which matters when some of those images were authored by an agent.
Light enough for your own box. Containers share the host kernel, so a small k3s cluster or homelab can run many services at once where virtual machines would be far too heavy. Self-hosting a fleet of small apps is actually practical.

In short, containers give Atelier a model that is uniform enough to automate, isolated enough to stay safe, and composable enough to extend itself.

Why use it

It’s yours. Atelier runs on your own hardware or VM. The source, the container images, and the running apps stay on your infrastructure — not on someone else’s servers.
Agent-ready by design. The fastest path is the built-in Build with AI terminal: enable a bundled agent in your cluster — Claude Code or opencode, your pick — and describe the app you want; it writes and ships the code with no local setup. Prefer your own? Connect any AI agent — Claude Code, Cursor, a chat assistant like Hermes — with a single scoped, revocable API token. Either way, Portable Agent Skills teach any skill-aware agent to drive the platform end-to-end: scaffold an app, push code, watch the build, read logs, manage secrets. The agent authors the code; Atelier builds, deploys, and operates it. The loop runs both ways: Atelier pushes signed event webhooks (builds, crashes, CVE holds) back out, so an agent or monitor can react to what the platform does instead of polling for it.
No AI required. The whole platform works with no LLM configured at all. Push code, clone repos, import images, operate apps — none of it needs a model. AI features (the Nova assistant, background code review, build summaries) light up when you add a provider key.
Bring your own AI provider. When you do want the AI features, you supply your own API keys (Anthropic, OpenAI, or a local model) and pay the provider directly — no markup, no per-seat fee.
A pipeline you control. Every build can lint the source and scan the image for known vulnerabilities — then hold the deploy on findings, depending on the profile.
No lock-in. The output is ordinary code in your Git server and ordinary container images in your registry. You can take them and leave at any time.

Where it fits

Atelier is a good fit when you want to:

Give an AI agent somewhere real to deploy — your agent writes the code; Atelier gives it a cluster, a pipeline, and an operations surface it can drive through skills and a scoped token.
Stand up internal tools — dashboards, small line-of-business apps, utility services — without building deployment infrastructure for each one.
Build on a homelab — run real apps on your own cluster for personal projects and learning.
Keep code and data in-house — when compliance, IP, or privacy means the work can’t go to a hosted service.

It is not an AI coding assistant, and it doesn’t try to be. Atelier’s focus is the platform: taking working code from you or your agent to deployed-and-operated, on hardware you own.

Atelier is opinionated on purpose, so it’s worth being honest about where it doesn’t fit:

Reach for raw Kubernetes (kubectl, Helm, Kustomize) if you need total control or unusual infrastructure such as StatefulSets, a service mesh, GPUs, or custom operators. Atelier won’t model everything, and where it doesn’t, its conventions will get in your way.
Reach for a managed hosted PaaS if you want maximum polish and a support SLA, and you’re happy running on someone else’s infrastructure.
Reach for Atelier if you want to run normal web apps on your own cluster, driven by an agent, without hand-writing and maintaining YAML. That’s the shape it’s built for, and on the agent-driven, self-owned axis there isn’t really anything else like it.

Ready to try it?

Atelier is early-access (beta) software: free to use, proprietary, and young, with active development. It’s sharpest at the shape above; if you’re putting business-critical workloads on it, weigh its age honestly against a mature commercial platform. The encouraging part is the trajectory, where friction tends to get filed and fixed rather than accumulated.

Head to Install Atelier to get a cluster running, then Using Atelier for a walkthrough of deploying your first app.