After much research I came across Packeton - an open source fork of Packagist which you can run on a web server of your choosing.

This walkthrough sets Packeton up with Docker which requires the least amount of server setup.

The following how-to runs through setting it up and some hurdles I came across. It expects CLI experience and you need to be comfortable with SSH.

Where to run

You need a server or VPS for this - I opted for a cloud server from Hetzner with Ubuntu 24 running.

Server set up

Update the server applications and install caddy (which allows web traffic to docker images) and docker itself.

apt update && apt upgrade -y
apt install -y caddy
curl -fsSL https://get.docker.com | sh

DNS

Point your domain (e.g. packages.yourdomain.com) at the server's public IP

Firewall

Set up a firewall with the following inbound rules - I used the firewall built into the Hetzner control panel

Generate an app secret

This can be run on the server or your local machine - you just need a 32 character string

openssl rand -hex 32

Copy the output for use in the next step. Keep it static — it's used to encrypt SSH keys in the database.

Create your Docker compose file

I chose to keep all my Packeton-related files in /opt/packeton. Start off by making the folder & file

mkdir -p /opt/packeton
nano /opt/packeton/docker-compose.yml

This utilises a few different settings & configuration. Some points worth noting

• This include configuration for using Mailgun (we use it on the free tier) for sending the password reset emails
• This includes watchtower which will keep packeton updated

services:
  packeton:
    image: packeton/packeton:latest
    container_name: packeton
    restart: unless-stopped
    environment:
      APP_SECRET: <output from step 5>
      ADMIN_USER: admin
      ADMIN_PASSWORD: changeme
      ADMIN_EMAIL: you@yourdomain.com
      PACKAGIST_DIST_HOST: https://packages.yourdomain.com
      TRUSTED_PROXIES: 127.0.0.1
      MAILER_DSN: smtp://you%40yourdomain.com:PASSWORD@smtp.eu.mailgun.org:587
      MAILER_FROM: Your Name <you@yourdomain.com>
    ports:
      - '127.0.0.1:8080:80'
    volumes:
      - ./data:/data
  watchtower:
    image: containrrr/watchtower
    restart: unless-stopped
    environment:
      DOCKER_API_VERSION: "1.40"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --interval 86400

Configure Caddy

Caddy allows a domain name to be forwarded to a running docker container.

Replace the entire contents of /etc/caddy/Caddyfile with:

packages.yourdomain.com {
    reverse_proxy localhost:8080
}

Then reload caddy:

systemctl reload caddy

Start Packeton

cd /opt/packeton
docker compose up -d

Verify it all works

Visit https://packages.yourdomain.com and log in with the admin credentials you set.

Post-setup

Change the admin password

The ADMIN_PASSWORD env var only applies on first run. Change it via the console:

docker exec -it packeton bin/console packagist:user:manager admin --password=newpassword

Create additional admin users

docker exec -it packeton bin/console packagist:user:manager newusername --password=newpassword --admin --no-interaction

Configure GitLab OAuth

First, create a GitLab OAuth application at https://gitlab.com/-/profile/applications:

• Redirect URIs:

  https://packages.yourdomain.com/oauth2/gitlab/install
  https://packages.yourdomain.com/oauth2/gitlab/check
  

• Scopes: api, read_user, read_repository

Then create /opt/packeton/data/config.yaml:

packeton:
    integrations:
        gitlab:
            base_url: 'https://gitlab.com/'
            clone_preference: 'clone_https'
            gitlab:
                client_id: 'xxx'
                client_secret: 'xxx'

Restart Packeton to apply:

cd /opt/packeton
docker compose restart packeton

Then go to the Packeton integrations page in the UI and click Install Integration, then Connect to complete the OAuth flow.

Bonus Notes

Data

All Packeton data lives in /opt/packeton/data on the host, mapped to /data inside the container. Back this directory up — it contains the database, config, and any stored artifacts.

Ongoing maintenance

Watchtower checks for a new packeton/packeton:latest image daily and recreates the container automatically. No action needed.

Monitor the Packeton releases for any updates that require manual migration steps before they land.

Read time: 4 mins

Tags:

https://gitbutler.com/

Read time: 1 mins

https://danielabaron.me/blog/css-refactoring-with-an-ai-safety-net/

Read time: 1 mins

This is exactly when you need fresh eyes. At Liquid Light, that's what the BLAT test is for.

BLAT is a timeboxed, no-holds-barred review where everyone gets a go at one of our nearly finished websites. Each person gets an hour to click around, prod things, and use the site as a real person would. The goal is to find holes.

It might be a personal preference. It might be a niggle. It might be the tiniest of nitpicks. Doesn't matter. It goes on the list.

The project manager then reviews the list and decides what to action, postpone, or drop. It's not personal. It's priorities.

Things that tend to come up:

• Spacing between two particular elements
• Accessibility of a link in a specific context
• Unexpected (or missing) behaviour from an interaction
• Image sizes affecting performance
• Print styles nobody tested
• Odd flows between pages
• Future website improvements or additions

Anything goes, as long as the note includes:

• A link
• A description
• A screenshot where possible

Side note: No, BLAT doesn't actually stand for anything. We all know what it means (although out of all the recommendations from Claude my favourite was Brutally Look At Things )

Read time: 1 mins

Tags:

Eventually, my DDEV got confused and started producing 404s. With mixed version images & config, I wanted to remove everything and start again.

With the help of Claude, I created a bash script which will run through and delete every DDEV related configuration.

Completely remove DDEV

Steps

1. Copy the contents or download the zip
2. Make the file executeable - cd path/to/file and chmod +x ./remove-ddev.sh
3. Run the script ./remove-ddev.sh - there is --help and --dry-run flags available

Read time: 1 mins

Tags:

https://github.com/remorses/playwriter

Read time: 1 mins

Life

Plenty of goings-on with the Street family this year. Ruby, our youngest, started school which meant another shift in routines and schedules. Alfie moved up to Beavers and Ruby started Squirrels, which now means I'm the only one of our family to not be currently invested in a scouting section.

Alfie has become a classic "kid" and discovered Minecraft. He'd been talking about it at school and we finally gave in and bought a copy for the XBOX. I've also enjoyed playing it, trying to actually build things and thinking about layout (although it's still enjoyable to build a tower of TNT and blog it up).

There were some small home improvements - I redecorated the garden office and painted the "TV corner" of the lounge with matching bookcases. The biggest change was the demolition of the back garden patio and building of a deck - carried out by my dad and me.

To finish off the year, our car decided to give us a Christmas present of breaking. We couldn't get it booked in until the 5th Jan, however my mother-in-law leant us her car for the festive period which meant Christmas was saved.

Trip and Holidays

For our main holiday this year we took the kids to Disneyland Paris. It was a first for me - going on the channel tunnel and driving on foreign soil in my own car. Disneyland was hectic and expensive and fun and chaos. We went with my wife's family which did mean we had the opportunity to leave the kids with each other and head off to the big rides.

Little trips included taking Ruby to London for the first time, a boat trip out to the Rampion Wind Farm and a visit to Brooklands Museum in Weybridge.

We also spent a week in a static caravan in the New Forest - it was a classic "caravan park" style holiday, with on-site swimming, golf and evening entertainment. We sprinkled in some day trips to Paultons Park and a miniature steam railway. We also found a pub round the corner with an incredible outdoor play area for the kids (while Chilly and I kicked back with a book and a beer).

My attendance to gigs sky-rocketed this year as I got the taste for it last year. This year saw a few shows with the kids along with seeing OneRepublic (my first trip to the 02 since it was the millennium dome), Nizlopi (a birthday present), Self Esteem and it seems I can't go through a year without seeing Bastille. The last gig of the year was with my mum and family to see Stereophonics at the 02 again.

Stats Analysis

Visit the stats page.

Cycling was a big part this year - recording the highest ever number of miles done in a year since I started recording. A big part of this was the turbo trainer I purchased at the end of last year, with just 85 miles separating virtual and real-world bike rides (and I rode more virtual miles then I did on an eBike)!

I also hit a few big rides this year, doing the London to Brighton bike ride (for the third time), a 65 mile bike ride in August and 70 miles around the Isel of Wight in October. I was pretty happy that I was able to pull these out the bag without much concious training. It seems cycling to and from work combined with the turbo proved to be a pretty effective training plan. I'd like to hit 4000 miles again in 2026.

My Geocaching suffered this year - only finding 2 at the beginning of the year. I need to get some caching days booked in in 2026 to get those numbers back up. I feel like 75 Geocaches is a good target.

Everything else, such as blog posts, steps and music streams stayed steady.

Read time: 3 mins

Tags:

https://ohmyposh.dev/

Read time: 1 mins

Makefile includes

The thing that initially had me scratching my head was wanting to share commands between sites. A lot of our sites follow the same patterns and need identical Makefile commands - seemed daft to copy-paste the same stuff everywhere when we could have one central file doing the heavy lifting.

I spent ages trawling through Stack Overflow and various forums, but here's the thing - because our Makefiles essentially just contain bash commands (rather than actually "making" anything in the traditional sense), there was loads of conflicting advice that didn't quite fit our use case. Eventually, I gave up being stubborn and asked AI, which promptly gave me exactly what I needed:

-include ./path/to/file.mk

Word of warning: That hyphen - before include is doing important work - it prevents Make from throwing a tantrum if the file happens to be missing (which can happen if it's installed via a dependency that hasn't been pulled yet).

.mk is the recognised file extension for Makefiles that aren't called Makefile - bit of trivia for you there.

When you're including a file with commands, you can overwrite them in your local Makefile if you need project-specific tweaks. Make will give you a gentle warning about this, but it's just letting you know something's been overridden - nothing to worry about.

Variables

Your central Makefile might need some paths or other bits that vary between projects. You can handle this much like bash - define variables without a prefix, use them with one:

SITE_PATH_PRODUCTION := ~/www/current

-include ./path/to/file.mk

Then reference that variable in your shared Makefile:

## Pull the full database from production
db-full-pull-production:
	ssh $(SSH_HOST) \
		"$(SITE_PATH_PRODUCTION)/vendor/bin/typo3 database:export ...

As a bit of a safety net, you can set defaults at the top of your shared makefile too:

SITE_PATH_PRODUCTION ?= ~/www/current

That way things won't explode if someone forgets to set a variable.

.PHONY Commands

All our commands are basically bash scripts masquerading as Make targets. This works fine until you accidentally create a folder that matches one of your command names.

For example, if you've got make config but also have a config/ folder hanging about, running make config will target the folder instead of your command. Bit annoying when you're expecting it to do something entirely different.

You can tell Make which commands are .PHONY (i.e., they don't correspond to actual files), but since all of ours are just bash commands in disguise, we take the sledgehammer approach and mark everything as phony:

.PHONY: *

Help block

Here's something that'll save you from accidentally running the wrong command: by default, running make with no target executes whatever's first in the file. This could be anything - a rebuild command, a deployment script, something that downloads half the internet. Not ideal.

We stick a help generator at the top of our Makefiles that serves double duty - it shows available commands and acts as a safety net:

help:
	@echo "\033[0;33mAvailable targets\033[0m"
	@echo "\033[0;33m-----------------\033[0m"
	@awk '/^[[:alnum:]_-]+:/ { \
		helpMessage = match(lastLine, /^## (.*)/); \
		if (helpMessage) { \
			helpCommand = substr($$1, 0, index($$1, ":")-1); \
			helpMessage = substr(lastLine, RSTART + 3, RLENGTH); \
			printf "%-25s %s\n", helpCommand, helpMessage; \
		} \
	} \
	{ lastLine = $$0 }' $(MAKEFILE_LIST)

Any command with a double hash comment (##) above it gets picked up and displayed in the help. Simple but effective - and it means accidentally running make just shows you what's available rather than doing something potentially destructive.

Certainly not the most groundbreaking setup, but it's made managing our various projects much less of a faff. If you've got a different approach or improvements to suggest, I'd love to hear about them.

Read time: 3 mins

Tags:

• The slides (linked below)
• The info and notes below
• Pens and paper for your teams

The quiz can be played in teams or individually - I'll leave it to you to work it out. There doesn't need to be a "quiz master" per say, just someone who can click "next slide please".

Slides

Get the quiz slides

The slides are on Google, however if you need them in a different format, let me know.

Quiz Information

This quiz is 5 rounds with 7 questions in most rounds (except the picture round, which has 11).

Most answers are 2 points per correct answer (allowing single points to be rewarded where deserved).

When running the quiz I ask that phones are put away - more for politeness than fear of cheating. I also make it clear that the answers in the quiz are always right - even if they are not. This way it is fair and should hopefully avoid arguments.

Round explanations

1.Battlenips (and other parts)

Identify the grid reference where the specified body part of object is.

2. Music

Fill in the missing lines of the song. Single points can be awarded if the teams are nearly right.

3. Film

Identify the films featuring my face

4. Picture

I got my 7 & 4 year-olds to draw things from the garden and park. What are they?

5. 2025

7 questions about what happened in 2025.

The end

Let me know if you use this quiz and how you get on - was it to easy? to hard? to complicated?

Read time: 1 mins

Tags:

Since we're only using RustFS to cache build assets, we can safely bin the old ones without worry. We settled on a 14-day cut-off - bit arbitrary really, but it works. The worst that can happen is the application won't deploy without them, which means you'll have to re-run the entire pipeline if you're trying to deploy something that hasn't been built in a fortnight. Not ideal, but hardly the end of the world.

RustFS is comapitble with mc - the MinIo command so I started looking there but then ended up with a default linux command

find /data/rustfs0/XXX -mindepth 1 -type f -mtime +14 | xargs rm

Once you have the command and are happy with it, add it to a crontab to run once a night.

To edit the crontab, run crontab -e and place the following at the bottom (this will run a 10pm every evening)

0 22 * * * find /data/rustfs0/gitlab-ci -mindepth 1 -type f -mtime +14 | xargs rm

Read time: 1 mins

Tags:

If your website is sending emails at all (even to you for contact form responses), it is worth considering spending time to verify that you own the domain and you are allowed to send emails from it. Word of warning: this isn't going to be the most thrilling post, but it's one of those things that'll save you a proper headache down the line when your carefully crafted emails end up in spam folders.

SPF, DKIM and DMARC records all help with this and below each one is explained as to what it does and how you set it up. I'll be honest - I found these records a bit bewildering at first, but once you've set them up a few times they become second nature. Think of them as your email's passport - proving you are who you say you are.

Testing Tools

Before we dive in, bookmark this:

• mail-tester - Send an email to get real-world data (proper useful, this one - gives you a score out of 10 and tells you exactly what's wrong)

SPF Record

• SPF Records explained
• SPF Tester

SPF (Sender Policy Framework) is basically your domain saying "these are the mail servers allowed to send email on my behalf". Without it, anyone could pretend to send emails from your domain - which is as dodgy as it sounds.

This is how the most common SPF record looks:

v=spf1 a mx -all

Breaking this down: v=spf1 is the version, a and mx mean your domain's A record and MX records are allowed to send mail, and -all means "reject anything else". That last bit is important - it's like saying "if it's not on the list, it's not coming in".

As an example, if your client uses Google Workspace, you'll need to add include:_spf.google.com. Same goes for services like Mailchimp:

v=spf1 a mx include:_spf.google.com include:mailchimpapp.net -all

Most services which send emails on your behalf will have some documentation detailing what SPF Record you need.

DMARC Record

• DMARC wizard (weirdly satisfying to use, this one)

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do if your SPF or DKIM checks fail. It also sends you reports so you can see if someone's trying to spoof your domain - certainly interesting to see what's being attempted in the wild.

A good standard is something like the following:

• Target: _dmarc.@
• Type: TXT
• Record:

v=DMARC1; p=quarantine; rua=mailto:email@example.com; aspf=r;

Or if you want to be a bit stricter:

v=DMARC1; p=quarantine; pct=100; aspf=s;

The p=quarantine means "if this looks dodgy, put it in spam rather than rejecting it outright". You can use p=reject if you're feeling confident, but I'd recommend starting with quarantine until you're sure everything's configured properly.

DKIM Record

This can only be configured if the service you are using emits a DKIM signature or similar. CMS's, like TYPO3, does not include a DKIM header so make sure you know before you start.

DKIM (DomainKeys Identified Mail) adds a digital signature to your emails - like a wax seal on a letter proving it hasn't been tampered with. Your email service provider will generate the keys for you.

Check with the system for instructions - each provider does it slightly differently and they'll give you the specific DNS records to add.

BIMI

Right, this one's a bit fancy and optional, but if you want your logo to appear next to your emails in supported clients (Gmail, Yahoo, etc.), BIMI is what you need.

• BIMI Generator & Inspector
• Use a 512px square SVG for the image (the Favicon SVG is perfect for this)
• We don't generally have a VMC (Verified Mark Certificate) available - these cost proper money and are only really worth it for big brands

Example BIMI:

• Target: default._bimi.@
• Type: TXT
• Record: v=BIMI1; l=https://link/to/svg;

Final Thoughts

I should really test email deliverability more systematically on projects, but these DNS records are a good foundation. Set them up early and you'll avoid that awkward conversation later where the client asks why their contact form emails keep ending up in spam.

If anyone's got experience with VMC certificates for BIMI or has tips on DKIM implementation in TYPO3, I'd love to hear your thoughts. There's still a lot of nuance to email deliverability that catches me out occasionally.

Read time: 3 mins

Tags:

I've written about MinIO before - speeding up Gitlab CI and caching Gitlab assets - and it's been great as a self-hosted S3 alternative. But I'm always up for trying new toys, especially when they promise improvements.

Turns out RustFS has been benchmarked against MinIO and is faster across the board. That was enough to convince me to give it a go.

Server setup

We're running RustFS on a dedicated Ubuntu server with Hetzner (our go-to VPS provider). I went with an Intel CX32:

• 4 vCPU
• 8 GB RAM
• 80 GB Disk

Note: You'll need an external IPv4 address - rustfs.com only supports IPv4 for setup.

Installation

Once your VPS is up, installation is pleasantly straightforward. First, make sure you've got unzip:

apt update && apt upgrade
apt install zip unzip

Then grab the install script:

curl -O https://rustfs.com/install_rustfs.sh && bash install_rustfs.sh

Follow the CLI prompts and you're sorted.

Setup

After installation, hit up the web interface at http://[server-ip]:9000. Default credentials are rustfsadmin for both username and password.

Change that immediately by editing:

/etc/default/rustfs

Once logged in, you can create buckets and extra users or access keys - which is what I've been using for Gitlab CI.

Read time: 1 mins

Tags:

Sleep is one of the few things we pretend to do to actually do it

Close your eyes, lie down and pretend until you actually drift off

Cleaning your teeth is the only time we clean our skeleton

You don't see a skull with a beard, do you?

Why do we have round lenses on cameras, but rectangle sensors and photos?

Surely the lens is capturing more of the photo then we ever see?

Have you ever walked in a "space" of the earth that no human has before?

Doesn't matter what is actually under your feet, but has a human ever been to that lat/long before?

Read time: 1 mins

Tags:

GitLab doesn't make this easy. There's no big "Change Domain" button, and if you're using package registries, you're in for a proper adventure and need to get your team on board.

Steps we'll cover

1. Add the new domain alongside the old one (30 mins)
2. Switch the primary domain (30 mins + testing time)
3. Set up redirects (1 hour)
4. Clean up (10 mins)
5. Deal with package registry authentication (varies, but budget a day if you're unlucky)

In the examples below, I'm using:

• old.gitlab-company.org - the old domain
• new.gitlab-instance.com - where we're migrating to

Word of warning: if you're using GitLab as a package registry (NPM, Docker, whatever), prepare yourself. This is where most of the pain lives.

Add the second domain

The first step is to allow GitLab to accept connections from the new domain. This lets you test everything works before you commit to the switch - you'll be able to access GitLab on both domains simultaneously, which is brilliant for testing.

Once you point the domain record to your GitLab instance, you'll find you can navigate to it and click around - GitLab doesn't try to redirect you back to the primary domain. You may, however, encounter an SSL error. This can be resolved by adding the secondary domain to Let's Encrypt and allowing GitLab to generate an SSL certificate for it.

Edit the GitLab config file /etc/gitlab/gitlab.rb and add the following:

letsencrypt['alt_names'] = ['new.gitlab-instance.com', 'registry.new.gitlab-instance.com']

Note: If you have a container registry or any other subdomains, these will need to be added too.

Reconfigure the instance:

gitlab-ctl reconfigure

This will generate the SSL certificates while reconfiguring and will error if there are any subdomains it can't generate certificates for.

I'd encourage using this new domain for a day or two (we left it longer, because paranoia, but two days is probably fine if you're braver than us). Navigate around, clone some projects, generally kick the tyres to make sure there are no basic issues.

Switch the instance domain

The next step is to change the instance URL. This won't force a redirect but will mean GitLab responds with the new URL for API and internal requests. You'll still be able to navigate on the old URL, clone projects, and so on.

Edit the GitLab config file /etc/gitlab/gitlab.rb and update the external_url and letsencrypt['alt_names']:

external_url 'https://new.gitlab-instance.com'
registry_external_url 'https://registry.new.gitlab-instance.com'
letsencrypt['alt_names'] = ['old.gitlab-company.org', 'registry.old.gitlab-company.org']

Reconfigure the GitLab instance:

gitlab-ctl reconfigure

I'd advise using this new domain with GitLab for a week or two. It won't redirect you to the new domain, but clone URLs and other requests will use the new domain.

Package registries

This is where you'll begin to see issues. If you use your GitLab instance as a Docker or package registry, you'll need to ensure you've authenticated with all your package managers using the new domain.

If you use GitLab as your NPM registry, this will be the biggest pain. Every project needs re-authenticating with the new domain, and npm will absolutely refuse to install packages until you do. It'll update your package-lock.json happily enough, then leave you staring at authentication errors wondering what you've done to deserve this.

If you use something like Renovate, this can help with migration, but it takes a lot of planning (and a lot of head scratching). Weirdly, dealing with this across multiple projects was more time-consuming than the actual GitLab migration.

Get in touch if you need advice with your specific setup - I spent enough time Googling obscure package registry authentication that I might actually be able to help.

Redirect to the new domain

With the new instance battle-tested and working, it's time to set up a redirect. You may choose to do this when you switch the instance domain above, but I left it a week or two in case we needed to fall back to the old domain (which, to be fair, we didn't, but better safe than sorry).

Edit the GitLab config file /etc/gitlab/gitlab.rb and add the option to allow custom nginx configuration:

nginx['custom_nginx_config'] = 'include /etc/gitlab/nginx-extra.conf;'

Next, create a config file - /etc/gitlab/nginx-extra.conf. I chose not to redirect the registry, but if you need to, there's an example in Running GitLab simultaneously on two domains.

Before you reconfigure the GitLab instance, ensure the SSL certificates are in the location specified below:

# web
server {
  listen 443 ssl http2;
  server_name old.gitlab-company.org;
  server_tokens off;

  ssl_certificate /etc/gitlab/ssl/old.gitlab-company.org.crt;
  ssl_certificate_key /etc/gitlab/ssl/old.gitlab-company.org.key;
  ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';
  ssl_protocols TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_session_cache builtin:1000 shared:SSL:10m;
  ssl_session_timeout 5m;

  return 301 https://new.gitlab-instance.com$request_uri;
}

Reconfigure the GitLab instance:

gitlab-ctl reconfigure

Clean-up

After some time (we left it a month, but we're cautious like that), you can tidy things up:

• Delete /etc/gitlab/nginx-extra.conf
• Remove nginx['custom_nginx_config'] from /etc/gitlab/gitlab.rb
• Remove any references to the old domain in /etc/gitlab/gitlab.rb
• Delete any references from your browser history

The whole migration took us about three weeks from start to finish, mostly because we were being cautious and dealing with the package registry nightmare. If you're not using registries heavily, you could probably knock this out in a few days.

There's still a lot I don't know about GitLab's internals (it's a proper beast of a system), but this process worked well for us. If you hit any snags or your setup is a bit different, get in touch - I might be able to point you in the right direction.

Read time: 4 mins

Tags: