netcup eos ausprobiert: die neue Cloud in der Preview

netcup baut eine eigene Cloud: eos, gedacht für alle, die Server per API, Terraform oder KI-Agent verwalten statt per Klick. Wir waren in der geschlossenen Preview dabei und haben ausprobiert, was heute schon geht – und wo es noch hakt.

Vorweg: Das ist der Stand einer Testphase. Öffentlich startet eos 2027; netcup-Kunden sollen die Plattform schon vorher in einem Friends-&-Family-Launch nutzen können. Preise, Größen und viele Details werden sich bis dahin ändern.

Was bauen wir?

Wir setzen in eos eine Debian-VM auf, machen sie per SSH erreichbar, sichern Daten mit restic in den S3-Speicher der Plattform und messen die VM mit denselben Benchmarks wie unseren VPS 1000. Dabei zeigen wir die Stolpersteine, über die man beim ersten Mal fällt – zwei davon kosten ohne Vorwarnung eine halbe Stunde.

eos steht für „European Orchestrated Sovereignty“ und ist im August 2026 als Preview gestartet. Die Plattform läuft bisher in einer Region, Klagenfurt, und rechnet minutengenau ab. Alles, was die Weboberfläche kann, geht auch über eine REST-API mit öffentlicher OpenAPI-Beschreibung, das Kommandozeilenwerkzeug eosctl, einen Terraform-Provider und einen MCP-Server für KI-Agenten. Diesen Teil – Infrastruktur als Code – zeigt netcup eos mit eosctl und OpenTofu (Tutorial folgt voraussichtlich im Oktober); hier geht es um die Plattform selbst.

Voraussetzungen

• Ein Zugang zur eos-Preview. Die Anmeldung lief über das netcup-Forum und stand nur netcup-Kunden offen; die Testphase lief laut netcup bis zum 17. Oktober. Als Nächstes folgt ein Friends-&-Family-Launch für netcup-Kunden, der öffentliche Start ist für 2027 geplant.
• Ein SSH-Schlüssel auf deinem Rechner (ssh-keygen -t ed25519) – wie das geht und warum, steht in SSH absichern.
• Grundwissen zu Linux-Servern, wie es in Erste Schritte mit dem netcup-VPS vermittelt wird.

Was du in der Preview anlegst, ist ausdrücklich nicht für den Betrieb gedacht: keine SLAs, keine Redundanzgarantie, und nach der Testphase werden alle Daten gelöscht.

Schritt für Schritt

1. Die Konsole: Organisation, Realm, Rechte

Nach dem Login (Passwort plus TOTP oder direkt per Security Key) landet man im Dashboard einer Organisation. Darunter liegen Realms – Arbeitsbereiche, etwa einer pro Projekt oder Umgebung. Rechte vergibst du über Teams, für Automatisierung gibt es Client Credentials auf Organisations- oder Realm-Ebene.

Links im Realm stehen die Bausteine: Virtual Machines, Networking, ACL, Public IP, Volume Storage und Object Storage. Kubernetes, verwaltete Datenbanken, Load Balancer und eine Container-Registry fehlen noch. Auch automatische Backups gibt es nicht – Snapshots legst du von Hand an.

2. Die erste VM anlegen

Unter Virtual Machines → Create new wählst du Größe, Image und Root-Platte. In der Preview gab es drei Größen, alle mit 1-Gbit/s-Netzwerkkarte:

Als Images stehen Alpine Edge, Arch Linux, Debian 13 und Ubuntu 26.04 bereit, jeweils auch als Cloud-Variante mit Cloud-Init. Die Root-Platte ist frei wählbar ab 10 GB.

Die Preise in der Preview sind Spielgeld („Credits“) und offensichtlich Platzhalter: Alle drei Größen kosten gleich viel, 10 GB Platte sollen zehnmal mehr kosten als die VM, und oben rechts meldet die Konsole regelmäßig Price conversion error. Daraus lässt sich nichts über die späteren Preise ableiten.

Eine neue VM war in rund einer halben Minute im Zustand ready / started.

3. Cloud-Init: der SSH-Server fehlt

Der wichtigste Stolperstein zuerst: Auch die Cloud-Images bringen keinen SSH-Server mit. Cloud-Init legt deinen Benutzer und den Schlüssel brav an, aber openssh-server ist nicht installiert. Wer nur einen Benutzer mit Schlüssel übergibt, bekommt eine VM, die auf Port 22 nichts annimmt.

Cloud-Init nimmt die Konsole nur als Datei-Upload entgegen, nicht als Textfeld. Lege also lokal eine Datei user-data.yaml an:

#cloud-config
users:
  - name: koch
    groups: sudo
    shell: /bin/bash
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    ssh_authorized_keys:
      - ssh-ed25519 AAAA… DEIN_SCHLUESSEL
package_update: true
packages:
  - openssh-server
write_files:
  - path: /etc/ssh/sshd_config.d/10-nur-schluessel.conf
    content: |
      PasswordAuthentication no
      PermitRootLogin no

Ersetze DEIN_SCHLUESSEL durch den Inhalt deiner ~/.ssh/id_ed25519.pub. Die Datei legt einen Benutzer koch mit sudo-Rechten an, installiert den SSH-Server und schaltet Passwort- und Root-Login über eine Drop-in-Datei ab.

Die offizielle eos-Anleitung zum SSH-Zugang geht übrigens einen anderen Weg: Root-Passwort setzen und PermitRootLogin yes erlauben. Für einen Test mag das reichen, für einen Server im Internet nicht.

4. Die Web-Konsole: Root ohne Anmeldung

Ohne SSH bist du trotzdem nicht ausgesperrt. Über das Drei-Punkte-Menü einer VM öffnet Open Console eine Root-Shell im Browser – ohne Passwort, direkt als root.

Das ist praktisch zum Reparieren und gleichzeitig der Grund, warum dein eos-Konto mit zweitem Faktor geschützt sein muss: Wer die Konsole erreicht, hat root auf jeder VM. Prüfe dort nach dem ersten Start:

cloud-init status
systemctl is-active ssh

status: done
active

5. Öffentliche IP und ACL: zwei Schritte, nicht einer

Eine neue VM hat nur private Adressen. Jedes Netz bekommt zwar eine öffentliche IPv4 und IPv6, die dient aber nur dem ausgehenden Verkehr und Port-Weiterleitungen – an eine VM hängen lässt sie sich nicht. Für direkten Zugang legst du unter Public IP → Create new eine eigene Adresse an und hängst sie über Attach Public IP an die VM (immer 1:1).

Danach ist die VM immer noch nicht erreichbar. eos arbeitet „secure by default“: Jedes Netz hat eine Standard-ACL, und die ist leer. Eingehend wird alles abgewiesen, ausgehend ist alles erlaubt. Für SSH brauchst du eine Regel unter ACL → Add New Rule:

• Action Allow, Protocol TCP
• Sources: deine eigene IP – oder leer für „von überall“
• Destinations: die interne IP der VM, etwa 172.19.144.3
• Destination Ports: 22

Die Konsole bietet im Ziel-Feld auch an, eine VM per @name auszuwählen. In der Preview scheiterte genau das: Die API nahm die Regel an, kurz darauf meldete die Konsole Failed to create ACL Rule. Mit der internen IP als Ziel war die Regel sofort aktiv.

Ob die ACL wirkt, zeigt die Gegenprobe: Von der freigegebenen Adresse kommt man per SSH herein, von jeder anderen läuft der Verbindungsaufbau in einen Timeout. Zwischen VMs im selben Netz braucht es keine Regel – sie erreichen sich privat mit rund 1 ms.

6. Leistung: CPU top, Platte und Netz halbiert

Wir haben eine Medium-VM (4 vCores, 8 GB) mit denselben Befehlen gemessen wie den VPS 1000 G12, der ebenfalls 4 Kerne und 8 GB hat. Es sind Einzelläufe auf Preview-Infrastruktur – eine Momentaufnahme, kein Urteil über das spätere Produkt.

Bei Rechenleistung und RAM liegen beide gleichauf, bei AES ist eos deutlich schneller – die VM meldet AVX-512 und AES-NI, das CPU-Modell selbst ist hinter „Common KVM processor“ verborgen. Platte und Netz liefern etwa die Hälfte. Beim Netz ist das schlicht die 1-Gbit/s-Karte: 118 MB/s sind die volle Leitung. Die Plattenwerte passen zu dem, was netcup selbst schreibt: Die Preview läuft auf begrenzter Infrastruktur mit reduzierter Leistung.

Ein Detail, falls du selbst misst: /tmp ist bei Debian 13 ein tmpfs im RAM. Ein fio-Lauf dort misst den Arbeitsspeicher, nicht die Platte – leg die Testdateien ins Home-Verzeichnis.

7. Object Storage: S3 mit restic

eos bringt einen S3-kompatiblen Speicher mit; im Hintergrund arbeitet Ceph (die Benutzer tragen ein IAM-Handle RGW…). Zugang bekommt ein Programm über einen S3-Benutzer, den du unter Object Storage → Users anlegst. Zwei Dinge dabei:

• Der Secret Key wird genau einmal angezeigt. Sofort in den Passwortmanager kopieren.
• Der Benutzer ist ein Root-Benutzer und hat Zugriff auf alle Buckets der Organisation. Für getrennte Rechte gibt es Bucket-Policies.

Der Endpunkt ist at-preview1.object-storage.eoscloud.io, adressiert wird im Path-Style. Mit restic sieht das so aus:

export AWS_ACCESS_KEY_ID=DEIN_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=DEIN_SECRET_KEY
export RESTIC_REPOSITORY=s3:https://at-preview1.object-storage.eoscloud.io/DEIN_BUCKET/restic
export RESTIC_PASSWORD=EIN_LANGES_PASSWORT
restic init

Dass die Konsole als Bucket-URL eine lange, interne Kennung vor den Namen setzt, stört restic nicht – der Bucketname genügt. Ein Gigabyte Zufallsdaten ging in gut 9 Sekunden hinein und in rund 7 Sekunden wieder heraus, bitgenau. Auch hier begrenzt die Netzwerkkarte.

Einen zweiten Bucket konnten wir nicht anlegen. Die Konsole graut die Auswahl des Districts aus, ohne einen Grund zu nennen; erst die API sagt es deutlich:

Bucket creation is currently unavailable in this district.

Nach unserem Kenntnisstand war in der Preview ein Bucket pro Organisation vorgesehen. Außerdem blieb die Nutzungsanzeige des vorhandenen Buckets auf 0 GB stehen – die Statistik wurde seit Tagen nicht aktualisiert, die Daten lagen trotzdem korrekt im Bucket.

8. Audit-Log: wer hat was getan

Ein klarer Pluspunkt: Jede Aktion landet mit Zeit, Person, Realm und Ressource im Audit-Log der Organisation – VM angelegt, IP angehängt, Regel erstellt, Konsole geöffnet.

Fehlgeschlagene Vorgänge wie die gescheiterten ACL-Regeln tauchen dort allerdings nicht auf.

Wenn es nicht funktioniert

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

In der Preview gilt eine einfache Regel: Nichts Wichtiges dort ablegen. netcup kann Ressourcen jederzeit für Wartungsarbeiten löschen, und nach der Testphase ist ohnehin alles weg.

Für später, wenn eos produktiv nutzbar ist:

• Backups selbst organisieren. Automatische Backups gibt es (noch) nicht. Snapshots legst du von Hand über das VM-Menü an; für Daten ist ein restic-Backup in einen Bucket – besser in einen zweiten Standort – der robustere Weg.
• Konto absichern. Die Web-Konsole gibt root auf jeder VM. Ein Security Key oder TOTP für alle Mitglieder der Organisation ist Pflicht, und Client Credentials gehören wie Passwörter in einen Tresor.
• ACLs pflegen. Jede Regel ist ein Loch in der Standardsperre. Halte Quellen so eng wie möglich und lösche Regeln, wenn ein Dienst wegfällt.
• Öffentliche IPs aufräumen. Eine zusätzliche Public IP kostet, solange sie existiert. Zum Löschen erst von der VM abhängen, sonst verweigert eos das.

Unser Eindruck nach den Tagen in der Preview: Die Grundlage stimmt – sichere Voreinstellungen, eine saubere API, ein vollständiges Audit-Log und eine CPU-Leistung auf VPS-Niveau. Was fehlt, sind die Dinge, die eine Preview ausmachen: echte Preise, mehr Regionen, Backups und ein paar Kanten in der Oberfläche. Wer heute Rechenleistung für den Betrieb braucht, nimmt einen klassischen netcup-VPS oder Root-Server; wer seine Infrastruktur als Code verwalten will, sollte sich als netcup-Kunde den Friends-&-Family-Launch vormerken.