What does deploying a site from the terminal involve?
Deploying means putting a new version of a website where visitors can reach it. On most shared hosts that’s a folder called public_html on the server: whatever is in it is the website. Deploying from the terminal pulls together everything from this course: archives, ssh, scp, permissions, careful deleting and checking your work.
The project follows six steps, the same ones written in deploy-checklist.txt: pack the site, copy it up, back up the live site, unpack, fix permissions, and check. Each step has a way to confirm it worked before you move on, and that habit is what makes a deploy dull in the good sense.
Spoke and Chain’s new site sits on the laptop in ~/bike-shop/site: a home page announcing summer hire, a hire page with new prices, a stylesheet and a logo. The live site on shop-server still advertises the spring sale.
tar -xzf away from undone.How do you pack the site so it unpacks in the right place?
Decide where the files must land, then shape the archive to match. You want index.html directly inside public_html, so the paths in the archive should start with the files themselves, with no site/ in front. The tidy way is to go into the folder and pack ., meaning “this folder”, while writing the archive one level up so it doesn’t try to include itself.
List it before it goes anywhere. Paths starting ./ mean the contents will spill into whichever folder you unpack in, which is what you want for public_html. If they started site/, you’d get a public_html/site folder and visitors would still see the old home page.
tar -czf site.tar.gz -C site . does the same without cd: tar steps into site before packing. That works in the practice terminal too.
cd site
tar -czf ../site-2026-03-14.tar.gz .
cd ..
tar -tzf site-2026-03-14.tar.gz
./
./css/
./css/style.css
./hire.html
./images/
./images/logo.png
./index.htmlWhere should the archive go on the server?
Copy it into your home folder on the server, outside public_html. Anything inside public_html can be downloaded by anyone who guesses the name, and an archive of your site, or worse a backup, is not something to publish. The trailing :~ means the home folder.
The scp command prints a progress line when it finishes. Then log in with ssh and run ls to see the archive sitting next to public_html. From this point on, read the prompt before every command: you’re on shop-server.
scp site-2026-03-14.tar.gz spoke@shop-server:~
ssh spoke@shop-server
ls
public_html/ site-2026-03-14.tar.gzWhy back up the live site first?
Unpacking replaces files with the same name without asking. If the new version has a mistake, the old version is gone unless you saved it. A backup takes one line and a second or two, and it means any problem is a quick restore instead of an emergency.
Name backups with the date and keep them outside public_html. Check that the backup contains the pages you expect with tar -tzf before trusting it. To roll back later, unpack it from the home folder: the paths start with public_html/, so tar -xzf backup-2026-03-14.tar.gz puts the old files back where they were.
Your host probably keeps its own daily backups as well. They’re a second line of defence, and restoring from them can take hours or a support ticket. Your own backup is there in seconds.
tar -czf backup-2026-03-14.tar.gz public_html
tar -tzf backup-2026-03-14.tar.gz
public_html/
public_html/css/
public_html/css/style.css
public_html/hire.html
public_html/index.htmlHow do you unpack into public_html?
Use -C to say where: tar -xzf site-2026-03-14.tar.gz -C public_html. The new index.html, hire.html and css/style.css replace the old ones, and images/logo.png is added. Any old file that isn’t in the new archive stays where it is, which is usually what you want for things like uploaded photos.
If the new site has removed a page, delete the old copy by hand after checking it’s really unused. Don’t reach for rm -rf public_html/* before unpacking to “start clean”: it takes every file the archive doesn’t replace with it, including files other tools put there, such as .htaccess and verification files for search engines.
tar -xzf site-2026-03-14.tar.gz -C public_html
ls -l public_htmlWhy do permissions break deploys, and how do you fix them?
The web server runs as a different user from you. It needs to read every file and enter every folder in public_html. Files made on the laptop here came out as -rw------- (600), readable by you alone, and tar keeps permissions as they were packed. The site would load with a 403 Forbidden error, even though every file is in place.
The usual settings are 644 for files and 755 for folders: you can change them, everyone else can read. find with -exec sets them in two lines, one for each type. The {} stands for each path found and \; ends the command for find.
Never use 777 to make a 403 go away. Many hosts refuse to serve files that others can write, and those that do serve them leave your site open to any other account on the machine.
find public_html -type f -exec chmod 644 {} \;
find public_html -type d -exec chmod 755 {} \;
ls -l public_html
total 40
drwxr-xr-x 1 spoke spoke 4096 Mar 8 09:13 css
-rw-r--r-- 1 spoke spoke 111 Mar 15 09:18 hire.html
drwxr-xr-x 1 spoke spoke 4096 Mar 22 09:19 images
-rw-r--r-- 1 spoke spoke 257 Mar 8 09:21 index.htmlHow do you check the deploy worked?
Check from the server first. ls -l public_html shows every file in place with the right permissions. grep -i summer public_html/index.html proves the new home page is the one being served, without opening a browser.
Then check from the outside: open the site in a browser, use a private window so the old version isn’t cached, and click through the pages you changed. Look for missing styles or images, which usually mean a path or permission problem on a folder.
Finally exit, and leave the archives in the server’s home folder for a week or two in case you need to roll back. Delete old ones once you’re sure, checking the names with ls before the rm.
grep -i summer public_html/index.html
<p>Summer hire now open: cargo bikes, hybrids and tandems.</p>
exit
logout
Connection to shop-server closed.What goes wrong most often?
Unpacking an archive packed from the wrong folder, so pages land in public_html/site. Forgetting the backup. Leaving files at 600 so the site returns 403. Running a command on the laptop that was meant for the server, or the other way round. Each one shows up in this project’s Break It.
Every one of these has the same remedy: check after each step instead of at the end. tar -tzf after packing, ls after copying, tar -tzf on the backup, ls -l after unpacking, grep before logging out.
How do you deploy with AI help safely?
AI tools are good at writing deploy scripts, and those scripts often contain the risky patterns from the previous lesson: rm -rf public_html/* before unpacking, chmod -R 777 to fix permissions, sudo on hosts where you have none, and paths such as /var/www/html that belong to a different kind of server. Swap in your own paths and check each line.
Once you’ve done this by hand a few times, putting the steps into a script is a sensible next move. Keep the backup line first, keep the checks, and run the script with bash -x deploy.sh the first time so each command is printed before it runs. Bigger sites move on to tools such as rsync or git-based deploys, which build on exactly these ideas.
Field notes
- Pack the site from inside its folder so files land in the right place.
- Back up the live site with
tarbefore you unpack the new one. - Unpack into
public_htmlwith-C, then set files to 644 and folders to 755. - Check the live files before you log out.
Easy to get wrong
Packing the folder by name puts site/ at the start of every path, so it unpacks into public_html/site instead of public_html.
An archive inside public_html can be downloaded by anyone who guesses its name. Keep it in the home folder.
777 lets every account on the server change your site. Files need 644 and folders 755.
Deleting first throws away files the archive doesn’t contain, such as .htaccess. Back up, then unpack over the top.
Questions people ask
How do I roll back if the new version is broken?
Log in, go to your home folder and run tar -xzf backup-2026-03-14.tar.gz. The backup’s paths start with public_html/, so the old files go back where they were. Fix permissions again if needed.
Can I do this with cPanel’s File Manager instead?
Yes. Upload the archive, use Extract, and set permissions with the Permissions button. The terminal is faster once it’s familiar, and the same commands work on any Linux host.
Why not copy the folder with scp -r instead of making an archive?
That works for a few files. An archive copies in one go, gives you a dated record of exactly what was deployed, and keeps permissions consistent.
Do I need to stop the website while deploying?
Not for a small static site. Unpacking takes a moment, and visitors see either the old page or the new one. Bigger sites with databases need more care.
What should I learn next?
Git, for keeping every version of the site, and rsync, which copies only what changed. Both build on ssh, which you now know.