Deploys & rollback

Nothing you build goes live until you say so. A finished ticket gives you a preview and a commit; shipping is a separate, deliberate action. And because the source lives in your GitHub repository, everything that does go live is reversible.

What happens when a ticket finishes

When the build agent finishes a ticket it:

commits the code to your GitHub repository, and
builds a preview you can open, click through, and share.

The agent will not ship unasked. Nothing reaches a public production URL until you say so.

One detail worth knowing: if the app has a backend — a database, file storage, a scheduled trigger — Typillar deploys a preview Worker into your Cloudflare account during the build, so the preview’s /api/_* routes actually work against real infrastructure. The preview Worker is a separate script from the production one, so a build never changes what your customers see; it shares the project’s data, so what you click through is the real thing. A purely static app that has never shipped needs no Worker at all.

An idle preview Worker is deleted after a week and rebuilt on your next build.

What a deploy is

Ship is a project-level action. It takes no ticket: it deploys the project as it now stands — everything built since the last deploy — and publishes it at a live URL. Typillar provisions anything still missing in your Cloudflare account, deploys the built code to the production Worker, and records the deployment.

You ship by pressing Ship, which sits above the preview in the Build tab, or by saying “deploy it” in the thread. The button is disabled until the project has been built at least once — there has to be something to deploy. Build builds; Ship ships.

The deployment is real production infrastructure in your own account — not a preview hosted by Typillar. See What you own. Your plan sets how many products you can have live at once; shipping past that limit returns a payment_required error and offers you the upgrade. See Billing.

The two ways to undo

They are different actions, and the difference matters.

Restore — go back to earlier code

Restore returns the app to an earlier version. Open Build → History, pick a version, and restore it; Typillar re-commits that version forward as a new commit, so nothing in your history is rewritten or lost. The app is back to how it was, and the record of how it got there survives.

Restoring changes the code. It does not, by itself, take anything offline — the live app keeps serving the last version you shipped until you Ship again.

Roll back — take a live deployment offline

Roll back takes a live deployment offline while keeping the deployed script in place. Use it when what’s live is wrong and you want it gone now, ahead of deciding what the code should say instead.

It lives in Overview → Deployments, on the resource itself: each Worker the project runs has its own Roll back. It is per-resource, not one project-wide switch — you take offline exactly what’s wrong.

Rolling back changes what the public can reach. It does not change your code.

Both are one action and neither is destructive, because both are anchored to things you own: the commit history in your GitHub repo, and the deployment history Typillar records for the project.

Taking a project down for good

Two more actions live in a project’s Danger zone:

Archive rolls back every Worker the project runs, so the app stops serving and stops counting against your plan’s live-project allowance. It deletes nothing: the database, the files in its bucket, the code and the build history all stay. Unarchive and Ship, and the app is back with its data intact.
Delete permanently removes the project, its build history, and every Cloudflare resource it provisioned — including its database and every file in its bucket. Your repository is left untouched. This cannot be undone.

Why reversibility matters

Reversibility is what makes shipping fast safe. When any change can be undone in one step, you can move quickly and respond to what’s live, rather than deliberating over every deploy. The loop is built to be fast precisely because it’s built to be reversible.

Production-ready from the first deploy

There’s no separate “go to production” ceremony. The first time a project ships, it ships to production — live, on your domain or a Workers subdomain, with restore and rollback available immediately.

When the live app throws

A deployed app reports its own faults, on both sides of the wire. Every production Worker Typillar ships carries a reporter: when a request ends in an unhandled error, the app records the message, the stack, the route it happened on and nothing else — no request bodies, no headers, no visitor data. A scheduled job that gives up after its last retry is recorded the same way.

Every production page carries a small reporter too. An uncaught error in the browser, an unhandled promise rejection, or a page that loads and renders nothing at all is recorded with the page it happened on. The same restraint applies: the page’s path pattern with ids collapsed — never a query string, never anything typed into the page, never who was looking at it. Each browser reports a given fault once per visit and goes quiet after ten.

Those records go to an Analytics Engine dataset in your own Cloudflare account, alongside the rest of the app’s infrastructure. Typillar reads them back to fill in the Errors card on the project’s home page: what threw, where — a route for the server, a page marked browser for a visitor — how often, and when it last happened, over the last 24 hours. The card isn’t there when nothing has thrown.

Two things worth knowing about what it can and can’t tell you:

It sees throws and blank pages, not wrong ones. A page that renders the wrong thing, a button that does nothing, a layout that breaks — those throw nowhere, so they appear nowhere. Say what you saw instead.
It’s the shipped code. Errors describe the deploy that’s live right now. A fix isn’t reflected until you ship it.

“Fix this” on any error captures it — message, route and stack — as a ticket, so the agent starts from the actual failure rather than your description of it. The agent can also read the list itself when you tell it the live app is broken.

Project history — the full record behind restore.
The build loop — where deploy fits in the loop.