I’m not going to fill my calendar with back-to-back meetings. I’ve never really enjoyed that approach to conferences, and some of the best conversations happen spontaneously.

That said, if you’ll be in Krakow and would like to make sure we get a chance to chat, feel free to get in touch.

Hitting the trails on Sunday

After the event wraps up, I’ll be renting mountain bikes on Sunday to explore the trails west of Krakow.

If you enjoy riding bikes, being outdoors, and occasionally dodging trees, you’re welcome to join. Nothing competitive. Just a fun ride and a good way to unwind after a few days of conference talks and conversations.

If that sounds like your kind of thing, let me know via email, Mastodon, or Twitter.

In 2014 I started experimenting with content management systems beyond WordPress. First Ghost, then Jekyll, then Hugo, then 11ty, then Gozer (my own), then Astro. All of them were mostly great, but all had their downsides as well.

The reason I’m back on WordPress now is not technical. A static site comes with many benefits if you’re a developer: you get to edit posts in your favorite IDE, everything is in version control and hosting is free, simple and secure.

Those benefits eventually turned into a downside for me.

Writing versus coding

My IDE is for coding, not for writing. It is the same reason people say your bedroom should only be for sleeping: context matters. Every time I opened the site to write, my brain switched into engineering mode. Too often I would open up my site to write a new post, drift and suddenly find myself focusing on some technicality instead. Another redesign. Getting the build working. Moving stuff around so I could upgrade to the latest version.

Static is really static

You can host a static site pretty much anywhere, often for free. It is just a collection of files, after all. There is no database, no runtime, and no dynamic processing. That is part of the appeal.

It also has limits.

Want to show off a list of your GitHub repositories? You can generate it at build time, but it will not update until the next time you build and deploy the site.

Static sites are excellent when the content can be fully known at build time. Increasingly, I found myself wanting small dynamic pieces. Maybe a contact form, a comment section or some content generated from various API calls.

Of course there are ways around this. But every workaround would move the site a little further away from being a simple publishing tool, often requires a dependency on a third-party service and moves the site a little closer to being another software project.

It’s the content that matters

While moving this site back to WordPress it occurred to me that I was finally looking at and updating blog posts written well over a decade ago. I had spent years rebuilding the site around them, but not nearly enough time tending to the content itself.

WordPress gives me a place that is clearly for managing content. Not building, not configuring, not upgrading a toolchain. Writing. That matters more to me now than whether the site is statically generated, server-rendered, or deployed from Git.

I want this site to be boring again. WordPress is familiar, imperfect, flexible, occasionally annoying, and very good at being a place where words can live for a long time. Right now, that is exactly what I want.

Phpactor works well with modern PHP code when the project either follows PSR-4 or uses Composer for autoloading. WordPress does not use either approach, so phpactor can have trouble discovering symbols from WordPress core by default.

Configuring phpactor to include WordPress core files

You can solve this by setting the indexer.include_patterns configuration option to include WordPress core files. Add the following to your .phpactor.json configuration file:

{
    "indexer.include_patterns": [
        "wp-includes/**/*.php",
        "wp-admin/**/*.php",
        "wp-content/plugins/**/*.php",
        "wp-content/themes/**/*.php"
    ]
}

I also exclude WordPress core and third-party plugins from phpactor’s diagnostics through the language_server.diagnostic_exclude_paths configuration setting.

{
  "language_server.diagnostic_exclude_paths": [
    "wp-includes/**/*",
    "wp-admin/**/*",
    "wp-content/plugins/woocommerce/**/*"
  ]
}

With these two configuration options in place, phpactor can discover symbols from WordPress core and provide accurate diagnostics for your own code while ignoring issues in WordPress core or third-party plugins.

Using WordPress stubs

Alternatively, you can use stubs to give phpactor the information it needs about WordPress core functions and classes.

composer require --dev php-stubs/wordpress-stubs

This installs the php-stubs/wordpress-stubs package. You can then configure phpactor to use these stubs by adding the following to your .phpactor.json configuration file:

{
    "worse_reflection.additive_stubs": [
        "vendor/php-stubs/wordpress-stubs/wordpress-stubs.php"
    ]
}

Both approaches make phpactor more useful in WordPress projects. Indexing core files gives phpactor more project context, while stubs provide a lightweight way to expose WordPress functions and classes to the language server.

This post is in Dutch because it is specific to the Dutch retirement system.

Als zelfstandige kan het lastig zijn om te bepalen hoeveel je opzij moet zetten om later voldoende pensioen op te bouwen. Een veelgehoorde vuistregel is 5 tot 15% van je bruto inkomen. Maar als je inkomen jaarlijks sterk varieert, of als je pas later begint met pensioenbeleggen, zegt die vuistregel weinig.

Dan blijft de vraag hoeveel jaarruimte je jaarlijks wilt benutten. Dit artikel is geen financieel advies, maar een praktische rekenmethode om tot een redelijk bedrag te komen.

Wat is jaarruimte?

Jaarruimte is een fiscaal vriendelijke manier om vermogen op te bouwen dat je na je pensioendatum periodiek kunt laten uitkeren. In essentie gebruik je het om inkomen van nu naar na je pensioendatum te verplaatsen. Dat heeft zowel voor- als nadelen:

Voordelen van jaarruimte

• Het geld dat je op een geblokkeerde pensioenrekening stort, kun je aftrekken van je belastbaar inkomen in box 1. Na je pensioendatum betaal je hier alsnog belasting over, maar waarschijnlijk tegen een lager tarief (momenteel 17,92% vs. 35,82% t/m €38.441).
• Je bespaart mogelijk jarenlang op box 3-belasting.

Nadelen van jaarruimte

• Het geld staat vast tot ongeveer je AOW-datum, tenzij je bereid bent revisierente te betalen.
• Je moet met het geld dat vrijkomt een periodieke uitkering aankopen.
• Belastingregels kunnen in de tussentijd veranderen.

Hoe benut je je jaarruimte optimaal?

Daar is geen eenduidig antwoord op te geven. Veel hangt af van je persoonlijke omstandigheden.

De grootste voordelen van jaarruimte benutten zijn het verplaatsen van inkomen naar een hopelijk lager belastingtarief en het besparen op box 3-belasting wanneer je boven het heffingsvrij vermogen zit.

Met de huidige belastingregels betaal je na je AOW-datum 17,92% box 1-belasting in de eerste schijf. Daarom is het meestal verstandig om in elk geval pensioeninkomen op te bouwen tot maximaal €38.441. Dat bedrag is inclusief AOW en eventuele andere inkomsten.

Bij een pensioeninkomen boven €38.441 zijn de belastingvoordelen beperkter. Dan spelen je persoonlijke omstandigheden een grotere rol, zoals in welke box 1-schijf je huidige inkomen valt, of je boven het heffingsvrij vermogen in box 3 zit en hoeveel waarde je hecht aan flexibiliteit.

Hoeveel moet je dan inleggen?

Concreet wil je weten hoeveel pensioeninkomen je ongeveer nodig hebt, welk eindbedrag daarbij hoort en hoeveel je tot je pensioendatum jaarlijks moet inleggen om op dat bedrag uit te komen.

We kunnen een conservatieve schatting van het benodigde eindkapitaal FV berekenen door de looptijd te vermenigvuldigen met het deel van het inkomen waar we zelf voor moeten zorgen:

Vervolgens berekenen we de benodigde maandelijkse inleg als een annuïteit. Daarbij is de looptijd n gelijk aan het aantal jaren tot je pensioendatum, gebruiken we de huidige waarde PV van je pensioenpot als startpunt en nemen we het verwachte jaarlijkse rendement op je beleggingen r als rente.

Je kunt dit uitrekenen met een rekenmachine of spreadsheet en de PMT-functie gebruiken, maar de tool hieronder maakt het eenvoudiger.

Zo zie je snel of je op schema zit, extra moet inleggen of mogelijk al meer spaart dan nodig is.

Berekenen maandelijkse inleg pensioenrekening

De informatie op deze site is mijn persoonlijke mening, geen financieel advies. Je blijft zelf verantwoordelijk voor je eigen keuzes.

If your composer.json requires a specific PHP version, this can result in an error like this even when the required PHP version is installed:

- Root composer.json requires php >=8.4 but your php version (8.3.24) does not satisfy that requirement.

The issue is that the composer package in the Alpine Linux Package Repository depends on a hard-coded PHP version. The APKBUILD file creates /usr/bin/composer as a shell wrapper that calls that specific PHP binary instead of the one from /usr/bin/env php.

$ head /usr/bin/composer
#!/bin/sh

/usr/bin/php83 /usr/bin/composer.phar "$@"

You can confirm which PHP binary Composer is using by running composer --version. It prints both the Composer version and the PHP version behind it:

$ composer --version
Composer version 2.8.10 2025-07-10 19:08:33
PHP version 8.3.24 (/usr/bin/php83)

How to fix Composer to your desired PHP version

Once you know Composer is using the wrong PHP binary, the fix is straightforward. You can either adjust the /usr/bin/composer wrapper or skip the Alpine package and install Composer manually.

Point the wrapper at your desired PHP version

One option is to use sed to change the PHP binary used by /usr/bin/composer, so it runs whatever /usr/bin/env php resolves to.

$ sudo sed -i 's/php83/env php/g' /usr/bin/composer
$ composer --version
Composer version 2.8.10 2025-07-10 19:08:33
PHP version 8.4.11 (/usr/bin/php)

Install Composer manually

Another option is to skip the package from the Alpine Package Repository and install Composer yourself using the official installation instructions.

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'dac665fdc30fdd8ec78b38b9800061b4150413ff2e3b6f88543c636f7cd84f6db9189d43a81e5503cda447da73c7e5b6') { echo 'Installer verified'.PHP_EOL; } else { echo 'Installer corrupt'.PHP_EOL; unlink('composer-setup.php'); exit(1); }"
php composer-setup.php
php -r "unlink('composer-setup.php');"
sudo mv composer.phar /usr/bin/composer

After that, composer --version should show Composer running with the expected PHP version:

$ composer --version
Composer version 2.8.11 2025-08-21 11:29:39
PHP version 8.4.11 (/usr/bin/php)

With Composer using the correct PHP binary, Alpine Linux builds can use the intended PHP version without failing on a platform requirement mismatch.

The methods I tested were scandir, readdir, glob, and DirectoryIterator.

As expected, runtime grows linearly with the number of directory entries.

Sorting accounts for a noticeable share of that runtime. scandir("", SCANDIR_SORT_NONE) and glob("*", GLOB_NOSORT") are both at least 10-30% faster than their sorted versions, which are the default.

scandir("", SCANDIR_SORT_NONE) is consistently the fastest option, with readdir usually coming in second.

DirectoryIterator is the slowest option for directories with fewer than 2000 files. Its relative performance improves as the directory grows, until it is about as fast as readdir and scandir for directories with 10000 files.

Below are the raw benchmark results and the code I used. Times are in ms and calculated as the average across 100 iterations.

Benchmark results

Benchmark code

<?php
namespace D;
class DirectoryReader
{
    public function __construct(
        protected string $directory,
    ) {
    }
    public function iterator($flags = 0)
    {
        $results = array();
        foreach (new \DirectoryIterator($this->directory) as $fileInfo) {
            $results[] = $fileInfo;
        }
        return $results;
    }
    public function readdir($flags = 0)
    {
        $results = array();
        if ($handle = opendir($this->directory)) {
            while (false !== ($filename = readdir($handle))) {
                $results[] = $filename;
            }
            closedir($handle);
        }
        return $results;
    }
    public function scandir($flags = 0)
    {
        return scandir($this->directory, $flags);
    }
    public function glob($flags = 0)
    {
        return glob($this->directory . '/*', $flags);
    }
}
if (empty($argv[1])) {
    echo "Usage: php " . basename(__FILE__) . " <directory>\n";
    exit(1);
}
$directory = $argv[1];
if (is_dir($directory)) {
    echo "Directory exists already\n";
    exit(1);
}
mkdir($directory, 0755);
$reader = new DirectoryReader($directory);
$n_iterations = 100;
$step_size = 10;
$tests = [
    ['iterator', 0],
    ['readdir', 0],
    ['scandir', 0],
    ['scandir', SCANDIR_SORT_NONE],
    ['glob', 0],
    ['glob', GLOB_NOSORT],
];
echo "files\t" . join("\t", array_map(function ($t) {
    $name = $t[0];
    if ($t[1]) {
        $name .= ' unsorted';
    }
    return $name;
}, $tests)) . "\n";
for ($n = 1; $n <= 10000; $n *= 10) {
    for ($f = (int) ($n / 10); $f <= $n; $f++) {
        touch("{$directory}/{$f}.txt");
    }
    $line = "{$n}\t";
    foreach ($tests as [$method, $flags]) {
        $start = microtime(true);
        for ($i = 0; $i < $n_iterations; $i++) {
            $reader->{$method}($flags);
        }
        $end = microtime(true);
        $time_per_it = sprintf('%.3f', ($end - $start) / $n_iterations * 1000);
        $line .= "$time_per_it\t";
    }
    $line .= "\n";
    echo $line;
}

This post is about a standalone version of Koko Analytics. It is currently functional and we are using it internally, but we chose not to open-source it for now.

The year is 2025 and I once again find myself building an open-source, self-hostable, privacy-friendly website analytics product.

By now I am starting to worry if I will ever be able to leave this topic alone. I mean, it was quite the rage back in 2018 but surely there are more than enough good solutions available now, well over 6 years later?

The one thing I have going for me is that I am not actually starting from scratch. Instead, I am porting over Koko Analytics to a standalone version in modern PHP.

The WordPress plugin version is currently in active use on more than 50.000 sites according to the statistics on WordPress.org. Over the years, I have received several requests for a standalone version for being able to track non-WordPress sites. Having been there when I was initially involved with Fathom, I never really wanted to go there again.

However, a couple of weeks ago I found myself itching to get it done, rolled up my sleeves and started the work.

Introducing Koko Analytics Standalone

I haven’t really decided whether I want to recycle the Koko Analytics brand name or name it differently, but let’s just roll with what we got for now.

You can follow the project on GitHub here: github.com/koko-analytics/koko-analytics.

Project goals

Goals for the project are to have a PHP based solution that uses a minimal amount of resources and can run on a wide range of hosting options.

You can use either MySQL, PostgreSQL or SQLite as the database backend. You may wonder how this will possibly scale or why we’re not choosing Clickhouse or DuckDB for the database. The answer is that Koko Analytics doesn’t want to force you on certain hardware or spinning up a whole new database just for some metrics. By making some choices, we can make a traditional OLTP database perform really well:

• Daily granularity.
• Writing data to an temporary buffer file, then periodically aggregating this and only then persisting to the database (in bulk).
• Limiting the amount of metrics that Koko Analytics tracks: we think visitors, pageviews, referral traffic and custom events are most important for our target audience.

Open-source licensing

The application itself is licensed under the AGPL license.

To avoid issues with AGPL virality, the tracking snippet (which you include on the sites you would like to track and allows the project to track pages served from cache) is MIT licensed.

This mirrors the licensing used by established alternatives like Matomo and Plausible.

Where we at?

Koko Analytics Standalone is functional already, but I still expect some things to change over the next few months.

We are about to start dogfooding it and hope to release a stable version some time during the second or third quarter of 2025.

The first few searches led me to SQLite’s .dump command^2, which dumps the entire database (including table structure and indices) to a text file. This approach requires you to manually edit out the differences between SQLite and MySQL in SQL syntax, but this seemed a bit tedious to me. Surely there must be a better way, especially when using Doctrine?

In the end I came up with a reasonably short bash script which successfully creates the MySQL database structure and copies over all data from the SQLite database with minimal downtime. In this post I’ll walk you through the script, so that you can hopefully modify and use it for your own needs.

Setting up the bash script

First we’ll create a new file, make sure it’s executed using bash and set a few flags.

#!/usr/bin env bash

set -e
set -o pipefail

• set -e: The set -e option instructs bash to immediately exit if any command has a non-zero exit status.
• set -o pipefail: This setting prevents errors in a pipeline from being masked by later successful commands. If any command in a pipeline fails, that return code will be used as the return code of the whole pipeline.

Connecting to the MySQL server

We want our application to keep using the SQLite database until we run this script. So we start out by writing our updated database connection string to the .env.local file.

echo 'DATABASE_URL="mysql://user:password@host/database_name"' >> .env.local

Note that your DATABASE_URL may require a serverVersion and charset argument^4, but I left that out for simplicity reasons.

Creating the new database

We can use the commands from the Doctrine Symfony bundle to create our (empty) database. This also ensures our database connection string is working before we proceed.

echo "-- Setting up new MySQL database"
bin/console doctrine:database:create

Creating database tables and indices

Now, instead of converting our SQLite database structure to MySQL we can simply have Doctrine inspect our current PHP models (“entities”) and create the schema from that.

echo "-- Creating table structure"
bin/console doctrine:schema:update --force

We should now have our database in MySQL with a bunch of empty tables in it. Let’s make sure by running doctrine:schema:validate.

echo "-- Validating schema"
bin/console doctrine:schema:validate

A nice side effect of creating the database structure from the current PHP models is that we can remove any previously used Doctrine migrations after we’re done migrating from SQLite to MySQL, effectively starting from a clean slate.

Migrating the data

OK, now the important part. Copying over all data from SQLite to our new MySQL database.

SQLite has an option for changing output formats^3, with one of them being insert mode. This output mode will output the textual result of any SELECT queries you do as INSERT queries. Insert mode can be used to generate text that can later be used to input data into a different database.

One caveat is that we have to manually specify our columns in the right order in our SELECT queries, as the order of columns in SQLite can differ from the order of attributes in our PHP models.

echo "-- Dumping current data"
rm -f var/data-dump.sql || true # Remove any leftovers from previous (attempted) runs
sqlite3 db.sqlite -cmd ".mode insert users" 'SELECT id, email, password, name FROM users;' >> var/data-dump.sql
sqlite3 db.sqlite -cmd ".mode insert payments" 'SELECT id, amount FROM payments;' >> var/data-dump.sql
# Repeat for all your database tables

We should now have a text file called data-dump.sql which contains our production data as `INSERT queries. We can simply execute this on our MySQL database and be done with it!

echo "-- Importing data"
mysql database_name < var/data-dump.sql

At this point there is just one thing left that needs to be done, and that is removing the old DATABASE_URL line from .env.local and confirming that everything went well.

Of course your process may look slightly different, but I hope this gives you some ideas on how to tackle this problem in a mostly automated way.

[^1]: Yes, I have no qualms running SQLite in production for some of my projects. Why does SQLite in production have such a bad rep?

This post walks through that C++ development setup: Sublime Text 4 with clangd, compiler flags, clang-tidy, clang-format, and perf.

Editor: Sublime Text

The two most popular options right now are probably VSCode and CLion, yet I found neither of them performant or reliable enough for my taste. Instead, I use Sublime Text 4 in combination with its Language Server Protocol implementation and Clangd.

Why Sublime?

• It’s an order of magnitude faster than both CLion and VSCode.
• It doesn’t suffer from random crashes on large projects.
• It’s easy to configure by modifying JSON config files.
• It works without hours of configuration. Install LSP and LSP-Clangd through Package Control and you have a powerful editor ready to go.
• It’s much more resource efficient than the alternatives. I can have a large C++ project open while it consumes less than 600 MB of RAM and the CPU sits idle.

The main drawback is that it’s not open source. Still, I like how a small team from Australia can build a small but profitable business around a code editor.

The community for plugins is not as vibrant or active as it once was, but everything I need is there.

Configuring Clangd

Clangd works with Sublime Text through LSP-clangd out of the box, but a few settings are worth configuring.

First, enable background indexing explicitly.

1. Go to Preferences > Package Settings > LSP > Servers > clangd.
2. Ensure initializationOptions["clangd"]["background-index"] is set to true:

{
   "initializationOptions":{
      "clangd.background-index":true
   }
}

To let Clangd know how to build your project, you can use several methods:

• A .clangd YAML file in your project root containing a CompileFlags key. CompileFlags: Add: [ -std=c++20, -Wall, -Wextra, -Wconversion ]
• A compile_flags.txt file containing one flag per line. -std=c++20 -Wall -Wextra -Wconversion
• A compile_commands.json file. You can have this file generated by CMake by setting the CMAKE_EXPORT_COMPILE_COMMANDS environment variable.

Compiler flags

My workstation runs Debian, so I tend to compile the C and C++ projects I work on using whatever version of GCC and Clang is in the official package repositories.

Currently, this means GCC 12 and Clang 14, both of which have near-complete support for -std=c++20 ^1.

When a newer compiler is needed, there’s always building GCC from source or LLVM’s APT repositories.

Both GCC and Clang are conservative with warnings, so it is worth enabling some of them explicitly. The group of warnings from -Wall and -Wextra is what I always enable as a baseline ^3.

For compilation profiles, I tend to use three:

Development

Development mode mostly cares about fast compilation times. The LDFLAGS environment value instructs the compiler to use mold for the linking stage, which is usually an order of magnitude faster than ld.

CFLAGS="-std=c11 -Wall -Wextra -Wvla -Wformat -Wformat=2 -Wconversion -Wdouble-promotion -g"
CXXFLAGS="-std=c++20 -Wall -Wextra -Wconversion -g"
LDFLAGS="-fuse-ld=mold"

Debug

In debug mode, we want debug symbols, stack traces, and runtime checks from both Address Sanitizer and Undefined Behavior Sanitizer.

CFLAGS="-g -fsanitize=address,undefined -fno-omit-frame-pointer"
CXXFLAGS="-g -fsanitize=address,undefined -D_GLIBCXX_ASSERTIONS -fno-omit-frame-pointer"
ASAN_OPTIONS="strict_string_checks=1:strict_memcmp=1:quarantine_size_mb=512:detect_stack_use_after_return=1:check_initialization_order=1"
UBSAN_OPTIONS="print_stacktrace=1"

-D_GLIBCXX_ASSERTIONS adds runtime bound checks for C++ containers from the STL. There is also -D_FORTIFY_SOURCE=2, which adds runtime buffer overflow detection for a collection of functions from glibc, but it requires an optimization level of 1 or higher (-O1).

ASAN_OPTIONS is used to configure Address Sanitizer so it can use more memory for detecting use-after-free errors and perform some stricter checks that are disabled by default.

UBSAN_OPTIONS is used alongside -fno-omit-frame-pointer to configure Undefined Behavior Sanitizer to print a symbolized stack trace for each error report.

Release

In release mode, we want the compiler to produce the fastest code possible at the cost of longer compilation times.

CFLAGS="-O3"
CXXFLAGS="-O3"

If you don’t care about portability and want to target your specific CPU, you could add -march=native and -mtune=native.

Diagnostics: clang-tidy

Since we use Clangd as our language server, we can instruct it to emit diagnostics beyond compiler warnings through clang-tidy.

clang-tidy is disabled by default, but you can enable it by modifying the settings for the LSP-clangd plugin.

1. Go to Preferences > Package Settings > LSP > Servers > Clangd.
2. Ensure initializationOptions.clangd["clang-tidy"] is set to true

{
   "initializationOptions":{
      "clangd.clang-tidy":true,
      "clangd.background-index":true,
      "clangd.header-insertion":"iwyu",
      "clangd.completion-style":"detailed"
   }
}

3. You can configure clang-tidy by creating a .clangd YAML file in your project root. In it, you can add or remove the clang-tidy checks you want. I mostly stick to the ones from performance-* and cppcoreguidelines-*.

Diagnostics: 
    ClangTidy: 
        Add: 
        - performance-* 
        - cppcoreguidelines-* 
        Remove: 
        - cppcoreguidelines-avoid-magic-numbers

The LLVM suite also contains a run-clang-tidy command, which you can use to run a single check against your source directory:

run-clang-tidy -checks='-*,performance-unnecessary-value-param' src/

Formatter: clang-format

We can use clang-format through Sublime’s LSP-clangd plugin.

Go to Preferences > Package Settings > LSP > Settings and ensure lsp_format_on_save is set to true.

Your code style can be configured through a .clang-format YAML file in your project root.

Profiling: perf

To find performance bottlenecks, I have not come across anything that beats perf together with flamegraph.pl.

The author of flamegraph.pl has a useful post with many language-specific tips on how to create flamegraphs from a perf report.

I had spent the previous few weeks moving some friends and family back to shared hosting, which turned out to be amazing value for money. For less than $10 per month, you get Apache, MySQL LTS, PHP 8.2, 64 MB of Varnish, SSH access, and hourly backups.

With me going back to full-time employment in a few weeks, I liked the idea of having fewer systems to maintain. So I migrated all my remaining PHP applications to that same shared hosting. With this site on sourcehut pages, I could then power down all of the virtual servers I was renting.

This worked well, but I missed one capability: an easy way to run code connected to the internet. I am especially interested in this because I am playing with the idea of allowing comments on this blog by letting people email a specific address.

I decided to spin up a cheap VPS again and use it to host my various static sites. hut publish is great, but so is rsync -rav. I’ll use this post as documentation for future me, and hopefully it is useful to others in a similar boat too.

Server details

For this server, we do not need much. A single-core vCPU with 1 GB of RAM, IPv4 and IPv6 networking enabled, some storage, and Debian installed is plenty.

If your cloud provider lets you configure a firewall from their UI, allow inbound traffic only on ports 22 (SSH), 80 (HTTP), and 443 (HTTPS).

Software

Once logged in, update the base packages and install what we need.

apt update
apt upgrade
apt install vim nginx certbot python3-certbot-nginx

We could get somewhat newer versions by adding the nginx APT repository and using snap to install Certbot, but I am sticking to the Debian packaged versions here.

Configuring nginx

We’ll store our websites and configuration files in /var/www/.

Open /etc/nginx/nginx.conf and add the following line inside the http { } block:

include /var/www/nginx/*

This tells nginx to include all files in the /var/www/nginx directory, allowing us to leave the rest of this file alone.

Create that directory and, inside it, create a file called nginx.conf for global configuration across all sites.

mkdir /var/www/nginx
touch /var/www/nginx/nginx.conf

The first thing we want to do is disable the server_tokens directive so nginx stops including its version in HTTP headers.

/var/www/nginx/nginx.conf

server_tokens off;

Next, enable gzip compression and configure it properly.

/var/www/nginx/nginx.conf

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 32 4k;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

This enables gzip compression for HTML, CSS, SVG, and JS responses at a level that strikes a good balance between compute cost and compression ratio.

Responses with a Content-Length header below 1024 bytes are not compressed, since they would barely benefit from it.

To determine a good setting for gzip_buffers, use getconf to get the size of a memory page on your system.

getconf PAGESIZE

If this returns a value other than 4096, modify the gzip_buffers setting accordingly.

Serving your site

Next, create another file containing the server configuration for your static site.

/var/www/nginx/www.dannyvankooten.com

server {
    listen 80;
    listen [::]:80;
    index index.html;
    server_name www.dannyvankooten.com dannyvankooten.com;
    root /var/www/www.dannyvankooten.com;

    # Cache static assets for 1 year
    location ~* .(?:css|js|ico|txt|svg|jpg|jpeg|webp|png|csv)$ {
        expires 1y;
        add_header "Cache-Control" "public";
    }

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

Test your configuration with nginx -t. If that succeeds, reload nginx with nginx -s reload.

Uploading your site

This site uses gozer to turn Markdown into HTML files and generate an RSS feed. Uploading the site to our server is a simple matter of using rsync:

rsync -rav build/. remote-user@remote-host:/var/www/www.dannyvankooten.com

The nice thing about this is that on subsequent calls, only modified files are transferred. We could use -z to enable compression, but the gains are fairly minimal because files are sent in isolation.

Update your DNS records

Our site is ready to go live. You can preview it by adding a temporary entry to your /etc/hosts file.

123.456.789.123 www.dannyvankooten.com dannyvankooten.com

If everything looks good, update the DNS records of your domain so it has an A and AAAA record pointing to your server.

You can verify the DNS change using dig:

dig dannyvankooten.com +noall +answer -t A
dig dannyvankooten.com +noall +answer -t AAAA

Enable HTTPS

With your domain pointing to your server, it is time for the final step: enabling HTTPS on your site. We already have Certbot installed, so creating a new SSL certificate that automatically renews every 3 months is as easy as:

certbot --nginx -d dannyvankooten.com,www.dannyvankooten.com

That’s it. You can repeat the steps above for multiple sites. Unless your blog gets millions of pageviews per day, you can easily host a dozen static sites like this without making the server work hard.

Tweaks

What follows are some final tweaks. They are not strictly necessary, but they are useful.

Creating a non-root user

It is a good idea to create a non-privileged user account that requires sudo for actions that need elevated permissions.

adduser danny
adduser danny sudo
adduser danny www-data

Only allow SSH access using public key authentication

First, add your public key to $HOME/<user>/.ssh/authorized_keys.

Then open /etc/ssh/sshd_config and disable password authentication.

/etc/ssh/sshd_config

PasswordAuthentication no

Increasing the soft limit for open file descriptors

nginx defaults to 768 worker connections. We should increase our soft limit for open file descriptors to at least twice that value.

Open /etc/security/limits.conf and add the following line just before the end of the file:

/etc/security/limits.conf

www-data soft nofile 1536

Disabling or buffering access logging

Logging every request consumes both CPU and I/O cycles. You can disable it entirely by including the following directive in your configuration file.

/var/www/nginx/nginx.conf

access_log off;

Another way to reduce the impact is to enable access log buffering.

/var/www/nginx/nginx.conf

access_log /var/log/nginx/access.log combined buffer=4096 flush=1m;

This writes to the log only once the 4 kB buffer is full or a minute has passed since the last write.

Limit request body size

Since we are hosting a static website that does not accept any request data, we can change the default value for client_max_body_size to something much closer to zero.

/var/www/nginx/nginx.conf

client_max_body_size 4k;

[^1]: My two reservations are that they seem to have been somewhat less reliable in terms of uptime since they suffered a huge DDoS a while ago, and that I am unsure whether their new servers are powered by renewable energy.

[^2]: You can of course pick other distributions. A lot of tutorials online use Ubuntu, but I really enjoy Debian (which Ubuntu is based on) and its stability.