Publishing Your Site
The Publish button and its menu: publish changes, deploy, manage domains and environment variables, check the site before launch, and go back to earlier versions.
Publishing Your Site
Everything about getting your work live is in one place: the Publish button at the top right of the editor, and the ▾ menu next to it.
Your project lives in a GitHub repository. Edits save on their own in your workspace (a Codespace or your local Docker container), but the live site is built from GitHub. Publishing saves your changes to GitHub, and your hosting provider (Vercel or Cloudflare Workers) builds the site from there.
The Publish Button
The button shows how many changes haven't been published yet. Hover over it to see them in plain words, for example the page or component that changed and what changed in it. With nothing to publish, the tooltip says Everything is published.
Click Publish to open the Publish changes dialog:
- What's going live describes each changed page, component or file in Builder terms ("Hero heading: text changed", "New component: RecipeCard"), marked New, Changed or Deleted. Long lists scroll.
- Show code changes opens the same changes as a code diff.
- Files expands the list of changed file paths.
- Summary is the message saved with your changes. It's filled in from what changed; edit it if you like.
Click Publish in the dialog. Your changes are saved to GitHub and the site starts updating. When a deploy you started finishes, a card shows the live address with Open site and Copy link.
Drafts
If you're working on a draft branch instead of your production branch, the button reads Save draft. The dialog says the work is saved as a draft on that branch and that your live site won't change. See Drafts and branches for how to publish a draft.
The Publish Menu
Click ▾ next to the button. The menu has two parts: Live site and Changes.
Live site
The top line shows the state of the last deploy: Live with how long ago, Building…, Deploying…, Last deploy failed, Last deploy canceled or Not deployed yet. Open opens the live site.
If no hosting provider is connected yet, the menu offers Set up deployment (connect Vercel) and Use Cloudflare instead. See Deploying to Vercel and Deploying to Cloudflare Workers.
Once a provider is connected:
| Item | What it does |
|---|---|
| Deploy now | Starts a new deploy from what's on GitHub. Reads Deploy for the first time before the first deploy. With both Vercel and Cloudflare connected and no deploy yet, you pick Deploy to Vercel or Deploy to Cloudflare Workers |
| Stop tracking this deploy | Shown while a deploy is building, instead of Deploy now |
| Domains | Add a custom domain, see its DNS records with Show DNS, and check whether it's verified |
| Deploy history | Past deploys with their status and commit message. Rollback on an earlier, successful deploy makes it the live one again |
| Environment variables | The site's environment variables on Vercel (not shown for Cloudflare deployments) |
| Deploy hook | A URL that redeploys the site when something opens it. Shown after the first deploy. See Deploy Hooks |
| Go-live check | Checks the whole site before launch (see below) |
Deploy checks for changes that aren't on GitHub
Deploys build what's on GitHub. If you click Deploy now while some changes are still only in your workspace (not committed, or committed but not pushed), the editor tells you: Some changes aren't on GitHub yet. Choose Commit & push first; the deploy starts right after the push. Cancel stops without deploying.
Go-live check
Go-live check opens each page the way visitors, Google and link previews see it, and checks that:
- every page loads and has a title, and the titles are all different
- every page has its own description
- links show a preview image when shared
- each page has one main heading
- images have alt text
- no page is hidden from Google
- pages say which language they're in
- no placeholder text is left
- links go to pages that exist
- the site's address is set, and the site has a favicon, a robots.txt and a "page not found" page
Each problem lists the pages it affects; click a page to open its file. Fix with AI hands the problem to the AI assistant. Use the refresh button to check again after fixing. Template pages such as src/pages/blog/[slug].astro aren't checked.
Changes
| Item | What it does |
|---|---|
| View changes | Shows what changed since the last publish, file by file, as a diff |
| Commit & push | Saves to GitHub with your own commit message. Code mode only |
| History | Every published change: what, when and who. Restore on an entry brings the whole project back to that point |
| Undo last publish | Rolls back the most recent commit |
| Versions | Save the project as it is now, and go back to it later |
| Drafts & branches | Work on a draft without changing the live site |
| Get the latest from GitHub | Replaces your workspace copy with the current branch on GitHub |
Commit & Push
In Code mode, Commit & push opens a dialog with the list of changed files (each marked M, A, U, D or R) and a Commit Message field. It does the same thing as Publish, with Git wording and your own message. On your production branch, pushing updates the live site like Publish does.
Going Back: History, Undo and Versions
None of these erase anything. A restore saves a new commit that matches the version you picked, so you can undo the restore later. Before it runs, a confirmation shows which files will change. If you have changes that aren't committed yet, it warns you and the button becomes Discard changes & restore; commit first if you want to keep them.
After a restore, the rolled-back files are pushed to GitHub. On your production branch that updates the live site.
- History lists commits with their author and date. Click Restore to go back to one.
- Undo last publish rolls back only the most recent commit.
- Versions are named bookmarks. Type a name (for example "Before homepage redesign") and click Save; the version is backed up to GitHub. Later, click Restore next to it, or the trash icon to delete it. Versions belong to the branch you saved them on.
Versions also lists Automatic recovery copies. The conflict resolver makes one before it changes anything, and they're never deleted automatically. See Publishing Changes and Resolving Conflicts.
To bring back an earlier version of the live site without changing your code, use Deploy history › Rollback instead. It switches which deploy is live.
Drafts and Branches
Drafts & branches opens the branch picker. While you're on a draft, or when the project has more than one branch, the branch name also shows in the header; click it to open the same picker. It shows your production branch (the one your live site is built from) and your drafts. Each draft says how many changes are waiting to publish and whether production has updates the draft doesn't have yet.
- Click a draft to switch to it.
- New branch creates a draft from the branch you're on; type a name and click Create & switch.
- The trash icon next to a branch deletes it without merging.
While you're on a draft, Publish saves to the draft and the live site stays as it is. To put a draft live, click Publish to production in the branch picker, or the amber rocket button next to the branch name in the header. It brings the draft into your production branch and updates the live site.
If the draft and production changed the same lines, nothing is pushed and your branch stays as it was. The dialog lists the conflicting files and links to the comparison on GitHub, where you can resolve them.
Get the Latest from GitHub
Use Get the latest from GitHub when the repository changed somewhere else (a teammate, an AI agent working on its own copy, or an edit on github.com) and you want those changes in the editor.
This replaces your workspace copy with the branch on GitHub. Changes you haven't committed are lost. Publish or commit anything you want to keep first.
It gets the branch you're on. To get your production branch instead, switch branches first. Open files and the preview reload with the new code.
When GitHub Has Newer Changes
If GitHub received changes that overlap with yours since you last synced, publishing stops with Your commit is saved, but newer changes on GitHub overlap with yours and offers Resolve conflicts. Your work is safe. See Publishing Changes and Resolving Conflicts for the step-by-step resolver.
Next Steps
- Publishing Changes and Resolving Conflicts: what to do when GitHub has overlapping changes
- Deploy Hooks: redeploy from a CMS, a CI step or a script
- Deploying to Vercel and Deploying to Cloudflare Workers: set up hosting
- Deployment Troubleshooting: when a deploy fails