Deploying your own site: GitHub Pages, Vercel or an ordinary host

Deploying a site means moving its files to a host that serves them to all, such as GitHub Pages or Vercel, and attaching a domain of its own with HTTPS.

From files to an address

You have a site: the files in the gallery that you built across ten parts. But for now only you can see them. To deploy a site is to put those files on a computer that serves them to everyone. You already know everything needed: what hosting, a domain, DNS, a certificate and a pipeline are. Now we put them together.

One honest caveat. A real deploy can’t be shown here: the textbook’s sandbox has no network, and nothing you do on this page is published. So what follows is a rehearsal: the steps are real, taken from the providers’ documentation in October 2026, and you can repeat them yourself. Interfaces change, so the steps name what to look for, not which button to press.

What you are deploying

Open the gallery and press “Download the site” on any version. You get an archive with the site’s files and a README.md with short instructions (the same three ways are in it). Everything you deploy is a static site: HTML files, CSS and images. For such a site, to deploy is to “put the files so that index.html lies at the top level of the folder the server serves”.

A request form on a static site receives nothing by itself: it needs a receiver (a form service or a function, as in the lesson on serverless). That doesn’t get in the way of deploying: the pages are served, and the receiver is connected separately.

Three ways

GitHub Pages. Free for public repositories. The site is served straight from the repository, and every change updates it. It suits you if you’re ready to make a GitHub account and your site is no secret (a repository on the free plan is public, so there must be no secrets in the files). GitHub’s terms also say Pages isn’t meant for running an online business or a store (checked October 2026), so a shop belongs elsewhere. The default address looks like https://account.github.io/repository/; your own domain is attached with DNS records (four A records for the root and a CNAME for www), and GitHub turns on HTTPS itself after the certificate is issued.

Vercel. There’s a free Hobby plan, but it is for personal, non-commercial use only: a site that earns money needs a paid plan or another host (Vercel’s plan page, October 2026). You can connect a repository (then every commit deploys by itself, and other branches give a preview) or simply drag a folder onto the Vercel Drop page, which works even without an account for a static site. A domain is attached in the project’s settings, and Vercel shows right there which records are needed: use the values from your project, not from other people’s articles. The previous deploy can be restored. Netlify and Cloudflare Pages work in much the same way, and Netlify has its own drag-and-drop page.

An ordinary web host. Paid (a few dollars a month), with a contract and support, and a data center in a region you can choose, which is convenient when you have a form with personal data. You choose a plan, add the site and the domain in the panel, upload the files to the site’s folder (usually public_html, but called something else at some hosts) and point the domain: by changing the NS to the host’s servers, or with an A record with the address the host gives you. The certificate is switched on with a button in the panel.

A note on the Russian market: a Russian shared host is the usual third choice there, because the law favors a data center in Russia for forms with citizens’ personal data. The steps are the same as for any ordinary host.

Choose by the rule from the first lesson: the simplest way where your project’s main action works. For a business card that is almost always the free static option, and for a project with a form and customers in a particular region it’s a host in that region, with the receiver there too.

A rehearsal

Choose a way and check off the steps. The page fills in your project’s address. Under the steps is a list of symptoms with causes: the commonest are “I deployed and it’s empty” and “a certificate warning”.

This is a rehearsal: nothing is sent or published. The steps are real, and you can repeat them yourself.

GitHub PagesVercelAn ordinary web host

Free for public repositories; the site is served from the repository. GitHub’s terms say Pages is not meant for running an online business or a store (checked October 2026).

Your site will be at an address like https://your-account.github.io/my-site/, and on your own domain: https://example.com/.

Your domain (as an example):

1. Download your site from the gallery (“Download the site”): you get an archive with the files and a README.
2. Create an account at github.com and a new repository with a name of Latin letters and hyphens, say.
3. Upload the files to the root of the repository (the “Add file”, “Upload files” button) and save (“Commit”). index.html has to be at the top level.
4. In the repository, open Settings, then Pages, choose the source: the main branch and the root folder, and save.

   Wait a few minutes (sometimes up to ten): an address appears at the top of the Pages section.

5. Open the address that looks like https://your-account.github.io/repository-name/ and make sure the page is the same as in the preview.

   If it is empty or a 404, see the “Something is wrong” section below.

6. Your own domain: in Settings, Pages, enter the domain in the Custom domain field and save, then add the DNS records from GitHub’s documentation at your registrar (four A records for the root and a CNAME for www pointing to your-account.github.io).
7. When the certificate is ready (up to a day), check “Enforce HTTPS”.

   Check: http:// redirects to https://, and both www and no-www open.

Steps checked: 0 of 7.

Something is wrong

The symptom 404 or empty after the deployThe page has no styles and picturesThe old site shows after an editA certificate warning on your own domainThe domain doesn’t open at allIt opens without www but not with it (or the reverse)

Most often. The file index.html is not at the top level of the published folder, the wrong branch or folder is chosen, or the case of letters in a name is off (on servers Index.html and index.html are different files).

What to do. Check the publishing source in the settings and the position of index.html. Wait up to ten minutes after the deploy.

Check yourself: why write file addresses without a slash at the start when deploying to a subfolder?

An address with a slash is counted from the root of the domain, and the browser won’t find the file if the site lies in a subfolder. Relative addresses (styles.css) are counted from the page itself and work anywhere.

Attaching your own domain

The order is the same for any way, and it’s familiar from the lessons on DNS and HTTPS.

1. First add the domain in the platform’s settings (at GitHub that is Settings, Pages, Custom domain; at Vercel, Settings, Domains). The platform will say which records are needed.
2. Then add the records at the registrar (or wherever the NS point): for the root an A (or ALIAS), for www a CNAME. Copy the values from the platform’s panel.
3. Wait. Records spread by their TTL, and the certificate is issued after the platform sees the right records. At GitHub that can take up to a day.
4. Turn on HTTPS and the redirect. Choose one main address (with www or without) and redirect the other to it.
5. Check with dig and by opening the site from a mobile network: home internet has a cache of its own.

Don’t change records one after another if it doesn’t work at once: every change resets the wait. Compare with the symptoms above and wait out the TTL.

What to check after a deploy

• Does the site open over https://, and does http:// redirect to it?
• Do both www and the address without www open?
• Are all the pages, images and styles in place (paths relative, the case of letters matching)?
• Does the project’s main action work at the real address: does the form send, does the booking reach you?
• How does the site look on a phone on the mobile network?
• Where does the form’s data go (the next lesson covers the law)?

And one last thing: deploy the site to the platform’s own address first, check it, and only then attach the domain. That way you won’t have to guess what broke: the site or DNS.

Practice

Write the deploy passport of your site: the way, the address and the six steps you’ll really take, in your own words. Then write what you’ll check after the deploy, naming the project’s main action in the words of the brief, and say where visitors’ data goes.

A passport isn’t a paper for inspection but insurance: in half a year you’ll forget where you uploaded the files and where the DNS records are, and the passport will restore it all in five minutes. If you like, after this lesson you can make a real deploy from the passport and come back to update it.

What was wrong before

In 2010 to deploy a site meant buying hosting, getting an email with a login and password for FTP, installing an upload program and dragging the files into a folder called something like www or htdocs. The site appeared without HTTPS, edits were uploaded over the top, and no earlier version was left. Today a free deploy in minutes is ordinary, and the measure of quality is no longer “the site is deployed” but “it can be changed calmly”: with checks, a rollback and a written procedure. You did the first half today, and the pipeline from the last lesson does the second.