Deploy, break and recover a site
How do I deploy a website, connect a domain, enable HTTPS and practice a rollback?
Deploy a sample site from a repository, connect a test domain, turn on HTTPS, set up error alerts and backups, then deliberately break it and roll back so recovery is a habit.
What you will be able to do
Deploy a sample site from a code repository, connect a test domain, enable HTTPS, set up alerts and backups, then deliberately break the site and recover it. By the end, a rollback is something you have done, not read about.
Before you start
- A sample site in a code repository. A small static site is ideal. If you need one, build it with From blank project to live demo.
- A test domain or subdomain you control, not a client's domain.
- An account on a static host that deploys from a repository. Check the current terms first, as in Low cost hosting options.
Why this matters
Every site breaks eventually: a bad deploy, a deleted file, an expired certificate, a hurried DNS change. If the first time you roll back is with a client on the phone, you will be slow and make it worse. This lesson is a rehearsal on your own test domain, so nothing you break matters. Do every step for real.
- 1BuildProduction output
- 2RepositoryEvery change versioned
- 3DeployPreview, then production
- 4DNSPoint the domain
- 5HTTPSCertificate issued
- 6VerifyClick through the live site
- 7RollbackKnow how to go back
Never paste real passwords, API keys or tokens into code, screenshots, chat or email. Placeholders here look like YOUR_TOKEN_HERE. Real values belong in your password manager and the host's environment variable settings.
Step by step
Tick each step as you do it. Your ticks are saved in this browser.
Put the sample site in a repository and tag a good version
Commit it, make sure it builds locally, and mark the commit as known good. That is your rollback target.
git tag v1-known-good git push --tagsConnect the repository to the host and deploy
Create a new project for this site only, connect the repository, set the build command and output folder, and deploy. Open the temporary address and check every page on desktop and on your phone.
Connect the test domain
Add the domain to the project; the host tells you which DNS records to create. Export or screenshot the current DNS zone first, then add the records. DNS takes time to spread, so wait and check again rather than changing things repeatedly.
Enable HTTPS and force it
Confirm the padlock, then turn on the redirect from HTTP to HTTPS. Visit the
http://version and confirm it lands onhttps://, for both the bare domain andwww.Set up uptime and error monitoring
Add an uptime monitor on the homepage that alerts you when it fails. If the site has JavaScript or a form, add error monitoring. Send yourself a test alert so you know where one arrives.
Configure backups you control
For a static site the repository is the main backup, so keep a second copy too (for example a scheduled export to your agency storage). For a CMS, back up files and database somewhere other than the same server, and note how long backups are kept. Write the backup location in the site's password manager entry.
Break the site on purpose
Delete the homepage content, break the stylesheet link, or add a build error. Deploy it. Confirm it is broken, check whether your monitor notices, and note the time.
Roll back
Use the host's deploy history to restore the previous good deploy. Then fix the repository too, so the next deploy does not bring the bad change back:
git revert HEAD git pushNote the time again. The gap is your recovery time.
Restore from backup on a fresh project
Pretend the whole project was deleted. Create a new project, deploy from your backup copy (or restore the CMS backup to a fresh install), and connect a second test subdomain. If this works, you can survive a lost account or a host ending your plan.
Write the recovery runbook
One page with the exact rollback and restore steps, where the backups live and who to call. Add it to your procedures and run the launch QA checklist on the restored site.
Example
A recovery log from a rehearsal on a pretend cafe site at cafetest.yourstudio.example:
SITE: cafe-test (practice)
Host project: cafe-test (separate project)
Repository: yourstudio/cafe-test
Known good tag: v1-known-good
Domain: cafetest.yourstudio.example, DNS zone exported before change
HTTPS: on, HTTP redirects to HTTPS, checked bare and www
Uptime monitor: homepage, alerts to studio inbox, test alert received
Backups: repository plus weekly export to agency storage
DRILL
Broke site: removed stylesheet link, deployed
Monitor noticed: no (page still returned OK). Added a content check for the word "Menu".
Rolled back via host deploy history
Fixed repository with git revert
Full restore: new project from backup copy on cafe-restore subdomain, worked
LESSONS
* Uptime check alone missed a broken page. Content check added.
* Write the build settings in the runbook, I had to look them up during restore.
That first lesson is common. A basic uptime check confirms the server answered, not that the page is right. A check for a word that should always be on the page catches far more.
Common mistakes
- Practicing on a client site. Use your own test domain and a sample site.
- Rolling back the host but not the repository. The next deploy brings the bad change straight back.
- Backups on the same server as the site. Lose the account and the backups go with it.
- Trusting the monitor without testing it. If you have never received a test alert, you do not know alerts work.
Try it yourself
Do the full drill on a sample site and test domain: deploy, connect domain, HTTPS, monitoring, backups, break, roll back, full restore. Keep a log like the example with timings and what you learned.
Deliverable: a recovery log plus a one page recovery runbook you can follow for real client sites.
Time: about 90 minutes.
Resources
- Launch QA checklist run it on every deploy and every restore
- Hosting fundamentals for agencies DNS and hosting basics
- Publish with a domain, DNS and HTTPS the first launch in detail
- Managing many client sites apply this runbook across every client
Finished this lesson?
Mark it complete to track your progress through the course.
Last reviewed October 18, 2026. Prices, laws and tool terms change, so check current terms before you rely on any figure.