Engineering

Networking from the ground up: redundancy and latency in a Swedish cloud

Latency is physics, not magic. Running close to your users in Sweden gives an edge no amount of caching can recreate. Here's how we build the network.

Compute gets the attention, but the network decides the experience. A fast server behind a poor network feels slow. When we built Kepler, we treated the network as a first-class part of the architecture, not an afterthought.

Latency is distance

Signals don’t travel faster than physics allows. Sitting in Sweden, close to Swedish users and Swedish peering, gives a latency advantage you can’t optimize away from a distant continent. For interactive services, those saved milliseconds are the difference between “fast” and “laggy”.

Redundancy without single points of failure

  • Redundant upstream links so no single transit provider can take traffic down.
  • BGP-driven routing that reroutes automatically on failure.
  • Isolation between tenants at the network level, not just in the software on top.

A network designed for failure is the only network that holds when failure comes.

— from Kepler’s engineering principles

Proximity as a feature

Running close to users isn’t only about latency. It keeps traffic within Swedish and European jurisdiction, tying the network design to the sovereignty question. Physical proximity and legal proximity happen to point the same way.

Bygg på ett moln du faktiskt äger.

Ingen bindningstid. En körande VM innan du betalar en krona.