> For the complete documentation index, see [llms.txt](https://docs.riff.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.riff.ai/interactive-guides/how-to-deploy-an-application.md).

# How to deploy an application

{% @riff-academy/riff-academy-guide url="<https://databutton.github.io/riff-academy/deploy.html?section=what-this-shows>" %}

### Deploying your app: the five checks

#### What deploying changes

Deploying gives your app a web address and lets your team in. One button does it. The work is what has to be true before you press it.

While the app is only yours, you know every screen, you know which states are unfinished, and you work around anything rough without thinking about it. The moment a colleague opens it, none of that knowledge travels with the link. They see the app; they do not see what you know about it.

Two things have to be true before that happens.

**It has to be safe to deploy.** Your applications sit in a workspace dedicated to your company. You sign into it the same way you sign into any other tool at your company— the same single sign-on — and the workspace is locked down by group security, so anyone inside the company can open a deployed app and anyone outside cannot. This part is arranged with your IT before you get there.

**It has to be safe to use.** The person opening it knows what the tool is for and what to do, nothing sends them down a path you never pictured, and if something does not look right they know who to contact and how to report it. This part is yours, and it is what the five checks below are.

#### How the checks run

Each check is a skill: a set of instructions written once, so the same check runs the same way on every app. You do not write them and you do not need to read them.

Type a slash in the message box and the list opens. Type `/deployment` and it narrows to these. Clicking one sends it — there is nothing else to fill in. The agent runs the check, does the work, and tells you where to look.

What a skill cannot do is decide whether what it found matters. That stays with you, and it is called out in the sections where it applies.

***

### 1 · Someone owns it, and users can get help

* A contact card in the app: who built it, how to reach them
* A documentation page with guides and a glossary
* A bug report form, and an admin page where the reports land

Support is set up before launch on purpose. After launch is when it is needed, and by then it is too late to add.

| Skill                                        | What it does                                                                                                   |
| -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `/deployment-add-contact-info`               | Adds a contact and maintainer card to the app, so a user can see who built it and how to reach them.           |
| `/deployment-implement-in-app-documentation` | Adds a documentation page inside the app, with sidebar navigation, workflow guides and a glossary.             |
| `/deployment-implement-bug-reporting`        | Adds a bug reporting system: users submit reports from the app, and you view and manage them on an admin page. |

***

### 2 · It works for people who are not you

* A pass over every route a user can take through the app
* The empty, error and loading screens you never see yourself
* Held together on a phone, not only on the machine you built it on

You stopped seeing most of this while you were building. The check is run rather than remembered because judging your own build is the hardest kind of judging.

| Skill                             | What it does                                                                                                                                                                               |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `/deployment-implement-ux-checks` | Runs a full user-experience check against established UX principles, covering broken flows and the empty, error and loading states a user hits when they do something you did not picture. |

***

### 3 · You know what it connects to, and what data moves

* Every connected system written down in one place
* What is read, what is written, what is stored
* Then your call: is that what you intended, and is personal data in there that need not be

The skill produces the map. The two questions at the end of it are yours — a check can tell you that data is moving, but not whether it should be.

| Skill                           | What it does                                                                                                                            |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `/deployment-check-integration` | Runs through every integration in the app and documents it: what it connects to, and what data is read, written, stored or transformed. |

***

### 4 · You know what happens if someone deletes something

* Audit logs and version history on data people can edit
* Point-in-time restore, so there is a way back
* Not every app needs this. That call is yours

The question this answers is what happens if something is wrong. If users can edit or delete records that matter, the app needs a way back. If they cannot, it does not.

| Skill                                     | What it does                                                                                      |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------- |
| `/deployment-add-audit-trail-and-restore` | Adds audit logs, version history and point-in-time restore for business data that users can edit. |

***

### 5 · Nothing is reachable that should not be

* Every page and route marked as protected or open to anyone
* A pass over the code for critical flaws
* A deeper audit for anything the first pass did not catch

The first part of this needs no security knowledge. Walk your key pages and API routes and read the protection status on each one: protected, or open to anyone. Anything open that should not be is a finding you can act on immediately.

| Skill                                | What it does                                                                                            |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------- |
| `/deployment-check-security`         | Runs through the codebase to identify critical security flaws and anything that would block deployment. |
| `/deployment-perform-security-audit` | Runs a systematic security review for vulnerabilities, going deeper than the deployment check.          |

***

### Where the decision sits

The full list of deployment skills is fixed and it is the same for every app. What changes is what each one finds, and what you decide to do about it.

Repeatable work goes to the skill. The judgement stays with you: whether a role sees the right thing, whether the data moving is data that should be moving, whether a finding is worth acting on, and whether this is ready to ship.

Once the checks are done you press deploy, and it goes to an approver inside your workspace before it goes live. You decide who that approver is. If you are happy to deploy directly, that is you. If you would rather one person looks over anything before it reaches the company, you assign them and every deployment goes past them first.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.riff.ai/interactive-guides/how-to-deploy-an-application.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
