11.1 Project — a live site on your own domain

Describes the projects, certifications and interview practice as of August 2026

What this is and why it exists

This is the first of two projects, and it is deliberately small: something you built, on the public internet, on your own domain, over HTTPS, deployed by a push, at a monthly cost you have measured. Every piece of it is something you have already learned separately, and assembling them is what turns "I did a course" into "here is the address". It is also the project that teaches the whole deploy loop without any application logic in the way.

The vocabulary

  • Static site — pages served as files, with no server-side code.
  • Origin — where the files really live; here, object storage.
  • Custom domain — a name you registered, pointed at the site.
  • Certificate — the file proving you control that name, renewed automatically.
  • Cache invalidation — telling the edge to discard an old copy.
  • Pipeline — the automation that publishes on a push.
  • Teardown — removing everything you created, so nothing keeps billing.

The mental model

Everything here is a piece you have already met, and the project is the assembly. Files live in one place, a network of caches sits in front of them, a name points at that network, and a certificate proves the name is yours. Nothing is served from a machine you run, which is why a static site is both the cheapest thing to host and the clearest possible demonstration of the deploy loop: there is no application logic to hide behind, so what you are learning is the plumbing itself.

The work

Four pieces, in this order.

Files in object storage. The site's built output goes into a bucket. The bucket is not public — you learned why in the storage module — and the content network reaches it through the provider's origin-access mechanism instead. If your first instinct is to make the bucket public because that is what the tutorial said, notice the instinct and do the other thing.

A content network in front. It caches near your users, terminates the encrypted connection close to them, and gives you one place to attach the certificate. This is also what makes the site fast from anywhere without you owning anything anywhere.

Your own domain. Register a name, host its zone with the provider's managed DNS, and point it at the distribution. Then request a certificate for that name and let it renew automatically. The lesson on certificates said that renewal is automated because a task nobody performs for two months is a task nobody remembers — this is where you confirm that for yourself, by checking a few weeks later that renewal has actually run once on its own.

A pipeline that publishes on a push. Committing to the main line builds the site, copies the output to the bucket, and invalidates the cached paths that changed. The credential the pipeline uses should be federated rather than stored — the CI lesson's rule, applied for the first time to something of yours. When this is working, deploying is a git push, and that is the moment the whole module clicks.

And then the part most people skip. Measure the monthly cost and write it down. Not an estimate from a calculator — the actual figure after the site has been up for a full billing period, broken into its lines: storage, requests, data transfer out, the DNS zone, the certificate, and the domain registration which is annual rather than monthly. Then explain each line to yourself. A static site is close to the cheapest thing you can run, so this is the ideal object on which to learn to read a bill: the numbers are small enough to be unfrightening and every line has an obvious cause.

Two habits to attach while you are here. Put a budget alert on the account even though the amount will be tiny, because the transfer line has no natural ceiling if something you host becomes popular. And write down the teardown — every resource you created, in the order they must be removed — even though you intend to keep this one. That list is the thing that makes the second project safe.

What you should now be able to explain or do

Have a site of yours reachable on your own domain over HTTPS. Explain why the bucket is private and how the content network reaches it anyway. Say where the certificate lives and how you confirmed that renewal ran without you. Deploy by pushing, and say what the pipeline does in three steps and where its credentials come from. State your actual monthly cost, line by line, and explain what causes each line.

Check yourself

Because a public bucket is the most common cloud data leak and it lets people bypass the content network entirely. The network reaches the origin through the provider's origin-access mechanism, so the files are public only through the door you control.

By checking, weeks later, that it has renewed once without anybody doing anything. Until it has run unattended, automatic renewal is a setting rather than a fact.

Builds the site, copies the output to the bucket, and invalidates the cached paths that changed. Its credentials should be federated for the run rather than stored in its settings.

Because the transfer line has no natural ceiling. A file of yours linked somewhere busy bills per gigabyte leaving, and nothing stops it on its own.

The teardown — every resource you created and the order to remove them. It costs ten minutes now and is what makes the next, larger project safe to build.

Go deeper

Back to Project — a live site on your own domain: work through the checklist