netcup eos Preview ist da – wir brauchen eure Meinung

    Liebe netcup Community,

    heute ist es endlich so weit: Wir öffnen netcup eos für eine kleine Gruppe an Testpersonen, und ich möchte euch persönlich einladen, dabei zu sein.
    netcup eos steht für "European Orchestrated Sovereignty" und ist das neue Cloud Platform Angebot powered by netcup.

    Als Dankeschön fürs Mitmachen gibt es bei Live-Gang von netcup eos Credits im Wert von 50 EUR für alle, die an 3 Umfragen teilnehmen. Mehr Infos zur Registrierung und Prämien-Programm findest du hier.

    Bevor es losgeht, will ich euch kurz erzählen, was netcup eos überhaupt ist, wer hier für euch ansprechbar ist und was ich mir von den nächsten Wochen erhoffe.

    Was ist netcup eos?

    netcup eos ist unsere neue europäische Cloud-Plattform. Sie richtet sich an moderne Builder, die zeitgemäße Infrastruktur wollen - automatisierbar, ohne Vendor Lock-in, ohne US-Abhängigkeit. Unser Grundgedanke dahinter: You build it - we run it.

    Einen ersten Blick darauf durften einige von euch bereits letztes Jahr bei unserem Community Event werfen. Seitdem haben wir viel gebaut, viel verworfen und wieder neu gebaut. Jetzt sind wir an dem Punkt, an dem wir euch brauchen, um weiterzukommen.

    Was steckt technisch drin?

    Heute bekommt ihr mit netcup eos virtuelle Maschinen (1 bis 4 vCPUs, mit Cloud-Init und Snapshots), private Netzwerke und einen S3-kompatiblen Object Storage. Das Besondere ist, wie ihr das steuert: Jede Funktion ist über eine offene API verfügbar - per Web-Oberfläche, CLI, Terraform und auch direkt durch KI-Agenten über eine eigene MCP-Schnittstelle. Sicherheit ist bei uns Standardeinstellung: Ein neues Netzwerk ist von außen zu, bis ihr es bewusst öffnet. Wer will, kommt vom leeren Account bis zur laufenden VM komplett ohne einen einzigen Klick aus. Alle Details - Konzepte, Funktionen und Tooling - findet ihr in der ausführlichen technischen Vorstellung: netcup eos im Detail: Was die Plattform heute kann.

    Und falls ihr tiefer einsteigen wollt: Wir haben eine ausführliche Dokumentation zu netcup eos: https://docs.eoscloud.io/

    Wer steht dahinter?

    Im Forum sind für euch da:

    Bruno Hautzenberger (Chief Technology Officer): verantwortlich für die Steuerung und Planung der Plattform, Produkte und deren Teams
    Stephan Pejinik-Steinwender (Chief Solution Architect): verantwortlich für die technische Gesamtarchitektur
    Stefan Lizelfelner (Domain Lead Platform Core): verantwortlich für den Bereich Core Platform
    Thorsten Lusser (Domain Lead Compute): verantwortlich für den Bereich Compute Foundation

    Wir lesen hier alle mit. Wenn etwas nicht funktioniert oder ihr Fragen habt, schreibt uns - wir antworten.

    Wo stehen wir gerade?

    netcup eos ist jetzt in der Preview-Phase. Das heißt: Eine kleine, ausgewählte Gruppe - und dazu gehört ihr - bekommt als Erste Zugriff auf die Plattform. Ich will ehrlich sein: Es ist noch nicht alles fertig. Das UI ist nicht final, es gibt kein festes Branding, keine SLAs und keine Redundanz-Garantien. Das ist bewusst so, und genau deshalb seid ihr jetzt hier - nicht danach.

    Warum machen wir das?

    Ich will mit euch gemeinsam möglichst viele Probleme finden, bevor wir netcup eos für mehr Leute öffnen. Genauso wichtig ist mir euer Feedback, um die richtigen Entscheidungen für netcup eos zu treffen: Was fehlt euch? Was ist unlogisch designt? Und treffen wir mit dem, was wir gebaut haben, überhaupt das Richtige für euch? Je ehrlicher euer Feedback jetzt ist, desto besser können wir entscheiden, bevor viel mehr Leute auf der Plattform sind.

    Ein Ort für den Austausch

    Dafür haben wir diesen Preview-Bereich hier im Forum eingerichtet. Das soll der zentrale Platz für alle sein, die mit dabei sind:

    Status: hier informieren wir über Wartungen und Ausfälle
    Support & Fragen: wenn ihr nicht weiterkommt
    Feedback & Bugs: für alles, was kaputt ist oder besser sein könnte
    Dein Projekt mit netcup eos: zeigt uns, was ihr gebaut habt
    Features und Wünsche: was euch fehlt oder was ihr euch als Nächstes wünscht

    Wie geht's weiter?

    Diese Preview ist erst der Anfang. Mit eurem Feedback arbeiten wir weiter an der Plattform, bevor wir den Kreis größer machen. netcup eos ist für uns ein Projekt mit langem Atem, und ich freue mich, dass ihr von Anfang an dabei seid.

    Ich lese hier mit und freue mich über jede Rückmeldung, auch kritische.

    Liebe Grüße,
    Alex

    Hallo,

    ich habe 5 vServer mit Debian 13, provisioniert über das EOS-Panel, alle im Netzwerk
    „at-preview1-da-default" (Block „at-preview1-da"). Jede VM hat eine öffentliche IPv6-Adresse
    zugewiesen und zeigt im Panel den Status „ready", aber keine der VMs kommt ins IPv6-Internet
    raus.

    Setup:
    - Jede VM bekommt per RA nur eine ULA-Adresse (fdxx:xxxx:xxxx:xxxx::N/64) sowie eine
    Default-Route über ein Link-Local-Gateway. Das Gateway antwortet auf NDP (Status
    REACHABLE), reagiert aber nie auf ICMPv6-Echo.
    - Zusätzlich zeigt das Panel eine eigene öffentliche /128-IPv6-Adresse, die 1:1 auf jede VM
    gemappt ist (sichtbar unter „Public IP" im Dashboard). Diese Adresse taucht innerhalb der
    VM aber nie auf — genau wie beim IPv4, das ebenfalls aus einem privaten /24 genattet wird.

    Was funktioniert:
    - VM-zu-VM über die ULA-Adresse: 0 % Paketverlust.
    - Eine VM pingt die gemappte ÖFFENTLICHE IPv6-Adresse einer anderen VM: 0 % Paketverlust,
    ~6 ms. Das 1:1-Mapping der öffentlichen IPv6 funktioniert also grundsätzlich.

    Was nicht funktioniert:
    - Jedes externe IPv6-Ziel läuft von jeder VM aus in den Timeout: 2001:4860:4860::8888,
    2606:4700:4700::1111, 2620:fe::fe, sowie öffentliche AAAA-Ziele — durchweg 100 % Verlust.
    - curl -6 zu jedem externen Host läuft in den Timeout.
    - Die eigentliche Upstream-Gateway-Adresse (einen Hop hinter dem Link-Local-RA-Gateway) ist
    ebenfalls nicht erreichbar.

    Auf meiner Seite ausgeschlossen:
    - Die Konfiguration in der VM ist korrekt: disable_ipv6=0, accept_ra=1, AAAA-Auflösung
    funktioniert einwandfrei, IPv4 (ebenfalls genattet) läuft ohne jedes Problem.
    - Die Netzwerk-ACL besteht aus einer einzigen Allow-All-Regel (beliebiges
    Protokoll/Quelle/Ziel), also liegt es nicht an Firewall/ACL.

    Für mich sieht das nach fehlendem IPv6-Upstream-Routing/Transit auf Block-Ebene aus — das
    Mapping in den Block hinein funktioniert, aber danach geht nichts mehr weiter. Hat das schon
    jemand anderes auf at-preview1-da gehabt, oder ist das ein bekanntes/gemeldetes Problem?
    Traceroutes oder weitere Infos liefere ich gerne nach.

    Danke!