Skip to content

Infrastructure

Real machines. Real networks. Real disks.

Racks of machines, cabled back to the switch that fronts the row. Illustration.

Interlaken Cloud runs on infrastructure we operate ourselves, and we would rather name it than hide it. Under every button in the console: Firecracker microVMs, a userspace VPP dataplane, LINSTOR-replicated volumes on DRBD, managed k3s, KubeBlocks-operated databases and MinIO buckets.

Built on
  • Firecracker
  • VPP
  • LINSTOR / DRBD
  • k3s
  • KubeBlocks
  • MinIO
Get started See the platform

01 Compute

One fabric, four shapes

Isolation, boot time, console, hot attach: the four shapes stop being interchangeable the moment you pick one. Here is the whole comparison, one property at a time.

Scroll to compare 01 / 04
How the four compute shapes on Interlaken Cloud differ.
Property Virtual machinesmicroVMsContainersAutoscaling groups
Isolation Full hardware virtualization, own kernelFirecracker VM isolation, minimal device modelKernel namespaces and cgroups, shared host kernelWhatever the member type provides
Boot time A full guest bootAbout a secondAs fast as the process startsMembers boot as themselves
Reach for it when You want a long-lived server that expects to be a real machineYou want density and a cold start you can wait throughYou already have an image and the workload is statelessCapacity has to follow demand instead of a guess
Console access VNC and serial consoleSerial consoleAttached terminalPer member
Hot attach and detach Disks and NICs, while runningDisks, while runningFixed at create timeDefined by the member template
Scaling Resize and relaunchResize and relaunchResize and relaunchPolicy-driven, on a metric

“About a second” is our own figure for a Firecracker microVM booting from a prepared rootfs image on our hosts. It is not a benchmark against anyone else, and your image decides most of it.

Open Compute

02 Networking

A dataplane in userspace

Every packet on Interlaken Cloud is forwarded by VPP running in userspace on the host. Your private networks, load balancers, NAT and bandwidth caps are one dataplane, not a stack of appliances.

How a request reaches a workload
Internet Public IP Load balancer Workload NIC Peered VPC · Geneve your VPC VPP dataplane · userspace

Inbound traffic lands on an allocated public address, meets a load balancer, and is delivered to a workload’s NIC inside your VPC. Peered VPCs reach the same NIC over the overlay.

  1. VPCs and subnets

    Private address space of your own, segmented into subnets with their own routes, DHCP option sets and DNS records.

  2. Gateways and egress

    A gateway plus a 1:1 NAT mapping is what gives a workload a route to the internet. No gateway means no egress — closed is the default, not an add-on.

  3. Public addresses

    Public IPs are allocated from a managed pool and bound to a NIC or a load balancer. There is no such thing as an untracked address.

  4. IPv6

    Public IPv6 addresses and prefixes are allocated the same way, from the platform’s own block.

  5. VPC peering

    Peered VPCs reach each other across hosts over a Geneve overlay, staying inside private address space the whole way.

  6. Load balancers

    Flat layer-4 TCP, TLS termination, HTTP/2 layer-7 routing and HTTP/3 over QUIC — four modes, one resource, health-checked backends.

  7. Per-NIC bandwidth

    A NIC can carry an aggregate throughput cap, applied by a policer in the dataplane instead of trusting something inside the guest.

Open Networking

03 Storage

Disks that outlive the host

Block storage is DRBD replication managed by LINSTOR. A volume is written to as many hosts as its replica count says, so losing a machine costs you a copy rather than the data.

  1. Replicated volumes

    Set the replica count per volume. Attachment follows the workload, so a rescheduled workload finds its disk where it lands.

  2. Snapshots and restore

    Point-in-time copies of a disk, restorable into a new volume without disturbing the original.

  3. Golden images

    Prepare a disk the way you want it, publish it as a bootable image, and launch from it again and again.

  4. Online expansion

    Grow a volume while it stays mounted; the filesystem inside is extended to match.

  5. Object storage

    S3-compatible buckets on MinIO, with access keys you can scope to a single bucket, plus a file manager in the console.

Open Storage
A volume with three replicas write
Block volume Replica · host AReplica · host BReplica · host C

One volume, written synchronously to every host in its replica set. The replica count is yours to choose per volume.

04 Managed services

The stateful parts, run for you

Two of the hardest things to operate well are a Kubernetes control plane and a database that matters. Both are managed services here, built on the same compute, network and storage as everything else.

01

Managed Kubernetes

k3s clusters whose nodes are your own virtual machines. The platform provisions them, keeps the cluster addons reconciled, and wires the rest of Interlaken Cloud in.

  • Persistent volumes come from the same replicated block storage, through a CSI driver
  • Cluster networking and load balancing are the platform’s, not a bolt-on
  • Addon manifests are re-applied continuously, so a cluster does not drift
Wired in
  • CNI
  • CSI
  • Load balancing
  • Kubeconfig

No cluster fee — nodes bill as the virtual machines they are.

Open Kubernetes
02

Managed databases

Database instances operated by KubeBlocks on the platform’s own Kubernetes. You ask for an engine and a size; what comes back is already running.

  • Volumes are the platform’s replicated block storage, with the same snapshots
  • Provisioning, backups and restore belong to the operator, not to a script you keep
  • One endpoint and one set of credentials per instance, whatever the engine is
Engines
  • PostgreSQL
  • MySQL
  • MongoDB
  • Redis
  • Elasticsearch

Private to your VPC by default — reaching one from outside is something you ask for.

Open Databases

05 Security and operations

Trustworthy when nobody is watching

The parts that decide whether a platform holds up when nobody is looking at it.

  1. RBAC on every call

    Roles and permissions are evaluated on every API request, not once at the console door. The console, the CLI and the API all pass through the same check.

  2. Security policies at the NIC

    A policy compiles into ACLs enforced on the NIC in the dataplane, so a rule holds whether traffic came from the internet, another VPC or a neighbour.

  3. Keys and certificates

    SSH key pairs for instance access, and X.509 certificates for TLS termination — validated as a matching pair when you upload them, not when a request fails.

  4. Quotas and admission

    Per-tenant limits are checked before anything is created, so an over-quota request is refused outright instead of leaving half a resource behind.

  5. Metered billing

    Live resources are sampled continuously into usage records and invoiced monthly, itemized by resource.

  6. Continuous reconciliation

    Every resource carries a desired state and an observed state, and a reconciler works to close the gap — on create, after a host reboots, after the dataplane restarts, and on a schedule in between. Drift is re-applied rather than reported.

06 Sizes

Sizes, from the source

Instance types and their hourly rates come from the platform’s own catalogue at runtime. Nothing on this page is typed in by hand.

Type vCPU Memory Storage Per hour
vm-xsmall — — — —
vm-small — — — —
vm-medium — — — —
vm-large — — — —
vm-xlarge — — — —
vm-2xlarge — — — —
vm-4xlarge — — — —

Compute bills per instance-hour, by type. Rates on the pricing page.

See pricing

Try it

Check it by running something

Sign up, launch a workload, and watch the console show you the same resources this page describes.

Get started See what it costs