pelle.io

Keeping up with recent technology developments was already hard before AI. Now that LLMs can be used to produce more stuff even faster, the perceived amount of new tools and libraries that are published every day feels staggering.

I like to read Hacker News every now and then to get a rough overview of what is happening and what might be worth looking into. My subjective feeling was that around October/November last year an inflection point was reached and the amount of new GitHub repos started to rise sharply, with a significant slowdown during the last weeks.

During a recent cloud migration project that had Scaleway as target cloud I stumbled upon their Dedibox Start-9-M dedicated server offering, delivering an AMD Ryzen™ 5 PRO 3600 (6C/12T, 3.6 GHz) machine with 32 GB of memory and two 1 TB NVMe disks for a price point of 39,99€/month. The two NVMe disks paired with the attractive price make this a nice offer for IO-intensive database workloads.

This post evaluates the performance characteristics of running a PostgreSQL 18 database on this machine. For comparison, I will try to match the performance using a managed AWS RDS PostgreSQL database.

A central aspect of the infrastructure deployed by Solidblocks cloud is the reduction of moving parts to minimize the potential attack surface. Instead of using a complex runtime involving control-planes and container schedulers, the deployed services rely on simple Debian-based VMs running plain services managed by systemd.

Despite the simplicity, security issues in the Linux kernel are sadly still an occasional thing, especially since AI-based scanners are able to reveal hard-to-find exploits faster than ever.

Although AWS S3 buckets are as stable and easy as it gets, sometimes you might not want to have an AWS dependency at all, or you expect a lot of egress traffic, making it a potentially costly choice.

Luckily, a lot of alternative implementations exist, one of them is Garage, offering a performant open-source option for self-hosting.

Garage also offers public buckets, making it a nice option to host a static website that can be deployed with any S3-compatible software and is now also an available service in Solidblocks Cloud.

April 2026 has not been kind to someone who is responsible for maintaining and securing online services, Copy Fail and dirtyfrag kept everyone busy with updating machines and making sure no data was lost or exfiltrated.

Environments provisioned with Solidblocks Cloud are always kept up to date, using Debian’s unattended-upgrade feature. While this works nicely to keep software packages up-to-date, a kernel update still requires a reboot.

This process is now automatically available in the Solidblocks cloud CLI.

The command

blcks cloud status cloud1.yaml

provides an overview of all deployed servers, and any pending kernel updates.

Most of the projects I work on nowadays are hosted on GitHub. And since many of those projects are infrastructure related, a lot of the GitHub Actions based CI runs are long-running tests verifying vital aspects like provisioning and disaster recovery. Due to the slow nature of infrastructure tests when compared to unit tests, those runs burn a considerable amount of action runner time.

When using the second-smallest runner SKU actions_linux (4 CPU/16 GB) that clocks in at 0.0513 €/hour, which for the larger projects where at least one runner is crunching away at jobs all the time comes in at around ~222 €/month.

For let’s say “geopolitical reasons” (I’ve always wanted to justify something with geopolitical reasons) I have been involved in quite a few Hyperscaler exits in the past year. While it is true that it is hard to find an exact match for services like AWS in Europe an important learning during those migrations was, that you do not always need globally-redundant-hockey-stick-growth-proof-scaled services.

The loss of convenience when leaving the managed services from the big Hyperscalers can sometimes be absorbed by simpler setups that are more focused on the really important parts of your operations.

As the number of ready-to-use Terraform modules included in my open source infrastructure components suite slowly grows, ensuring quality has been a constant topic during development. I wrote in this post about the challenges of testing infrastructure.

Dogfooding the infra-test library I wrote back then to test my newly released web-s3-docker module has led to some major improvements around integration-testing Terraform modules that will be the main topic of this post.

The infra-test library is published to Maven central, and can be included like described here.

A common obstacle I encounter when building deployments outside the typical hyperscalers like AWS or Azure is the issue where to store the initial artifacts needed to bootstrap the new deployment. Typical artifacts here are static files, like a Maven repositories, executables for services, Terraform state, Docker images or basically everything else that can be served via HTTP.

While for many uses-cases serving static data via S3 buckets is the best way to go, doing so in AWS may not always be the best option due to complicated account setup, or costly egress traffic when the data is accessed from the internet.

As laid out in my previous post “out of cloud” migrating applications from the big-hyperscalers to smaller (and cheaper) alternatives sometimes comes with the challenge to figure out alternatives for features that may be missing in the target environment you are moving the application to.

In the past I have done a lot of AWS/GCP/Azure to Hetzner cloud migrations, and one particular feature I was missing, especially for plain-VM deployments are the AWS Auto Scaling groups that automatically mange VMs attached to load balancers and are capable of conducting rolling deployment updates of those severs.