# Deploy from the dashboard

Drop your site's folder in the browser to put it online — no install, and nothing is uploaded until you say so.

There is nothing to install. Sign in, open a site, and on the **Overview** tab
drop the folder that contains your `index.html` onto the **Deploy from your
browser** panel — or press **…or choose a folder** if you would rather not drag.
If you exported your site from an AI tool, that folder is the unzipped download.

> **The most common mistake: a folder inside a folder.** Unzipping a download
> often gives you a folder that holds *another* folder, and the site is in the
> inner one. Before you drop, open the folder and look: `index.html` should be
> right there at the top level. If all you see is a single folder, open it and
> drop that one instead. In the review, the same check applies — `index.html`
> should be at the top of the file list, not inside a folder.

*Dropping the folder does not upload anything.* Your browser reads the folder
and shows you what would change. Nothing is sent until you press **Upload and
stage**, so dropping the wrong folder costs a moment and leaves nothing behind —
close the review, press **Discard**, and drop the right one.

When you do upload, only the files we don't already have are sent. The result
is a *staged* release: a new version waiting at its own [preview
address](/docs/releases), while your live site stays exactly as it was. A green
box under the drop zone shows that address — open it to check the new version —
and a **Make v1 live** button (the number is the new version's) that publishes
it. On a site that is already live you confirm once more, since visitors will
see the change straight away. The **Releases** tab has the same button for every
version, which is also how you switch back to an older one.

> **A browser upload never goes live on its own.** It always waits for you, and
> publishing is a separate click — so nothing you do here can take a site down.
> That is the one deliberate difference from the CLI, which can collapse both
> steps with `--deploy`.

Something not right? [Troubleshooting](/docs/troubleshooting) is organised by
what you saw.

## Widgets

The **Widgets** tab lists the site's widgets, each with a switch and its own
page. **Forms** gives the site a place to send contact-form submissions, with
no backend to run — every plan includes a Forms plan: define a form, paste the
HTML it generates, and submissions appear in the dashboard ([Widgets](/docs/widgets)).
**Comments** puts a moderated thread under any page
([Comments](/docs/comments)).

## It is the same release either way

Everything after the upload is identical to a CLI deploy: the same releases, the
same preview URLs, the same rollback. You can stage from the dashboard and
publish from the CLI, or the other way round — they are one history, not two.

Which means the dashboard is a reasonable place to *finish* a deploy that CI
started. A [GitHub Actions](/docs/github-actions) run stages a release on every
pull request; publishing it is a click here, or a merge, or a CLI command,
whichever suits the moment.

## When the browser is the wrong tool

Both ways in are plain web platform: the drop reads the dragged directory out of
the drag event, and the **choose a folder** button is a directory-mode file
input. If a drop can't be read for any reason, the panel says so and points you
at the button — try that before assuming the folder is the problem.

For a build of many thousands of files, the [CLI](/docs/cli) is noticeably
quicker: it hashes with the machine's full parallelism rather than one tab's.

## Details

If you use a framework, the folder that contains `index.html` is its build
output — usually `dist/` or `build/`. [Frameworks](/docs/frameworks) lists the
folder for each one. Dropping the project root instead of `dist/` is the
developer version of the folder-inside-a-folder mistake.

The drop hashes every file locally, in the tab, and compares those hashes with
what the site already serves; that is how the review knows what changed before
anything is sent. The files that are missing go straight to storage rather than
through the dashboard.

Dotfiles like `.git` and `.env` are left out of the release.