Opsting v0.27.0-beta

Atelier is now Opsting. Same platform, same apps, new name — and a new home at opsting.dev.

This is the rename release, and it is a breaking one. Every identifier the platform uses to find its own workloads has changed: the Kubernetes namespaces, the resource labels, the API token prefix, the environment variables, the config filenames, the image names and the agent skills. There is no in-place upgrade, and that is deliberate — see below.

Coming from v0.26.x or earlier? Do not run upgrade.sh against an existing Atelier install. Rewriting namespaces and labels under a running cluster orphans live workloads silently, with no error to tell you it happened. Stand up a fresh Opsting install and move your apps across instead. The full walkthrough is in Migrating from Atelier to Opsting — your source code and your app data both come over intact.

Why a rebuild rather than an upgrade

Kubernetes finds your running workloads by label selector. Change a label on a live Deployment and the objects that referenced it don’t error — they simply stop matching, and the workload carries on running with nothing managing it. The same is true of namespaces: the platform would come up cleanly, pointed at a namespace that no longer exists, and the only symptom would be a single line in a log.

A fresh install sidesteps all of that. It is slower to read about than an upgrade command, and much safer to actually do — and because you install alongside your existing box rather than over it, the old install keeps serving the whole time and rolling back costs nothing.

What changes

	Atelier	Opsting
Kubernetes namespaces	`atelier`, `atelier-apps`	`opsting`, `opsting-apps`
Resource labels	`atelier.io/*`	`opsting.io/*`
API token prefix	`atl_…`	`ops_…` — existing tokens stop working
Environment variables	`ATELIER_*`	`OPSTING_*`
Config files	`atelier.toml`, `atelier-spec.yaml`	`opsting.toml`, `opsting-spec.yaml`
In-cluster registry	`registry.atelier.local`	`registry.opsting.local`
Installer binary	`atelier-install`	`opsting-install`
Container images	`atelier-core`, `atelier-ui`, …	`opsting-core`, `opsting-ui`, …
Agent skills	`atelier-build`, `atelier-operate`	`opsting-build`, `opsting-operate`
MCP server	`atelier` (`mcp__atelier__*`)	`opsting` (`mcp__opsting__*`)

Three of these need action on your side rather than the platform’s:

Re-mint your API tokens. Old atl_… tokens are not recognised, so anything holding one — an agent, a CI job, a script — needs a new token issuing.
Reinstall the agent skills under their new names. The download URL is unchanged; the skills inside it are now opsting-build and opsting-operate. An agent still carrying the old pair will be reaching for tools that no longer answer.
Update your MCP host config if you have Opsting configured as an MCP server — both the server name and the mcp__… tool prefix have moved.

Rename your spec file before you rebuild

If a repo has an atelier-spec.yaml at its root, the build now stops and tells you to rename it, naming the exact git mv that fixes it.

We considered quietly accepting the old filename. It earns less than it looks like it does: the alternative to stopping isn’t “carry on correctly”, it’s ignoring the file and inferring the app’s shape from its Dockerfiles instead — which can drop a companion database and deploy something subtly different from what the repo declares, while looking entirely healthy. A build that stops is recoverable in one command. A wrong deployment that looks fine is not.

If you are following the migration guide, the rename rides along in the commit you push during re-onboarding, so there is nothing extra to do.

Fixed: restoring a backup could corrupt the database

The platform runs SQLite in WAL mode, which means the real contents of a database live partly in -wal and -shm sidecar files next to it. The restore path swapped the database file into place but left those sidecars behind, so the restored database was opened alongside the previous database’s write-ahead log.

The result was a platform that wouldn’t start, reporting database disk image is malformed, with the portal locked out entirely. The safety copy taken before the restore had the same problem, so rolling back wasn’t dependable either.

Sidecars now move with the database they belong to, on both the restore and the rollback path. This was caught on a test box during migration rehearsals rather than on anything anyone was relying on, but if you have ever restored a backup, this is the release that makes it trustworthy.

Also in this release

The offline upgrade path and upgrade.sh follow the new image and namespace names. An upgrade run against an Opsting install no longer reaches for images that were never published.
The installer’s own help text, the published docs and the agent skill copy have all been brought in line with the new name.

Getting it

Downloads are unchanged in location — only the binary name has moved:

curl -Lo opsting-install https://tryatelier.blob.core.windows.net/tryatelier/latest/opsting-install
chmod +x opsting-install
./opsting-install

On Apple Silicon or another arm64 host, use opsting-install-arm64.

The old latest/atelier-install URL still serves this release’s binary so that existing links land somewhere useful rather than freezing on the last Atelier build. It will not be published again after this release — update your notes to the opsting-install URL above.