LithusBook a 30-minute call →

Two decades of running production software. Ten years of stripping out what it does not need.

We started in 2007 building and hosting software for organisations across the UK and Europe, including projects for Twitter, the British Royal Navy, and renewable energy companies operating across developing markets. Along the way, we lived through every generation of cloud infrastructure, and built Lithus to fix where it ended up.

Every layer in the modern cloud solved a problem at the time.

Over nearly two decades of running client workloads, we watched hardware become reliable, open-source orchestration mature, and virtualisation layers turn from a necessity into an expensive middleman.

2007 – 2010Physical servers & early AWS

When getting a server quickly was the hard part.

We started in 2007 as a software development company. When we delivered software for small and mid-sized businesses, the next question was always where to run it, so we took on their hosting too. At the time, getting a physical Linux server racked took weeks, and each machine was a one-off server configured by hand over SSH and deployed via Subversion and SCP.

When Amazon launched EC2, we were there at the start, and we later used platforms like Heroku when Git-push deployments first appeared. Single EC2 instances were fast to provision, and Heroku felt effortless until a client needed to scale and saw the bill. High-availability load balancing and zero-downtime deployments were still exotic practices reserved for the largest companies, while the cloud solved the immediate problem of getting compute quickly.

2011 – 2015Configuration management to Kubernetes 1.0

Treating servers as replaceable.

As client workloads grew, single servers were no longer enough. The industry moved toward machine images and configuration management tools like Puppet, Chef, and Ansible so a failed instance could be replaced reproducibly.

When Google open-sourced Kubernetes based on their internal Borg system, we adopted it at version 1.0 in 2015, before StatefulSets even existed. It gave us a standard way to orchestrate workloads across multiple servers, route incoming traffic, and combine the open-source tools needed for zero-downtime operation.

2016 – 2020Managed Kubernetes & cloud bill creep

Years of rising bills for the same workloads.

We moved our clients onto managed Kubernetes, primarily on Google Cloud because they had built Kubernetes and offered the strongest early support. For several years, that was a sensible default.

Over time, our clients noticed a familiar pattern: their cloud bills kept climbing year after year to run the same software. Part of that growth was data volume, and part of it was the pricing structure of managed cloud services. At the same time, teams were being pulled into proprietary cloud services even as open-source alternatives matured to the point where we could deploy and operate them reliably at scale.

2021 – PresentLithus · Dedicated bare metal

Removing the layers we no longer needed.

We stepped back and looked at the stack we were running. Kubernetes was already handling scheduling, networking, and machine failure, yet it was sitting on top of virtual machines, which sat on top of physical servers. Because virtual machines cannot rely on a single host's local disks, any workload that stored data (such as databases, queues, and analytics stores) had to use network-attached block storage, which adds cost and latency.

Meanwhile, server hardware had shifted from spinning disks to fast, reliable solid-state NVMe drives, bare metal had become much more affordable, and Kubernetes operators for stateful workloads could now handle replication, automated failover, and rebuilding a missing node without human intervention. Virtual machines were solving a problem we no longer had, so we removed them, automating bare metal first with Ansible and today declaratively from the operating system up with NixOS.

Built to survive hardware failures without waking anyone up.

Removing the hyperscaler layer works because our hardware and software stack is engineered to self-heal by default, with our engineers on-call 24/7 when human judgment is needed.

Direct on NVMe bare metal.

Your applications and data services run directly on dedicated European servers with local NVMe drives and physical network cards. Removing the hypervisor and network block storage cuts latency and gives you markedly more compute and I/O per euro.

Self-healing workloads and multi-site resilience.

If a server fails, Kubernetes reschedules application containers immediately, while stateful services replicate across separate physical machines and rebuild lost instances automatically (for example, every managed PostgreSQL cluster runs with a synchronous standby replica, or two standbys when one serves analytics). For critical systems, we architect across multiple European data centres so production continues even if an entire facility goes offline.

Reproducible from the operating system up.

Every server is built declaratively using NixOS, and every cluster runs standard upstream Kubernetes and proven open-source software. You keep full SSH root and Kubernetes admin access at all times, with no proprietary services locking your team in.

Leadership.

When you work with Lithus, you speak directly with the people responsible for your platform and your commercial agreement.

Adam Charnock

Founder & Principal Engineer · Munich, Germany

Adam leads architecture, migrations, and engineering operations at Lithus. Over nearly twenty years in the industry, his work has ranged from internal product development for Twitter and multi-terabyte hardware-testing databases for Snap Inc, to optimising Blocknative's global AWS network and designing a bare-metal alternative to their cloud stack.

Because he spent years as an application developer before focusing on infrastructure, he works closely with client teams where code and infrastructure meet. That includes message delivery guarantees, database access patterns, and isolating critical state, such as making sure a Valkey instance holding user sessions cannot be filled by background cache data.

His networking background also comes from founding and operating a licensed regional ISP in rural Portugal: working with multinational carriers to run fibre along a railway line, beaming it up a mountain to a solar-powered relay, and running BGP peering across more than 100 km².

Photo & final title to be added

Harun Mlivo

Co-founder & Commercial

Harun leads commercial operations, client onboarding, and business case planning at Lithus, working with engineering and finance leaders to benchmark cloud spend and plan predictable migrations to dedicated European infrastructure.

Placeholder profile · Harun to update with final bio copy, links, and photo

Company facts and compliance.

Straightforward governance and European data residency for due diligence and security reviews.

Entity & presence

Lithus UK Ltd (established in the United Kingdom in 2007), with German GmbH formation due in Q1 2027.

Data residency

All client workloads and backups run exclusively in European Union data centres across Germany, the Netherlands, and France.

ISO 27001

Deployed in ISO 27001-certified EU data centres (Germany, the Netherlands, and France), with Lithus's own ISO 27001 certification completing in Q1 2027.

Access & continuity

Clients hold full SSH root and Kubernetes admin access from day one, with a customisable EU subprocessor chain.

Talk directly with an engineer who runs production clusters.

  1. 1Book a 30-minute call with one of our engineers to walk through your current stack
  2. 2Optionally share a recent cloud bill so we can model your exact hardware and savings
  3. 3Receive a costed migration plan, a fixed monthly price, and a candid view on whether we are a good fit
Book a 30-minute call →

Or email contact@lithus.eu

Locked into a cloud contract right now? Ask us to check back in 3, 6, or 12 months →