Plattform

Alles, was eine Cloud kann. Eine Console.

Maschinen, Netzwerke, Volumes, Datenbanken, Cluster, Deploys und Agenten — angelegt über eine API und eine Console. Darunter liegt ein Rückgrat: Tenants, Rollen, Quotas und jede Ressource gemessen auf eine einzige Rechnung.

Console öffnen Infrastruktur ansehen

01 / 07 Deploy

Vom Repository zur Adresse

Eine gemanagte Anwendungsplattform, gebaut auf Coolify und für dich betrieben. Push ein Repository oder beschreib die App — am Ende steht in beiden Fällen ein Build, ein laufender Prozess und eine URL.

Deploy-Server: Eine eigene gemanagte Coolify-Instanz, von der Plattform bereitgestellt und am Laufen gehalten.
Deploy aus Git: Zeig auf ein Repository und wähl eine Runtime. Interlaken klont es, baut es und lässt es laufen.
Config-Variablen: Bearbeite Umgebungsvariablen in der Console und übernimm sie in die laufende App.
Angehängte Datenbanken: Bind eine Managed Database an eine App; die Plattform verdrahtet die Verbindungsdaten.
App Builder: Beschreib eine App, sieh Agenten zu, wie sie sie gegen ein Repository bauen, bekomm eine Live-URL — und roll ein schlechtes Deploy zurück.
WordPress-Sites: Managed WordPress, bereitgestellt und betrieben wie jede andere Anwendung.

Deploy öffnen

bakery — deploy healthy

git push interlaken main

runtime detected — node 22
build — npm ci && npm run build
image 9f3c1a2 pushed
rollout — 1/1 healthy

live unter https://bakery.apps.interlaken.ai

02 / 07 Compute

Lass es laufen, wie es will

Vier Arten, einen Workload zu betreiben, alle aus derselben Console angelegt: eine ganze Maschine, in die du dich einloggst, eine MicroVM, die du für einen Job startest, ein Container, der nur sein Image ist, oder ein Pool, der sich selbst dimensioniert. Was du auch wählst — es landet auf deinen Netzwerken und deinen Volumes.

Virtuelle Maschinen: Aus Cloud-Images mit cloud-init gestartet, dein SSH-Key und die Erstkonfiguration sind also schon da.
MicroVMs: Auf Firecracker gebaut, ein Jailer pro Gast, gestartet aus einem Rootfs-Image, das du vorbereitet hast.
Container: OCI-Images auf denselben Netzwerken und Volumes wie jeder andere Workload.
Autoscaling-Gruppen: Lass einen Pool aus Maschinen oder Containern anhand von CPU- und Memory-Metriken wachsen und schrumpfen.
Hot Attach und Detach: Häng Volumes und Netzwerkkarten an eine laufende virtuelle Maschine an oder ab.
Konsolen: VNC für grafische Maschinen, seriell für MicroVMs — im Browser, ohne Bastion-Host.

01

Virtuelle Maschine

Ein ganzes Betriebssystem, mit cloud-init hochgefahren und deins zum Einloggen.
02

MicroVM

Ein Firecracker-Gast, den du für einen Job startest und danach wieder loslässt.
03

Container

Ein OCI-Image, so ausgeführt, wie es ist, im selben Netzwerk wie alles andere.
04

Autoscaling-Gruppe

Ein Pool aus allem oben, anhand einer Metrik vergrößert und verkleinert.

Geteilt: Netzwerke · Volumes · Images · Metriken · Console

Compute öffnen

03 / 07 Networking

Ein Netzwerk, das du wirklich konfigurierst

Jeder Tenant bekommt isolierte Virtual Private Clouds mit eigenem Adressraum. Route über ein Gateway nach draußen, stell einen Load Balancer davor und vergib öffentliche Adressen aus einem gemanagten Pool.

VPCs und Subnetze: Isolierter Adressraum pro Tenant, segmentiert in die Subnetze, die du definierst.
Gateways und öffentliche IPs: 1:1-NAT-Egress pro VPC, mit öffentlichen Adressen aus einem gemanagten Pool, an ein Interface gebunden.
Load Balancer: Layer-4-Pass-through, TLS-Terminierung, HTTP-Routing und HTTP/3 über QUIC — mit Health Checks.
VPC-Peering: Verbinde zwei private Netzwerke miteinander, ohne den Umweg über das Internet.
DHCP und DNS: Option-Sets, die du an VPCs und Subnetze hängst, und Records pro VPC, ausgeliefert vom Gateway.
Bandbreitenlimits: Ein Rate-Limit pro Netzwerkkarte, erzwungen im Datenpfad statt im Gast.

Networking öffnen

vpc-main · ingress health-checked

04 / 07 Storage

Volumes, nie das Problem einer Maschine

Block-Storage wird mit LINSTOR und DRBD über Hosts hinweg repliziert, ein Volume liegt also vom ersten Moment an auf mehr als einer Maschine. Snapshots werden zu bootfähigen Images; unstrukturierte Daten landen daneben in S3-kompatiblen Buckets.

Replizierte Block-Volumes: Jedes Volume liegt auf mehreren Hosts, und jeder Write wird auf die Replicas gespiegelt.
Snapshots: Zeitpunktkopien einer Disk, die du in ein neues Volume zurückspielst.
Golden Images: Veröffentliche einen Snapshot als bootfähiges Image und starte neue Maschinen daraus.
Object Storage: S3-kompatible Buckets auf MinIO, mit Access Keys auf ein einzelnes Bucket beschränkt und einem Dateimanager in der Console.
Online-Erweiterung: Vergrößere ein Volume und sein Dateisystem, während der Workload darauf weiterläuft.

Storage öffnen

vol-8f2a1c · 100 GiB in sync

host-01 primary

host-02 replica

host-03 replica

write

05 / 07 Datenbanken

Managed Engines, replizierter Storage

Fünf Datenbank-Engines, von KubeBlocks auf dem plattformeigenen Kubernetes bereitgestellt und laufend abgeglichen, mit ihren Daten auf denselben replizierten Block-Volumes wie alles andere. Du bekommst einen Endpoint und Zugangsdaten.

Fünf Engines: PostgreSQL, MySQL, MongoDB, Redis und Elasticsearch.
Betrieben, nicht nur installiert: Cluster werden bereitgestellt und laufend abgeglichen — du schreibst nie ein Manifest.
Replizierter Storage: Datenbank-Volumes sind die replizierten Block-Volumes der Plattform, mit derselben Snapshot-Unterstützung.
Privat by default: Erreichbar aus deinem VPC; alles darüber hinaus gibst du ausdrücklich frei.
Anhängbar: Bind eine Datenbank an eine deployte Anwendung und spar dir das Kopieren von Zugangsdaten.

Datenbanken öffnen

Engines KubeBlocks · abgeglichen

01 PostgreSQL Relational
02 MySQL Relational
03 MongoDB Dokument
04 Redis Key-Value
05 Elasticsearch Suche

repliziertes Block-Volume

Endpoint + Zugangsdaten

06 / 07 Kubernetes

Ein echter Cluster auf Maschinen, die du siehst

Managed k3s-Cluster, deren Nodes deine eigenen virtuellen Maschinen sind, in deinem eigenen VPC. Networking, der Storage-Treiber und Load Balancing sind verdrahtet, bevor du die kubeconfig bekommst.

dein VPC

kubectl

 $ kubectl get nodes 
NAME             STATUS   ROLES                  AGE   VERSION
cluster-1-cp-1   Ready    control-plane,master   12d   v1.31.4+k3s1
cluster-1-w-1    Ready    <none>                 12d   v1.31.4+k3s1
cluster-1-w-2    Ready    <none>                 12d   v1.31.4+k3s1

Managed k3s-Cluster: Eine Control Plane und ein Worker-Pool, bereitgestellt als virtuelle Maschinen in deinem Netzwerk.
Verdrahtet ab Werk: Plattform-CNI, -CSI und Load Balancing werden beim Bereitstellen konfiguriert, nicht danach.
CSI-Volumes: Persistent Volumes auf repliziertem Block-Storage, erweiterbar während Pods sie weiter nutzen.
Kubeconfig-Download: Nimm die kubeconfig aus der Console und richte kubectl direkt auf den Cluster.
Addons bleiben im Takt: Cluster-Addons werden aus den Manifesten der Plattform abgeglichen, Drift wird für dich korrigiert.

Kubernetes öffnen

07 / 07 Agenten

Agenten mit einem echten Arbeitsplatz

Ein Agent auf Interlaken bekommt eine echte Sandbox — eine Maschine mit Dateisystem, Terminal und Netzwerkzugang — statt eines Chatfensters. Gib ihm eine Rolle, Skills und Tools, und lass ein Team davon gemeinsam an einer Aufgabe arbeiten.

Sandbox-Runtimes: Ein Run ist ein pausierbarer, fortsetzbarer Fork einer versiegelten Umgebung, die du selbst gebaut und versioniert hast.
Teams und Rollen: Ein Lead delegiert an Agenten mit Rollen, jede Nachricht wird protokolliert, und du kannst mit dem Lead reden, während er arbeitet.
Skills und Tools: Fähigkeiten werden ausdrücklich vergeben. Ein Agent hat, was du ihm gegeben hast — und nichts sonst.
Claude- und Codex-Connectors: Hinterleg deine eigenen CLI-Zugangsdaten pro Tenant, damit Agenten unter Accounts laufen, die du kontrollierst.
MCP-Server und OAuth 2.1: Interlaken stellt seine eigene API als MCP-Tools hinter einem OAuth-2.1-Identity-Provider bereit, damit ein externer Agent die Plattform unter deinen Rollen steuern kann.

Agent-Runtimes öffnen

run · fix-checkout-total sandbox · vm-xsmall

plan Den fehlschlagenden Test und den Handler dahinter finden
read api/checkout — 3 Dateien
edit 2 Dateien geändert
shell go test ./... — 41 passed
done Branch fix/checkout-total gepusht

08 Betrieb

Betrieben als eine Plattform

Jede Ressource auf dieser Seite gehört zu einem Tenant, wird von einem Nutzer mit einer Rolle angelegt, zählt gegen eine Quota und fließt gemessen in eine Rechnung. Dieses Rückgrat macht daraus eine Cloud statt eines Haufens Dienste.

01 / 06

Tenants

Isolation zwischen Organisationen — über Netzwerke, Storage, Identität und Abrechnung hinweg.

02 / 06

Nutzer und Rollen

Rollenbasierte Zugriffskontrolle darüber, was jeder Nutzer mit welcher Art Ressource tun darf.

03 / 06

Quotas

Limits pro Tenant, geprüft bevor etwas bereitgestellt wird — nicht erst, wenn die Rechnung kommt.

04 / 06

Nutzungsmessung

Laufende Ressourcen werden fortlaufend gemessen und zu Nutzungsdatensätzen zusammengeführt.

05 / 06

Eine Rechnung

Aus Nutzung wird eine Rechnung. Guthaben, Zahlungsmittel und alte Rechnungen liegen in der Console.

06 / 06

Sperrsteuerung

Ein Tenant kann gesperrt werden — das kappt zuerst den Netzwerkzugang und fragt danach.

Console

Sieh es dir selbst an

Jede Sektion auf dieser Seite ist eine Seite in der Console. Leg einen Account an, und die ganze Plattform ist einen Klick entfernt.

Loslegen Preise ansehen