Hello, World!

Welcome to my blog.

I’m Marco, and this is my small corner of the internet where I write about building software: sometimes with a calm, backend-brain energy, sometimes with a “what if I animate everything” energy.

This first post is less a “Hello World” and more a “Hello, here’s the machine room” — a tour of the stack and the little decisions behind it.

🔗The VPS: openSUSE, but make it cozy

This site lives on a VPS running openSUSE.

I like a setup where I can see the whole system end-to-end: the OS, the web server, the deployment, the logs, the “why is this returning 403?” moments. It’s a quiet kind of control: not in a “I do everything manually forever” way, but in a “I know where the pieces are” way.

The vibe I aim for is:

Keep the server small and understandable.
Keep the moving parts intentional.
Automate the repetitive stuff.
Still be able to SSH in and make sense of what’s happening.

On the same VPS I’m also hosting a demo instance of my other project, OpenLikwid (openlikwid.org). So from day one this blog had a requirement:

Don’t break the existing thing.

Which is a very adult constraint that immediately makes everything more interesting.

🔗Caddy: the traffic cop at the front door

Caddy is what makes “one VPS, multiple projects” feel boring (in the best way).

At a high level, I use it as the front door that:

Terminates HTTPS automatically.
Routes the right domain to the right place.
Serves static files when that’s all that’s needed.

For this blog, that’s mostly: “when the request is for marcoallegretti.me, serve a directory of static files.”

For OpenLikwid, it’s the other kind of setup: an application stack (containers, services, ports) living behind the scenes, with Caddy proxying requests to the right internal service. So the same front door can handle both:

A static site (this blog)
A running app (OpenLikwid)

The Caddy config for the blog is intentionally simple: compression, a root directory on the VPS (/home/deploy/marcoallegretti.me), a file server, and a few security-ish headers. Errors get rewritten to 404.html so missing routes behave like a normal website instead of a directory listing safari.

It’s clean, it’s predictable, and it lets the OpenLikwid demo coexist without the two projects stepping on each other.

🔗Why Zola?

I chose Zola for a mix of practical reasons and personal taste.

The practical reasons:

Rust, single binary — it’s fast, simple to run, and easy to keep around on any machine.
Templates + Markdown — writing posts should feel like writing, not like wrestling a framework.
Good “default” features — Sass compilation, syntax highlighting, feeds: the basics are there without turning the project into a build-system hobby.

Zola also hits a sweet spot for me: it’s “web” enough to be expressive (Tera templates, content sections, taxonomies), but not so big that it turns into a framework-shaped lifestyle.

And the taste part: I like tools that are opinionated enough to get you moving, but not so opinionated that they decide your entire personality.

🔗Putting the blog together (without turning it into a ceremony)

The setup is intentionally boring:

Content lives in Markdown.
Layout is plain templates.
Styling is SCSS compiled by Zola.

And then I let the “boring parts” do their job.

In practice, that meant:

Pages and sections are just content + templates.
Syntax highlighting is a built-in feature (so code snippets don’t look like they’re wearing a trench coat).
Feeds exist by default, because I still like the old web.

There were a few small real-world bumps that ended up shaping the workflow:

Unicode vs. minification. At one point some characters were getting mangled, so I kept HTML minification off.
Windows vs. deployment tools. Some tooling that’s “standard” on Linux isn’t always present (or behaves the same way) on Windows.

None of these were dramatic. But they’re exactly the kind of tiny papercuts that make you appreciate a setup where each layer is understandable.

Also: I’m picky about the “default” web stuff.

Feeds are enabled.
Syntax highlighting is enabled.
SCSS compiles as part of the build.

I want the site to feel like a website, not a social media profile.

🔗Deploying: build locally, ship a folder, let Caddy serve it

My deployment strategy is: don’t be clever.

Zola outputs the site as a static directory (public/). So deployment is simply:

Build the site.
Copy the generated files to the VPS.
Let Caddy serve them.

To make this repeatable, I ended up with a small deploy script (there’s both a deploy.sh and a deploy.ps1). Under the hood it does a straightforward thing:

SSH into the server.
Clean the destination directory (/home/deploy/marcoallegretti.me).
Stream a tar archive over SSH and extract it on the other side.

That last part deserves a tiny shout-out: streaming a tarball is the kind of “old school” approach that keeps working even when your environment is a little quirky (and yes, Windows can be quirky).

It’s not glamorous, but it’s fast, it’s atomic enough for a personal site, and it doesn’t require extra services.

My favorite part is that it keeps the “deployment interface” tiny:

One command locally.
One directory remotely.
The web server just serves what’s there.

There was also one of those “this is why I self-host” moments: system services can be sandboxed in ways that are great for security, but surprising the first time you hit them. Caddy initially didn’t love reading files from inside a home directory under systemd hardening, so I adjusted the service override to allow the site directory.

Again: not a big deal. But it’s exactly the kind of detail that makes a VPS feel like a real machine you understand, not just a black box.

🔗A short detour into Squishy UI (a.k.a. “I am not a GUI artist”)

At some point I decided this blog shouldn’t just exist — it should move.

So I tried a little frontend exercise: a “Squishy UI”-style design.

If you’ve never heard the term, it’s that tactile-feeling UI trend where buttons feel like soft rubber, cards float and tilt, animations have springy easing, and the whole page behaves like it has weight.

Here’s the honest part: I consider myself more of a backend developer than a UI artist. I can build systems, ship services, and chase down performance bottlenecks with a smile — but if you ask me to pick between twelve slightly different border radiuses, I start making the same face as when a database migration takes longer than it should.

Still, it was a fun experiment. We iterated from “a few hover transitions” into “okay, now everything is animated and the page has physics.”

Some highlights of what ended up in here:

Spring-ish hover and click interactions.
Glassy cards with subtle depth.
Scroll-triggered reveals.
A smooth-scrolling layer.
A little blob/gradient background that reacts to the pointer.

Is it the final form? Probably not. But it’s a good reminder that frontend work is a skill like any other: you get better by doing, then doing again, and then doing one more pass because you noticed the button label is one pixel off.

🔗What to expect from this blog

This blog is where I’ll write about the things I’m building and the things I’m learning.

Topics I’ll likely cover:

Software engineering practices and patterns
Rust and systems programming
DevOps, self-hosting, and infrastructure
Side projects, experiments, and what went right/wrong

If you’re reading this: welcome. If you’re future-me reading this: hi, please remember to renew the domain.