Dullahan

Dullahan is our own server. It counts the visits to the sites we look after, without cookies and without fingerprinting, so there's no banner to click through. It also takes their contact forms and emails each message straight to the owner, with no form service in the middle.

We wanted to know how many people read our sites without putting a cookie banner in front of them, and without handing their visits or messages to someone else's service.

It's counting this visit as you read it, and one server does the same for several sites. Leixlip Dog Grooming's booking form goes through it too.

No IP address is ever written to disk. It backs itself up every night, checks it's still running, and emails a plain summary once a week.

One compiled program and one database, on a small rented server with 2 cores and 3.7GB of memory. Only the web server in front faces the internet, on 3 ports; the program and the database listen inside the machine alone. The server never builds anything, since a build would fight the visitors for those 2 cores: the program arrives ready to run. 176 automated tests run on every change.

Each layer assumes the one outside it has already failed. Logins take keys only, never a password or the root account, and repeated failures get blocked. The program runs as its own user, fenced off from the rest of the system and capped in what it can use. The database lets nothing in without proof, its secrets sit in a file only the program can read, and security updates install themselves.

The web server in front hides the program's internal stats page, which had been open to anyone: the setup notes always said to block it, and the setup never did. It also throws away any country a request claims and passes on the one the network reports, so nobody can fake where a visit came from.

Without a cookie there's no way to follow a visitor from one day to the next, and it doesn't try: it reports average daily visitors rather than a total it would have to guess.

Every night the database is encrypted before it leaves the machine and stored with a different company. The server keeps 7 daily, 4 weekly and 3 monthly copies of its own; the off-site store prunes by a rule the server can't change, so a broken-into server can't wipe the history. Once a month a drill restores the newest backup into a scratch database, counts the rows and drops it: a backup only counts once it has been restored.

From 1 to 16 October the storage key had expired. Every night's backup was made and kept, but on the same disk as the database it was there to protect, and nothing said a word: the health check never looked at the backups' age. A script retiring an old app from the server found it, by refusing to touch anything until it could prove an off-site copy existed. The key was replaced, the 16 stranded backups uploaded and a full restore run the same day.

The first new key could read but not write. Listing worked, downloading worked and the whole restore drill passed, while every upload failed. A check that only reads will pass a key that can't take a single backup.

The code is public, under a licence that lets anyone run it on a server of their own.