From push to live

Sahabti started as a way to get a database without doing the networking. The obvious next question, asked by more or less everyone who used it, was: and where do I put the app?

So: projects. Connect GitHub, import a repository, and Sahabti builds it into a container and serves it over HTTPS at a hostname of its own. Push to the branch you tracked and a new version ships.

git push origin main
# → cloning · detecting · building · deploying · live

That much is table stakes. The parts worth writing about are the ones you only notice when something goes wrong.

Detection you can overrule

The platform reads your repository and works out how to build it — Next.js, Nuxt, Astro, SvelteKit, React Router, Vite, Node, Python, Go, a static site. Detection is a guess, though, and a guess that can't be corrected is a trap. So there are three layers, and the higher one always wins:

1. sahabti.json, committed next to your code
2. the project's Build settings in the dashboard
3. detection

And if you'd rather we didn't guess at all, point the project at your own Dockerfile and we build it verbatim. No generated wrapper, no opinions.

The four seconds that matter

A deploy is easy right up until the moment the new container replaces the old one. Everything we care about lives in that window.

The new image starts alongside the one that's serving, and it has to answer a health check before anything is pointed at it. If it doesn't, the previous version is restored and the deployment is marked failed. Your visitors never meet the broken build.

And once the swap has actually started, cancel stops working — deliberately. We tried it the other way first, and killing a deploy between "old container removed" and "new container running" takes the app down in a way nobody asked for. So the button disappears for that window and the API answers with a plain "this is being deployed; roll back once it's live." A refused action that says why beats a successful one that breaks your site.

Rollback re-ships, it doesn't rebuild

Rolling back to a past deployment doesn't rebuild it from the commit. It re-ships the exact image that deployment shipped, so what goes live is byte-identical to what was serving before — not a fresh build of the same sha, which can differ for a dozen boring reasons a year later.

It also lands as a new deployment at the top of the timeline rather than rewriting the old one. Your history stays a record of what happened, including the rollback.

While you're there

Two other things shipped alongside, both in the same spirit of removing a step between you and the thing you're trying to do:

Database tools. PostgreSQL and MySQL instances now have a table editor, a SQL editor, and a database-users panel in the dashboard. Statements run inside your instance rather than over a connection from your browser — which means a fully private instance, with no public endpoint at all, is still completely usable from the dashboard.

An MCP endpoint. Point Claude, Cursor, or your own agent at https://api.sahabti.com/mcp and it can list your instances, read the provisioning log of the one that failed, run a query, take a backup. It's an adapter over the same routes the dashboard calls, so an agent gets your permissions and your quota, not a second implementation of them — and no tool returns a password, because a tool result is model context and model context travels.

Read the projects docs to get started, or the changelog for the rest of the release.