---
title: Delivery and deployment
description: What happens to a finished candidate — keep it, commit it, push a branch or open a pull request — and how going live on your hosting works as its own authorised step.
---

A finished session doesn't change your repository. **Delivery** — getting the
candidate into your repository — and **deployment** — putting it live — are
separate steps, each with its own permission.

## Four states that never blur

A session's summary keeps four questions apart:

| Question | Possible answers |
|---|---|
| Is Ysra still working? | Working, repairing, waiting to continue, finished. |
| Is there a candidate? | Yes — with its version — or not yet. |
| Is it verified? | Verified, completed, unverified, failed. |
| Has it been delivered? | Not yet, delivering, delivered, delivery failed. |

A session can be repairing while an earlier candidate is still available; a
verified candidate can be undelivered; a delivered one keeps its review history.

## Delivery options

| Option | What happens |
|---|---|
| **Keep only** | The candidate stays in Ysra. You deliver it when you choose. The default. |
| **Local commit** | For work on a local checkout: a commit in your working copy. |
| **Push branch** | The candidate is pushed as a new branch. |
| **Draft pull request** | A branch plus a draft pull request, linked to the session's report. It is never merged automatically. |

Which of these happens automatically is set by your
[autonomy policy](../workspace/autonomy-policy.md):

- **Delivery** — what happens to a candidate whose required checks passed.
- **Unverified delivery** — what may happen to one whose checks didn't all pass:
  keep only, or a draft pull request clearly marked as unverified.

When your policy doesn't deliver automatically, deliver by hand:

- **Portal** — **Open PR** in the workroom.
- **Phone** — **Open PR** in the output bar. Once opened it becomes **PR #n**.

<div class="phones" markdown>

![A finished mobile session with the output bar: Preview, Open PR, Changes and Report, and the hint "Send deploy to put this candidate live"](../assets/screens/mobile/conversation-done.webp){ width="585" height="1266" }
/// caption
The output bar: Preview, Open PR, Changes, Report.
///

</div>

### What delivery checks

Before anything is pushed, the candidate is rebuilt from its checkpoint, checked
against its recorded version, and scanned for secrets. Delivery permission is
kept apart from the coding work: a repair step can never grant itself the right
to publish.

## Deploying

**Deploy** puts a candidate live on hosting you have connected. It is its own
flow, never an automatic last step of a coding session:

1. **Choose the candidate.** Deployment names the exact version it will publish,
   and whether it is verified or not. Advisory findings stay visible.
2. **Choose the target** — a preview environment or production.
3. **Review the plan.** Ysra works out what the app needs — services, databases,
   environment settings — and shows the plan before creating anything.
4. **Deploy.** Resources are created in order, the result is smoke-tested, and a
   domain can be attached as a separately authorised step.
5. **If something fails,** the deployment can be repaired or rolled back.
   Resources Ysra didn't create are never touched.

Deploying is blocked while a coding task is still running. A failed deployment
doesn't rewrite the session's verdict — it gets its own record and its own
repair.

On the phone, sending *deploy* in a finished conversation starts the same flow.

!!! note "Hosting connections"
    Deployments use hosting providers you connect in
    [Account settings](../workspace/settings.md). Credentials stay with the
    platform; they never reach the model or the workspace.