Section 1

Server Setup

How a website actually exists on the internet — and how to put one up yourself, or tell an AI to do it for you and still understand what it did.

The four things every website needs

Google, your school's website, the page you're reading right now — all of them are the same four things. There is no fifth secret thing.

1. A computer that never turns off. This is the server. It holds your files.
2. An address. Something like 172.105.229.70. Computers find each other with numbers.
3. A name that points to that address. Like yashina.burns.jp. Humans are bad at remembering numbers, so we built a phone book. That phone book is called DNS.
4. A program that hands files to visitors. Usually nginx (say it "engine-x"). It listens for knocks on the door and hands out the right pages.

And one more, because the modern web insists on it:

5. A lock. An SSL certificate. It's what makes the address start with https:// instead of http://, and what stops browsers from showing scary "Not Secure" warnings.

The building analogy

If the words above felt abstract, map them onto something physical:

When someone types your website's name, their computer asks the phone book "where does this name live?", gets back a street address, knocks on that door, and the receptionist hands over the right room's contents. That round trip happens in under a second, millions of times a day, and it has worked essentially this way since the 1980s.

Your own address, decoded

Look at the address bar of the page you're on right now. It has three different layers, and people mix them up constantly:

You are looking at all three at once. Hold onto that — the next section is entirely about the difference between the last two.

The big one: subdomain vs. path

Say Microsoft wants a page for engineers. They have two choices, and both are completely valid:

How to decide

Ask yourself one question:

• Use a path when it's a section of the same site. An about page, a blog, a portfolio, a contact form. yoursite.com/about.
• Use a subdomain when it's genuinely a separate thing. A different app, a store running on different software, an admin dashboard, a docs site built with a different tool. shop.yoursite.com.

A mistake worth avoiding

Beginners often make a subdomain for every little thing — about.mysite.com, blog.mysite.com, photos.mysite.com — because it feels more official. Now you're maintaining four DNS records, four SSL certificates, and four server configs for what should have been four folders. Worse, search engines may treat them as four unrelated websites, so none of them builds up the reputation that would have helped the others.

Setting it up, step by step

This uses Linode (a company that rents you servers), but every hosting company works the same way. The names of the buttons change; the five steps do not.

0Own a domain

Before anything else. Buy a domain from a registrar — Namecheap, Cloudflare, Porkbun, GoDaddy. Expect $10–20 per year.

1Rent a server

On Linode: create a new instance.

• Image: Ubuntu LTS (the most recent "LTS" version — it means Long Term Support, i.e. stable and patched for years)
• Region: physically near the people who'll visit. California visitors → a US West datacenter.
• Size: the cheapest one. Genuinely. A static website serves thousands of visitors on the smallest plan. You can resize later.

When it finishes building, Linode shows you an IP address. That's your street address. Write it down.

2Point the name at the server — the A record

Go to wherever you bought the domain, find the DNS settings, and add a record:

To check it worked, open a terminal and ask the phone book directly:

dig +short yashina.burns.jp

If it prints your IP, it worked. If it prints nothing, either the record is wrong or it hasn't spread yet. Registrars warn that DNS can take 48 hours; in practice it's usually minutes. Different parts of the world update at different speeds, so it working on your laptop but not your phone for a while is normal, not broken.

3Install the receptionist

Connect to the server and install nginx:

ssh root@172.105.229.70

apt update
apt install nginx -y

Put your files somewhere, conventionally under /var/www/:

mkdir -p /var/www/yashina.burns.jp

Then tell nginx that this name maps to that folder. Create /etc/nginx/sites-available/yashina.burns.jp:

server {
    listen 80;
    server_name yashina.burns.jp;

    root /var/www/yashina.burns.jp;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Read that out loud and it's almost English: listen on the normal web port; when someone asks for this name; serve files from this folder; if the file isn't there, say 404 Not Found.

Turn it on:

ln -s /etc/nginx/sites-available/yashina.burns.jp /etc/nginx/sites-enabled/

nginx -t                  # ALWAYS test first
systemctl reload nginx    # only if the test passed

4Add the lock

Certificates used to cost money and take days. Now they're free and take about ten seconds, thanks to a nonprofit called Let's Encrypt. The tool is certbot:

apt install certbot python3-certbot-nginx -y

certbot --nginx -d yashina.burns.jp

It proves you control the name by placing a secret file on your server and checking it can fetch that file over the address — which is exactly why the A record has to work before this step. It then rewrites your nginx config to use the certificate and redirect http:// to https://.

Certificates expire every 90 days. Certbot installs a scheduled job that renews automatically, so this is genuinely a once-per-subdomain task.

Adding a path — the easy one

Now compare all of that to adding /training to a site that already exists:

mkdir -p /var/www/yashina.burns.jp/training
# put an index.html inside it

Done. No DNS. No certificate. No reload. No waiting. It's live the instant the file lands.

That is the difference the Microsoft comparison was pointing at. One of these is a construction project and the other is opening a drawer.

Getting an AI to do it for you

You don't have to memorize these commands. You do need to know enough to tell when an AI has done something wrong — which it will, confidently, at some point.

A prompt that works:

I have a Linode server at <IP ADDRESS> running Ubuntu,
and I own the domain <DOMAIN>.

I want <SUBDOMAIN>.<DOMAIN> to serve a simple static
site with an SSL certificate.

Walk me through it step by step. Tell me exactly which
DNS record to add at my registrar — I'll add it myself.
Before reloading nginx, always run nginx -t and show me
the output. Explain what each command does before running it.

Why that prompt is shaped the way it is:

• "I'll add the DNS record myself" — the one step that touches an account with your credit card on it stays with you.
• "always run nginx -t and show me the output" — forces the safety check to be visible instead of assumed.
• "explain before running" — you learn, and you get a chance to say "wait, why?" before something happens rather than after.

Things to try

All of these are safe. None can break anything that matters.

1. Change the smiley. Open this site's index.html, swap the emoji, reload. Smallest possible full loop: edit → deploy → see it.
2. Add a path. Make /training/hello/ with its own index.html. Notice you touched no DNS and no certificate. This is the lesson, felt rather than read.
3. Break it deliberately. Visit a URL that doesn't exist and meet your first 404. Then look at the server's log and find your own visit in it: tail /var/log/nginx/yashina.burns.jp.access.log. Every visit to every website is written down somewhere like this.
4. Trace a real site. Run dig +short github.com. Those are real servers you just looked up in the real phone book — the same one your browser uses.
5. Go find both patterns in the wild. Spend five minutes noticing which big sites use docs.company.com and which use company.com/docs. Once you see it, you can't unsee it.

Rules that keep you safe

• Test before you reload. nginx -t, every single time.
• Never run rm -rf unless you fully understand the path after it. There is no undo, no recycle bin, and no confirmation. It is the single most expensive command in computing.
• On a shared server, stay in your own folder. If a machine hosts other people's live websites, your edits belong under your own directory and your own config file — nowhere else.
• Changing files is cheap. Deleting them is not. When in doubt, rename something to whatever.bak instead of deleting it.
• If you're unsure, ask before you run it. Nobody has ever regretted this.

Words you now know