Deploy from the dashboard

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, 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 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). Comments puts a moderated thread under any page (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 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 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 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.