Skip to main content
Review a working preview before a production release. Building, checking and publishing are separate stages, and production deployment requires your approval.

Publish a web app and open the live result

​
Preview

Use Preview to try the working app before publishing it. Confirm which environment, data and integrations it uses. A preview is not automatically a copy of production data or proof that external actions are harmless. Use it the way a customer would. Then either ask for a revision, or publish.

​
Publish

Publishing is the moment the app becomes public.
Your app lives at a stable address that doesn’t change between deploys — safe to hand to customers, put on a card, or point a domain at. Publishing again updates what’s behind that same address.
An agent requesting a production deploy must receive your approval. Pressing the desktop’s production-deploy button can provide consent for that specific operation. Inspect the destination before approving.

​
Before “done”: verify

workser verify runs the available project checks, such as typecheck, lint and build. Inspect which checks actually ran, and test the important customer flows in the preview. A green result is evidence of those checks, not a guarantee that every requirement works.
If it comes back "ok": false, the errors it lists are what has to be fixed before the change is worth previewing.

Watch the Web Engineer check an app in the browser

​
When something goes wrong

​
Checkpoints: the undo button

Workser Code keeps its own history of your project folder, separate from the deploy history.
Restoring never discards anything. The current state is saved first, then the older state is restored on top. If you restore the wrong thing, restore again. That’s what makes it safe to say yes to.
These are the same source checkpoints used by Workser Code’s Undo flow. Restoring files does not roll back a production database, reverse an external action or publish the restored version. Check the affected services, then review and approve a new deployment if required.
Your project folder is a git repository, but the history lives with Workser and there is no remote. Code moves to and from Workser over its API as git bundles, using the same session everything else uses — no credential is read, and your own git keys and identity are never touched.That’s what makes this work on a machine that has no access to the Workser-managed repository, which is every machine.So the usual git verbs are replaced:Reading is always fine — git log, git diff, git show, git status.git stash is the one that actually loses work. Workser publishes what’s on disk, so a deploy while changes are stashed ships the version without them; and if a run stops between stash and stash pop, you open your folder and your work is gone. workser checkpoint has neither failure mode.
They’re different jobs. workser sync reconciles the folder with Workser; workser deploy puts it in front of users. Syncing doesn’t deploy, and deploying doesn’t require syncing first — a deploy publishes what’s on disk.sync pulls before it pushes. If it reports diverged, both sides changed and it stops rather than picking a winner — resolve it in Workser Code rather than forcing it.

​
Deliverables

When your agent finishes something you should actually receive — a published app, a report, a folder of exports — it registers it as a deliverable on the task, so it appears in Workser Code rather than being buried in a transcript.
Without this, Workser Code has to guess from file edits — and scratch files end up sitting next to the real output.

​
Next

The project workspace

Board, docs, decisions and memory — how the project survives past this conversation.

Security & approvals

What pauses for your approval, and what your agent can never do at all.