Alaa Reuschenbach

Why I built my portfolio at alaa.racing

Thu, 23 Jul 2026 00:00:00 GMT

When I registered alaa.racing, people asked me if I was starting a motorsport blog.

I wasn't. But the domain says everything about how I work.

Speed as a philosophy

In Formula 1, a tenth of a second separates the podium from the pack. Every decision - tyre choice, pit timing, aero setup - is made quickly, with the data available, and committed to fully. There's no room for endless deliberation.

I try to bring that same mindset to software.

The web should be fast too

I care deeply about web performance, not as a metric to game, but because slow websites cost people time and sometimes even money. Every unnecessary kilobyte, every render-blocking resource, every layout shift is friction between a user and what they came to do.

This site is built with plain HTML, CSS, and Eleventy. No JavaScript framework, no build pipeline heavier than it needs to be. It loads fast because it was built to load fast, not as an afterthought.

A domain that means something

Most developer portfolios live at firstname.dev or firstname.io. Nothing wrong with that. But I wanted something that felt like me: Someone who thinks about milliseconds in the browser the same way a racing engineer thinks about milliseconds on track.

alaa.racing is a small reminder to myself: Keep moving, keep iterating, and never stop chasing the next improvement.

Whether that's a faster lap time or a faster Time to First Byte.

How I deployed treff.tech

Fri, 10 Jul 2026 00:00:00 GMT

I've already written about why treff.tech exists. This time, I want to go a level deeper and walk through how it's actually deployed. The infrastructure, not the idea.

The setup: Terraform provisions the server, Ansible configures it, and Mobilizon (the software behind treff.tech) runs in Docker. Nothing exotic, but I think there's value in showing how the pieces fit together, especially for anyone considering self-hosting a Fediverse project of their own.

The stack at a glance

├── ansible/
│   ├── group_vars/
│   ├── inventory/
│   ├── playbook.yml
│   └── roles/
│       ├── docker/
│       └── security/
├── Makefile
└── terraform/
    ├── main.tf
    ├── outputs.tf
    ├── terraform.tfvars.dev
    └── variables.tf

Terraform handles the "what exists" the server itself and its networking. Ansible handles "what's on it" Docker, hardening, and the running services. A Makefile ties the two together so a full deploy is a single command, not a sequence of steps I have to remember.

Provisioning with Terraform

terraform/main.tf defines the actual infrastructure: the [cloud provider / VPS] instance treff.tech runs on, along with networking and DNS. variables.tf and terraform.tfvars.dev keep environment-specific values (like instance size and region) separate from the logic, so promoting the same setup to a production environment later is mostly a matter of swapping the .tfvars file. outputs.tf exposes things like the server's IP address, which Ansible's inventory then picks up.

Keeping this layer thin was a deliberate choice: Terraform's only job is to make the server exist. Everything about what runs on that server is Ansible's responsibility.

Configuration with Ansible

The ansible/ directory has two roles doing the real work:

docker — installs and configures Docker itself, so the host is ready to run containers. This is where Mobilizon (and its dependencies, like PostgreSQL) actually run.

security — hardens the server: [firewall rules / SSH configuration / fail2ban / automatic security updates — whichever you actually use]. This is a role I'd rather run once and mostly forget about, which is exactly the point of automating it — it runs identically every time, instead of relying on me remembering every step manually.

group_vars/all.yml.dev and inventory/hosts.yml.dev follow the same environment-separation pattern as the Terraform side — dev values are kept apart from what would eventually be production values.

Tying it together with Make

The Makefile wraps the Terraform and Ansible steps into simple commands — plan and apply infrastructure, then run the Ansible playbook against whatever Terraform just created. In practice, a full deploy or update usually comes down to one or two make commands rather than remembering the right terraform and ansible-playbook invocations each time.

Why this stack, and not something else

Mobilizon itself is straightforward to run — it's a Dockerized app, so the actual "install Mobilizon" step is small. The more interesting engineering problem was making the infrastructure reproducible: if the server disappeared tomorrow, I want to be able to stand it back up from these two directories, not from memory.

Terraform and Ansible are also just tools I'm comfortable with — nothing about treff.tech needed something more elaborate like Kubernetes. For a single-instance Fediverse platform, that would have been over-engineering for its own sake.

Takeaways

A few things I'd tell someone setting up something similar:

Keep Terraform thin. Let it provision infrastructure, and let configuration management (Ansible, in this case) own everything about the software layer.
Separate environments early, even if you only have one for now. The .dev suffix convention here made it trivial to add a second environment later without restructuring anything.
Automate the boring stuff first. The security-hardening role was the least exciting part to write and the most valuable to have automated — it's exactly the kind of task that's easy to skip a step on when done manually. If you're thinking about self-hosting Mobilizon or a similar Fediverse project and have questions about the setup, feel free to reach out.

treff.tech

Wed, 01 Jul 2026 00:00:00 GMT

You've probably run into this problem before: you're looking for tech events or conferences nearby, and the information is scattered across various platforms, groups, and newsletters. At the same time, many established providers rely on tracking, ads, or paywalls.

That's exactly why we built treff.tech with support from SWAGLab, and I've been maintaining the project ever since: an open, non-commercial platform that brings together tech events in the DACH region in one place.

What is treff.tech?

treff.tech collects community events such as user groups, conferences, and workshops from the German-speaking tech scene. Whether you're looking for an event or organizing one, treff.tech is meant to be the central place for it.

What makes treff.tech different

No tracking, no ads, no selling of data
Built on Mobilizon and part of the Fediverse
Free and open to everyone – anyone can list events
Long-term goal: develop the project together with the community and become independent treff.tech is currently sponsored and operated by SWAGLab GmbH. But the goal is clear: a platform that belongs to the community, not to commercial interests.

Why treff.tech exists

Tech events are often scattered across many different platforms, and commercial providers usually rely on ads, tracking, and paywalls. I wanted to create a privacy-friendly, non-commercial alternative — one that nobody has to monetize for growth's sake.

Get involved

Do you organize meetups, conferences, or workshops yourself? Feel free to list them on treff.tech for free, or just send me the details and I'll take care of it.

The platform is open to everyone — you can also create an account yourself and get started right away.

Learn more about treff.tech here.