Creating My Website

In the original “Creating My Website” post I actually started ranting about how modern web development is pure React and JavaScrpt and what not, and actually went as far as to make the website twice: once with Next.js and another time with HUGO, just to prove a point.

I might revisit the topic on a dedicate post, but you get the main point: I’m using HUGO. Among the main reasons are:

• Separation between content and website. (I care much more about the markdown files than the website itself)
• Small footprint. (No, I don’t want a 10MB JS bundle to render plain text, I’m pretty sure I even overdid the CSS already)

To get started:

1. Getting myself a domain and a VPS:

Went with Hostinger, simply for the convenience + payment method (Pix).

Picking the domain itself was harder, honestly. Ended up with marcusvrp.dev (though you probably know that, after all you’re reading this), which is nice, specially the “secure top-level-domain” (HSTS) shenanigans.

I went with a simple Debian Trixie VM. As far as specs go: even the cheapest option was overkill, so I got some flexibility with what I end up running there.

2. Getting the DNS right:

One of the pros of using Hostinger for both the VPS and the DNS is that pointing it was done in the same screen pretty much. (Doesn’t actually make any difference, but I’m trying to convince myself that not saving 5 bucks was worth it)

3. Deploying the Website with SSL

Install nginx with apt install -y nginx on the VPS to serve our website. We then enable it with systemctl enable --now nginx. Then, as easy as it gets: Do a hugo build --minify and copy the public/ directory results to the VPS’s /var/www/html/.

After that it’s as simple as configuring nginx with something like this:

server {
    listen 80;
    server_name marcusvrp.dev www.marcusvrp.dev;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name marcusvrp.dev www.marcusvrp.dev;

    ssl_certificate /etc/letsencrypt/live/marcusvrp.dev/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/marcusvrp.dev/privkey.pem;

    root /var/www/html;
    index index.html index.htm;

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

Oh wait, I don’t have certificates.

4. Let’s Encrypt!

I’m trying as hard as I can to make this look more exciting, but everything after step 1 took less than 5 minutes, so…

We need certbot: apt install -y certbot python3-certbot-nginx. Then we just need to run certbot certonly --nginx to get the certificate files.

To be fair the most exciting thing I can think of so far is explaining how Let’s Encrypt works, but there’s literally a page called “How It Works”. Worth a read if you’ve never thought about it, very simple.

Aaand finally, website is up.

An e-mail server!

The second part that might interest some people is the e-mail server I want to set up.

I’ve been wanting to get rid of my G-Mail for some time now, and managing my own e-mail seems to be the first step towards freedom. I’ll still be locked due to Android, but we’re doing this one step at a time. I might get Pixel phone eventually and switch to GrapheneOS. Would allow me to write a nice “what to expect” blog.

Look how cool

I can now manage aliases, for instance. I’ve observed that some data leaks are “smart”: I registered my usual youwish+<service-name>@gmail.com and the service-name was missing!

I literally created the email and used it once, meaning either Google or the app I used the “burner e-mail” on leaked it, both call for a better alternative: self-hosting + aliases.

You won’t know linkedin@marcusvrp.dev actually points to who-knows@marcusvrp.dev, so if I get spam from the first address I know the leak was there.

Does it make a difference? Not really, they’ll leak data anyways, but I find it cool to know. This is specially useful for password management. E-mail was leaked? How do you know your (hopefully) hashed password was not? No worries, you received spam from LinkedIn’s address, so you only need to change that password.

Adding/Removing an alias for a service is as running a script, “which is a trivial task and left as an exercise for the reader”.

Know what is even cooler? If I remove the alias and the mail never gets delivered the chance of that particular piece of data being deleted from the service’s database is higher. Theoretically you can reduce your digital footprint like this, but I’ve never tested the efficacy of burner e-mails on a server I control. So there’s a chance I’m just wasting your time here.

Should you?

Should I install my own e-mail server?

If you’re unsure: no. Even if you want one you can skip the hassle of setting it up using paid services, and they handle the annoying stuff for you. It’s still limited, as any SaaS will be, but it might be just be enough for you.

I’m all for self-hosting, but having your own e-mail server not properly set up might affect other areas of your life that depend on working e-mail. If you’re not willing to face these challenges, don’t bother.

Conclusions

After the first website deploy I noticed something: pretty much all my content is marked as draft. So I have about 30 blogs or so to publish over time.

I was going to do some optimizing here and there to make the website accessible even on very slow networks. But aside from media and fonts the whole thing is less than 12kB, so I’m not even going to bother for now. Media and fonts will require a bit more energy than what I have right now.

Hope you liked this.