Infrastructure

Amazon EC2 instances in eu-north-1, in AWS accounts we own directly rather than through a reseller. The fleet runs on ARM-based instances, which is a cost and efficiency choice rather than a security one.

Application servers, the database and supporting services run on separate instances. Storage is AWS gp3 volumes for instance and database storage, and S3 for uploaded files, backups and archives.

The platform database is MongoDB, self-hosted as a replica set on our own instances. It was migrated off MongoDB Atlas to self-hosted infrastructure in March 2026, which put the data and its backups inside our own accounts and region.

The platform's data layer also supports PostgreSQL, ScyllaDB, Cassandra and CockroachDB, so a system with a workload that calls for one of those is not forced onto the default.

Vertically first — instances are resized to the workload, and the fleet has been resized in place as demand changed. Storage volumes are expanded without a rebuild.

The database scales by adding replica set members, which also adds redundancy rather than trading it away.

Planned: horizontal auto-scaling of application servers behind a load balancer. Capacity today is provisioned deliberately rather than automatically.

The database runs as a replica set, so the loss of a single node does not lose the data or stop the service.

Every server has a machine image from the previous day, so a lost host is rebuilt from an image rather than reinstalled from scratch.

Planned: multi-availability-zone deployment for application servers, and automatic failover for the application tier. Today an application host failure is recovered by an operator rather than automatically.

The web application and its API, over HTTPS only. TLS terminates at nginx, certificates are issued by Let's Encrypt and renewed automatically, and plain HTTP is redirected rather than served.

The platform database is not reachable from the public internet and accepts connections on the internal network only.

SSH with key-based authentication on a non-standard port. Password authentication is disabled, so a guessed or leaked password is not a route in.

Administrative access goes to named accounts rather than a shared login, which is what makes an action on a server attributable to a person.

Planned. There is no web application firewall in front of the platform today, and volumetric protection is limited to what AWS provides at the network layer by default.

We would rather state that plainly than describe the platform as protected by something that is not deployed.

Amazon CloudWatch alarms across the fleet cover host and service health, with alerts routed to the people who operate the platform. Alarms fire to a person, not to a dashboard nobody is looking at.

Backup jobs report their outcome, so a backup that silently stopped running is a detectable condition rather than a discovery made during a restore.

Three separate trails. Application logs on the servers, infrastructure metrics and alarm history in CloudWatch, and the platform's own audit log of user and administrative activity in the database — that last one is described in full on the Security page.

Planned: centralised aggregation of all three into a single searchable store with defined retention. Today they are queried where they live.

There is a status page in this Trust Center, maintained manually. Automated status reporting driven by live health checks is planned rather than live, and the page says so rather than implying a feed exists.

Customers affected by an incident are contacted directly. We do not rely on a status page as the notification mechanism.