Zum Inhalt springenZum Inhalt springen
Mein Konto
Sprache Deutsch, Preise in Euro — Angaben einblenden
Sprache
Deutsch
Währung
Euro (EUR)
Preise
netto, zzgl. 19 % MwSt.

Abrechnung in Euro aus Deutschland. Weitere Sprachen und Währungen sind derzeit nicht verfügbar.

Werkzeuge für Entwicklerinnen und Entwickler

Sechs Werkzeuge,
eine Schnittstelle

Kommandozeile, Cloud Shell, Terraform-Provider, MCP-Server (die Anbindung für KI-Agenten) und die Bibliotheken sprechen alle dieselbe HTTP-Schnittstelle wie das Kundenpanel. Diese Seite sortiert sie nach Aufgabe: was wofür taugt, wo die Grenze liegt und wo die Referenz steht.

Alle Beispiele auf dieser Seite sind lauffähig, sobald ein Token und eine Projekt-ID vorliegen. Sie verwenden dieselben Endpunkte, Kopfzeilen und Antwortformen wie der Schnellstart in der Dokumentation.

Auf einen Blick
Grundpfad
api.entronyx.cloud/v2
Kommandozeile
entronyx, ein Binary
Cloud Shell
shell.entronyx.cloud
Terraform-Provider
entronyx/entronyx
MCP-Server
entronyx mcp serve
Bibliotheken
9 Sprachen, 3 Reifegrade
Jedes dieser Werkzeuge erreicht denselben Funktionsumfang. Es gibt keine Aufgabe, die ausschließlich im Panel möglich wäre.
API-Version
v2
OpenAPI 3.1 als Beschreibung
Ratenbegrenzung
3.000/min
je Projekt und Token
Abkündigungsfrist
12 Monate
Weiterbetrieb bis zum Ende
Abdeckung Panel/API
vollständig
Bedingung vor Auslieferung

Einordnung

Welches Werkzeug für welche Aufgabe

Die sechs Werkzeuge von ENTRONYX CLOUD können dasselbe. Die Wahl hängt deshalb nicht am Funktionsumfang, sondern allein an der Aufgabe. Diese Tabelle nennt für jede Aufgabe genau ein Werkzeug.

Schnittstelle

Alles, was jeder Aufruf gemeinsam hat

Kommandozeile, Terraform-Provider, MCP-Server und das Kundenpanel sprechen dieselbe HTTP-Schnittstelle. Wer sie kennt, kennt die Grenzen aller vier Werkzeuge — und weiß, was ein eigenes Skript ebenfalls kann. Beschrieben ist sie nach OpenAPI 3.1: eine maschinenlesbare Datei, aus der sich ein Client für jede Sprache erzeugen lässt.

Grundpfad
https://api.entronyx.cloud/v2
Authentifizierung
Authorization: Bearer
Projektbindung
X-Entronyx-Project
Ratenbegrenzung
3.000 / min
Beschreibung
OpenAPI 3.1
Abkündigungsfrist
12 Monate

Anwendungsschlüssel

Ein Token trägt einen Bereich je Ressourcengruppe — compute:rw, billing:ro und so fort. Fehlt der Bereich, antwortet die Schnittstelle mit 403, nicht mit 404: Die Ressource existiert, das Token darf sie nur nicht sehen.

Das Projekt steht im eigenen Kopf, nicht im Pfad. Dadurch bleibt derselbe Aufruf zwischen Test und Produktion unverändert; getauscht wird nur die Kennung.

Authorization: Bearer · X-Entronyx-Project

Ratenbegrenzung

Das Fenster gleitet, es springt nicht zur vollen Minute. Jede Antwort trägt das Restkontingent; wer es liest, muss nie in die Begrenzung laufen.

Bei 429 steht die Wartezeit in Retry-After. Sofortige Wiederholung verlängert die Sperre, statt sie zu umgehen.

3.000 Anfragen je Minute, je Projekt und Token

Version und Blättern

Die Version steht im Pfad und ändert sich nur bei brechenden Änderungen. Eine abgekündigte Version läuft zwölf Monate weiter und meldet sich in dieser Zeit über den Kopf Deprecation.

Listen werden über einen Cursor geblättert. Er ist undurchsichtig und wird unverändert zurückgegeben — anders als eine Seitenzahl überspringt er keinen Eintrag, wenn während des Blätterns eine Ressource entsteht oder verschwindet.

v2 im Pfad · Cursor statt Offset

Was der Block bewirkt: Er legt Token und Projekt in die Umgebung, holt die erste Seite der Instanzen in Frankfurt, liest die Kopfzeilen mit und fordert mit dem Cursor der ersten Antwort die zweite Seite an.

Instanzen auflisten, Kopfzeilen lesen, zweite Seite holen
# Token und Projekt einmalig in die Umgebung legen — niemals in ein Repository.
$ export ENTRONYX_TOKEN="ex_live_9f3c1a7d2b48e05c"
$ export ENTRONYX_PROJECT="prj_4c81f0"
 
# Erste Seite: bis zu 20 Instanzen in Frankfurt. Kopfzeilen mitschreiben.
$ curl -sS https://api.entronyx.cloud/v2/compute/instances \
    -H "Authorization: Bearer $ENTRONYX_TOKEN" \
    -H "X-Entronyx-Project: $ENTRONYX_PROJECT" \
    -D /tmp/kopf.txt \
    -G --data-urlencode "region=fra1" --data-urlencode "limit=20"
 
{
  "data": [
    {
      "id": "srv_8d41ac",
      "name": "web-01",
      "flavor": "nx-4-8",
      "region": "fra1",
      "image": "debian-13",
      "state": "running",
      "created_at": "2026-08-14T09:12:44Z",
      "network": { "ipv4": "185.42.19.7", "ipv6": "2a0e:8f02:41::7" }
    }
  ],
  "page": { "next_cursor": "eyJhIjoic3J2Xzhk", "has_more": true }
}
 
# Was in den Kopfzeilen steht: Restkontingent und Anfragekennung.
$ grep -iE "x-ratelimit|x-request-id" /tmp/kopf.txt
x-ratelimit-limit: 3000
x-ratelimit-remaining: 2987
x-ratelimit-reset: 1787043180
x-request-id: req_2f8c14ab9e
 
# Zweite Seite: den Cursor der ersten unverändert zurückgeben.
$ curl -sS https://api.entronyx.cloud/v2/compute/instances \
    -H "Authorization: Bearer $ENTRONYX_TOKEN" \
    -H "X-Entronyx-Project: $ENTRONYX_PROJECT" \
    -G --data-urlencode "region=fra1" --data-urlencode "limit=20" \
       --data-urlencode "cursor=eyJhIjoic3J2Xzhk"
Zurück kommt ein Umschlag aus zwei Feldern: data mit den Instanzen dieser Seite und page mit dem Cursor für die nächste. Das Restkontingent steht nicht im Körper, sondern in den Kopfzeilen — im Beispiel 2.987 von 3.000. Der Aufruf zum Erzeugen einer Instanz steht im Schnellstart der Dokumentation. Dort trägt er einen Idempotenz-Schlüssel: Wird der Aufruf nach einem Verbindungsabbruch wiederholt, verhindert der Schlüssel eine zweite Instanz.

Was der Block bewirkt: Er fordert eine Instanz mit einem Flavor an, den es in der Region Berlin nicht gibt, und liest die Antwort aus. Ein Flavor ist eine feste Kombination aus Kernen und Arbeitsspeicher.

Fehlerantwort lesen und einordnen
# Ein Flavor, den es in dieser Region nicht gibt: 422, nicht wiederholbar.
$ curl -sS -o /tmp/leib.json -w "%{http_code}\n" \
    -X POST https://api.entronyx.cloud/v2/compute/instances \
    -H "Authorization: Bearer $ENTRONYX_TOKEN" \
    -H "X-Entronyx-Project: $ENTRONYX_PROJECT" \
    -H "Content-Type: application/json" \
    -d '{ "name": "web-02", "flavor": "nx-96-768", "region": "ber1", "image": "debian-13" }'
422
 
$ jq . /tmp/leib.json
{
  "error": {
    "code": "flavor_not_available_in_region",
    "message": "Flavor nx-96-768 wird in der Region ber1 nicht angeboten.",
    "field": "flavor",
    "request_id": "req_71b0d4c6aa"
  }
}
Zurück kommt 422 und ein Fehlerobjekt mit vier Feldern: maschinenlesbarer Code, Meldung im Klartext, betroffenes Feld und Anfragekennung. 422 heißt: Die Anfrage war formal richtig, aber sachlich unmöglich — eine Wiederholung ändert daran nichts. Die Kennung gehört in jedes Ticket; mit ihr findet der Support den Aufruf im Protokoll, ohne nach Zeitstempeln zu suchen.

Kopfzeilen der Ratenbegrenzung

Vier Kopfzeilen, die ein Client auswerten sollte. Wer nur die ersten drei liest, kommt der Grenze nie nahe; wer nur die vierte liest, wartet richtig, nachdem er sie überschritten hat.

Kopfzeilen zur Ratenbegrenzung und ihre Bedeutung
KopfzeileBedeutung
X-RateLimit-LimitKontingent des Fensters, hier stets 3.000
X-RateLimit-RemainingVerbleibende Anfragen im laufenden Fenster
X-RateLimit-ResetUnix-Zeit, zu der das Fenster neu beginnt
Retry-AfterSekunden bis zum nächsten zulässigen Versuch, bei 429 und 503

Endpunkte im Überblick

Ein Ausschnitt, kein Verzeichnis: neun Aufrufe, die zusammen den üblichen Weg von der leeren Umgebung bis zum laufenden System abdecken. Die vollständige Liste mit allen Feldern liegt als OpenAPI-Beschreibung bereit.

Ausgewählte Endpunkte mit Methode, Pfad, Zweck und Erfolgscode
MethodePfadZweckErfolg
GET/v2/compute/instancesInstanzen eines Projekts auflisten, gefiltert nach Region200
POST/v2/compute/instancesInstanz erzeugen, mit Idempotenz-Schlüssel wiederholbar201
GET/v2/compute/instances/{id}Eine Instanz mit Zustand, Netz und Volumes lesen200
DELETE/v2/compute/instances/{id}Instanz abbauen, Volumes bleiben bestehen204
GET/v2/storage/volumesBlockvolumes mit Klasse, Größe und Anbindung200
POST/v2/network/private-networksPrivates Layer-2-Netz über mehrere Standorte anlegen201
GET/v2/k8s/clusters/{id}/kubeconfigZugangsdatei für einen Cluster beziehen200
POST/v2/webhooksEreignisziel eintragen, Signatur über HMAC201
GET/v2/billing/usageVerbrauch je Ressource und Etikett im Zeitraum200

Alle Pfade liegen unter dem Grundpfad https://api.entronyx.cloud. Schreibende Aufrufe nehmen den Kopf Idempotency-Key entgegen; er ist 24 Stunden gültig.

Geöffnetes 2-HE-Servergehäuse von schräg oben auf der Werkbank: Kühlkörper mit Kupferboden über dem Sockel, bestückte und verriegelte Speicherbänke, Lüfterwand, hinten die Netzteile mit Kaltgerätebuchse, an der Front die Laufwerkseinschübe.

Kommandozeile

Ein Binary, keine Laufzeit

entronyx ist statisch gelinkt — alle Abhängigkeiten stecken in der einen Datei — und läuft auf Linux, macOS und Windows ohne Interpreter im Rücken. Jede Ausgabe gibt es als Tabelle zum Lesen und als JSON zur Weiterverarbeitung. Dieselbe Abfrage taugt damit für den Blick zwischendurch und für den Cron-Eintrag.

Was der Block bewirkt: Er installiert das Werkzeug auf macOS oder Debian, hinterlegt ein Token und legt das aktive Projekt fest.

Installation, Anmeldung, Projektwahl
# macOS
$ brew install entronyx/tap/entronyx
 
# Debian und Ubuntu
$ curl -fsSL https://pkg.entronyx.cloud/gpg | sudo tee /etc/apt/keyrings/entronyx.asc >/dev/null
$ echo "deb [signed-by=/etc/apt/keyrings/entronyx.asc] https://pkg.entronyx.cloud/apt stable main" \
    | sudo tee /etc/apt/sources.list.d/entronyx.list
$ sudo apt update && sudo apt install entronyx
 
# Anmelden und das aktive Projekt festlegen. Das Token steht in einer Datei,
# nicht im Argument — Argumente landen in der Prozessliste und im Verlauf.
$ entronyx auth login --token-file ~/.config/entronyx/token
$ entronyx config set-project prj_4c81f0
 
# Prüfen, gegen welches Konto und welches Projekt gearbeitet wird.
$ entronyx auth whoami
Konto     ENTRONYX Deutschland GmbH (acc_5b12)
Projekt   prj_4c81f0 (produktion)
Bereiche  compute:rw storage:rw network:ro billing:ro
Ablauf    12.11.2026, 24 Tage verbleibend
Zurück kommt die Auskunft von entronyx auth whoami: Konto, Projekt, die vergebenen Bereiche und der Tag, an dem das Token abläuft. Das Token steht dabei in einer Datei mit Rechten 600 — lesbar nur für den Eigentümer — und nicht im Argument. Argumente stehen in der Prozessliste jedes Mitbenutzers und in der Verlaufsdatei der Shell.
Arbeitsplatz mit zwei Bildschirmen, offenem Terminalfenster und einem Notizblock, daneben ein Gehäuseteil auf der Werkbank.

Die zehn Befehle des Alltags

Der Aufbau ist durchgängig entronyx <bereich> <verb>. Wer den Bereich kennt, findet das Verb über --help; wer das Verb kennt, findet die Flags über dieselbe Stelle. Keine Abkürzungen, keine Sonderfälle.

Zehn häufig gebrauchte Befehle mit Zweck und wichtigstem Flag
BefehlZweckHinweis
entronyx auth loginToken hinterlegen und prüfen--token-file, nie als Argument
entronyx config set-projectAktives Projekt festlegengilt für alle folgenden Aufrufe
entronyx compute listInstanzen auflisten--region, --label, --state
entronyx compute createInstanz erzeugen--wait blockiert bis „running“
entronyx compute sshVerbindung zu einer Instanz öffnenlöst Namen gegen die API auf
entronyx storage volume createBlockvolume anlegen und anhängen--class block-nvme
entronyx network private-network listvRack-Netze und ihre Standorte--output json für Skripte
entronyx k8s kubeconfigZugangsdatei eines Clusters holen--merge schreibt in ~/.kube/config
entronyx k8s nodepool scaleKnotengruppe vergrößern oder verkleinern--wait wartet auf „ready“
entronyx billing usageVerbrauch im Zeitraum abrufen--from, --to, --group-by label

Jeder Befehl kennt --output table, --output json und --output jsonl (ein JSON-Objekt je Zeile) sowie --query für einen Ausdruck auf der JSON-Antwort. Die Vorgabe ist table, sobald die Ausgabe auf ein Terminal geht, und json, sobald sie in eine Pipe läuft.

Ausgabe für Skripte

Ein Werkzeug taugt für die Automatisierung, wenn es zwei Dinge zusagt: eine stabile Form der Ausgabe und einen aussagekräftigen Rückgabewert. Beides gilt hier über Nebenversionen hinweg — neue Felder kommen hinzu, vorhandene verschwinden nicht.

Was der Block bewirkt: Er holt drei Instanzen als JSON, erzeugt eine vierte und wartet auf ihren Zielzustand, schreibt den Monatsverbrauch zeilenweise in eine Datei und vergrößert eine Knotengruppe.

JSON, JSONL und --query
# Jede Ausgabe gibt es als Tabelle für Menschen und als JSON für Skripte.
$ entronyx compute list --region fra1 --output json | jq -r '.data[] | [.name, .network.ipv4] | @tsv'
web-01    185.42.19.7
web-02    185.42.19.8
db-01     185.42.19.21
 
# --query filtert im Werkzeug, damit kein zweiter Prozess nötig ist.
$ entronyx compute create --name web-03 --flavor nx-4-8 --region fra1 \
    --image debian-13 --ssh-key key_7a21bc --wait \
    --output json --query ".network.ipv4"
185.42.19.9
 
# JSONL für zeilenweise Verarbeitung großer Listen. Das Blättern über den
# Cursor übernimmt das Werkzeug selbst.
$ entronyx billing usage --from 2026-08-01 --to 2026-08-31 \
    --group-by label --output jsonl > verbrauch.jsonl
 
# Exit-Code auswerten statt Ausgabe durchsuchen.
$ entronyx k8s nodepool scale --cluster k8s-prod --pool general --count 6 --wait
$ echo $?
0
Zurück kommt nur, was --query auswählt — beim Erzeugen also eine einzige Zeile mit der Adresse. --wait blockiert, bis der Zielzustand erreicht ist; ohne --wait antwortet das Werkzeug sofort mit provisioning. Am Ende steht der Rückgabewert 0.
Rückgabewerte des Kommandozeilenwerkzeugs
CodeBedeutung
0Erfolg
2Nutzungsfehler, etwa unbekanntes Flag
3Fehler der API, Fehlerobjekt steht auf stderr
4Zeitüberschreitung, meist bei --wait

Cloud Shell

Eine Arbeitsumgebung, die schon da ist

Ein Terminal im Browser, angemeldet gegen dasselbe Konto wie das Panel. Kein Token wird in die Sitzung kopiert, keine Installation ist nötig, und die Umgebung steht in derselben Region wie die Ressourcen, an denen gearbeitet wird.

Was der Block bewirkt: Er fragt die Herkunft der Sitzung ab, misst den Platz in beiden Bereichen, holt ein Verzeichnis aus Git und startet einen Terraform-Lauf — alles ohne eine einzige lokale Installation.

Eine Sitzung von der Anmeldung bis zum Trennen
# Die Umgebung öffnet im Browser unter shell.entronyx.cloud und ist bereits
# angemeldet — es wird kein Token in die Sitzung kopiert.
entronyx@shell:~$ entronyx auth whoami
Konto     ENTRONYX Deutschland GmbH (acc_5b12)
Projekt   prj_4c81f0 (produktion)
Herkunft  Cloud Shell, Sitzung sh_9d2c41, gültig bis 21:40 Uhr
 
# /home überlebt die Sitzung, alles daneben nicht.
entronyx@shell:~$ df -h /home /tmp
Dateisystem  Größe  Benutzt  Verfügbar  Eingehängt auf
/dev/hdd1     5,0G     1,2G       3,8G  /home
tmpfs         2,0G      24M       2,0G  /tmp
 
# Ein Beispiel, das ohne jede lokale Installation läuft:
entronyx@shell:~$ git clone https://github.com/beispiel/infra.git && cd infra
entronyx@shell:~/infra$ terraform init && terraform plan
 
# Nach 30 Minuten ohne Eingabe wird getrennt. Laufende Vorgänge gehören
# deshalb in tmux — der überlebt die Trennung innerhalb der Sitzungsdauer.
entronyx@shell:~$ tmux new -s migration
Zurück kommt in der Herkunftszeile „Cloud Shell“ statt eines Tokennamens, dazu die Sitzungskennung und die Uhrzeit, zu der die Sitzung endet. Die Anmeldung ist an die Sitzung gebunden und endet mit ihr. Ein Token, das versehentlich abgelegt wird, wandert mit /home in den dauerhaften Bereich — deshalb gehört es auch hier in eine Datei mit Rechten 600.

Grenzen der Umgebung

Die Umgebung ist ein Arbeitsplatz, kein Rechenknoten. Wer mehr braucht als das hier Aufgeführte, nimmt eine Instanz — sie kostet weniger als der Umweg über eine Umgebung, die dafür nicht gebaut ist.

Rechenleistung
2 vCPU, 4 GB Arbeitsspeicher
Dauerhafter Bereich
5 GB unter /home, überlebt die Sitzung
Flüchtiger Bereich
/tmp und alles außerhalb von /home, mit dem Ende weg
Leerlauf
Trennung nach 30 Minuten ohne Eingabe
Sitzungsdauer
12 Stunden am Stück, danach Neustart
Eingehende Verbindungen
keine — die Umgebung ist nicht aus dem Netz erreichbar
Container
Podman ohne Wurzelrechte, kein Docker-Dienst
Ruhende Ablage
Löschung nach 180 Tagen ohne Anmeldung, mit Vorwarnung

Was vorinstalliert ist

Der Satz deckt den üblichen Arbeitstag ab: Infrastruktur beschreiben, Cluster bedienen, Ausgaben filtern, Daten spiegeln, Datenbanken abfragen. Die Versionen werden mit jedem Abbild nachgezogen; das Abbild selbst wird monatlich erneuert.

Vorinstallierte Werkzeuge mit Version und Verwendungszweck
WerkzeugVersionWofür
entronyximmer aktuellKommandozeile, bereits gegen das Konto angemeldet
terraform / opentofu1.14 / 1.11Infrastruktur beschreiben und anwenden
kubectl / helm1.34 / 3.19Cluster bedienen, Pakete ausrollen
Python3.14mit boto3, requests und dem Python-Paket entronyx
Node.js24 LTSmit @entronyx/sdk, npm und pnpm
Go1.26Übersetzen kleiner Werkzeuge an Ort und Stelle
jq / yq1.8 / 4.48JSON- und YAML-Ausgaben weiterverarbeiten
rclone / restic1.72 / 0.19Object Storage spiegeln, Sicherungen prüfen
psql / redis-cli18 / 8.2Verwaltete Datenbanken direkt abfragen
git / gh2.53 / 2.84Quellen holen, Änderungen zurückschreiben

Zusätzliche Pakete lassen sich in den dauerhaften Bereich unter /home installieren — etwa über pipx, npm --prefix oder go install. Systemweite Installationen überleben die Sitzung nicht, weil das Wurzeldateisystem bei jedem Start neu aus dem Abbild kommt.

Terraform

Der Zustand als Datei, nicht als Erinnerung

Der Provider — Terraforms Anbieterbaustein für ENTRONYX CLOUD — deckt Compute, Storage, Netzwerk, Kubernetes und Datenbanken ab. Was im Panel klickbar ist, ist auch als Ressource beschreibbar. Das ist dieselbe Bedingung, die auch für die HTTP-Schnittstelle gilt.

Vier Schritte bis zum ersten Plan

  1. 1Provider einbindenDer Provider liegt in der öffentlichen Registry unter entronyx/entronyx. Die Versionsbindung ~> 2.4 lässt Fehlerbehebungen zu und schließt brechende Änderungen aus. terraform init lädt ihn und schreibt die Prüfsumme in die Sperrdatei — die gehört ins Repository.
  2. 2Token setzen, nicht schreibenDer Provider liest ENTRONYX_TOKEN aus der Umgebung. Ein Token in einer .tf-Datei landet im Repository und im Zustand; beides ist nicht rückgängig zu machen, sobald es geschehen ist.
  3. 3Zustand ablegenDas S3-Backend — Terraforms Ablage für die Zustandsdatei über die S3-Schnittstelle — zeigt gegen den Endpunkt des eigenen Object Storage. Die Sperre nutzt bedingte Schreibvorgänge über use_lockfile und braucht keine zusätzliche Datenbank. Der Bucket sollte Versionierung tragen, damit ein überschriebener Zustand wiederherstellbar bleibt.
  4. 4Planen, prüfen, anwendenterraform plan -out plan.tfplan und terraform apply plan.tfplan. Der Umweg über die Datei ist der Unterschied zwischen „was geprüft wurde, wird angewendet“ und „was zufällig gerade gilt, wird angewendet“.

Was der Block bewirkt: Er beschreibt einen vollständigen Aufbau — privates Netz über zwei Standorte, Teilnetz in fra1, eine Instanz daran, ein NVMe-Volume mit 512 GB und dessen Anbindung. Die Trennung von Volume und Anbindung ist Absicht: So überlebt der Datenträger den Neuaufbau der Instanz.

Netz, Teilnetz, Instanz, Volume und Anbindung
terraform {
  required_version = ">= 1.9"
 
  required_providers {
    entronyx = {
      source  = "entronyx/entronyx"
      version = "~> 2.4"
    }
  }
 
  # Zustand im eigenen Object Storage, Sperre über bedingte Schreibvorgänge.
  backend "s3" {
    bucket       = "tfstate-prod"
    key          = "infra/app/terraform.tfstate"
    endpoints    = { s3 = "https://s3.fra1.entronyx.cloud" }
    region       = "fra1"
    use_lockfile = true
 
    skip_credentials_validation = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
  }
}
 
provider "entronyx" {
  # Token kommt aus ENTRONYX_TOKEN, nicht aus dieser Datei.
  project = "prj_4c81f0"
  region  = "fra1"
}
 
# --- Netz -----------------------------------------------------------------
resource "entronyx_private_network" "core" {
  name    = "core"
  cidr    = "10.42.0.0/16"
  regions = ["fra1", "fra2"]
}
 
resource "entronyx_subnet" "app" {
  private_network_id = entronyx_private_network.core.id
  region             = "fra1"
  cidr               = "10.42.10.0/24"
  dhcp               = true
}
 
# --- Rechenknoten ---------------------------------------------------------
resource "entronyx_compute_instance" "app" {
  name            = "app-01"
  flavor          = "nx-4-8"
  image           = "debian-13"
  region          = "fra1"
  ssh_keys        = [entronyx_ssh_key.deploy.id]
  private_network = entronyx_private_network.core.id
  subnet          = entronyx_subnet.app.id
 
  backup {
    retention_days = 14
    window         = "02:00-04:00"
  }
}
 
# --- Volume ---------------------------------------------------------------
resource "entronyx_block_volume" "daten" {
  name   = "app-01-daten"
  class  = "block-nvme"
  size   = 512
  region = "fra1"
}
 
resource "entronyx_volume_attachment" "daten" {
  volume_id   = entronyx_block_volume.daten.id
  instance_id = entronyx_compute_instance.app.id
  device      = "/dev/vdb"
}
 
output "app_ipv4" {
  value = entronyx_compute_instance.app.network.ipv4
}
Zurück gibt der Lauf genau einen Wert: app_ipv4, die Adresse der Instanz. Alles Übrige steht danach in der Zustandsdatei im Bucket, nicht auf dem Bildschirm — und der zweite Lauf mit derselben Datei ändert nichts, weil er nichts vorfindet, was von der Beschreibung abweicht.

Zustand im eigenen Object Storage

Die Zustandsdatei enthält Kennungen, Adressen und je nach Ressource auch Geheimnisse im Klartext. Sie gehört deshalb nicht ins Repository, sondern in einen Bucket, dessen Zugriff getrennt vergeben wird.

Vollständige Attributlisten je Ressource, das Verhalten beim Import bestehender Systeme und die Frage, welche Änderung einen Neuaufbau erzwingt, stehen im Terraform-Bereich der Dokumentation.

Bandförmige Reihe von Schaltschränken, dazwischen ein Gang mit Bodenmarkierung, im Hintergrund eine Wand aus Statusleuchten.

Zwischen Commit und laufender Instanz liegen bei ENTRONYX CLOUD zwei getrennte Schritte: terraform plan -out schreibt den geprüften Plan in eine Datei, terraform apply wendet genau diese Datei an — nicht das, was gerade gilt. Die Versionsbindung ~> 2.4 lässt Fehlerbehebungen zu und schließt brechende Änderungen aus.

Provider entronyx/entronyx · Zustand im eigenen Object Storage

MCP-Server

Dieselbe Schnittstelle, für Agenten beschrieben

Model Context Protocol ist die gemeinsame Sprache zwischen einem Sprachmodell und den Werkzeugen, die es benutzen darf. Unser Server übersetzt die HTTP-Schnittstelle in solche Werkzeuge — mit Beschreibung, Eingabeschema und einer klaren Trennung zwischen Lesen und Schreiben.

Wofür er da ist

Ein Agent, der einen Vorfall untersucht, braucht drei Dinge: die Liste der Ressourcen, ihre Messreihen und die Dokumentation. Alle drei über einen Server statt über drei zusammengeschriebene Skripte — und in einer Form, die das Modell nicht erraten muss.

Für den zweiten Fall, das Anlegen von Ressourcen, gilt derselbe Server, aber nicht dieselbe Freigabe. Siehe unten.

Bestandsaufnahme, Kostenfragen, Fehlersuche

Wie er angebunden wird

Lokal startet ihn das Kommandozeilenwerkzeug selbst: entronyx mcp serve. Der Client spricht über stdio — die Standard-Ein- und -Ausgabe des Prozesses — mit ihm; es öffnet sich kein Port.

Für gemeinsam genutzte Umgebungen gibt es denselben Server unter mcp.entronyx.cloud über Streamable HTTP, den netzfähigen Transport des Protokolls. Dort authentifiziert sich der Client mit einem eigenen Token, nicht mit dem des Nutzers.

stdio lokal · Streamable HTTP entfernt

Was der Agent sieht

Gesperrte Werkzeuge werden nicht ausgeblendet, sondern als gesperrt gemeldet. Das ist Absicht: Ein Modell, das ein Werkzeug gar nicht sieht, sucht einen Umweg — eines, das die Sperre kennt, meldet sie an den Menschen zurück.

Jede Antwort trägt die Anfragekennung der zugrunde liegenden API-Anfrage. Damit lässt sich jeder Schritt eines Agenten im Protokoll nachvollziehen.

Nur freigegebene Werkzeuge erscheinen

Was der Block bewirkt: Er trägt den Server in einen Agenten-Client ein — lesend, auf ein Projekt begrenzt, mit dem Token als Dateipfad statt als Wert.

Anbindung in der Konfiguration des Clients
{
  "mcpServers": {
    "entronyx": {
      "command": "entronyx",
      "args": ["mcp", "serve", "--read-only", "--project", "prj_4c81f0"],
      "env": {
        "ENTRONYX_TOKEN_FILE": "~/.config/entronyx/token-agent"
      }
    }
  }
}
Zurück bekommt der Client daraufhin die Werkzeugliste des Servers — den Block daneben. Der Dateipfad ist kein Umweg: Konfigurationsdateien von Agenten-Clients werden häufiger geteilt und gesichert, als ihren Eigentümern bewusst ist.

Was der Block bewirkt: Er zeigt, was der Server anbietet, führt einen lesenden Aufruf aus und danach — nach ausdrücklicher Freigabe — einen schreibenden.

Werkzeugliste und zwei Aufrufe
# Der Server meldet beim Verbinden, was er anbietet.
$ entronyx mcp serve --read-only --project prj_4c81f0 --list-tools
resource.list     lesend    Ressourcen auflisten, seitenweise über Cursor
resource.get      lesend    Eine Ressource vollständig lesen
catalog.search    lesend    Flavors, Abbilder und Speicherklassen einer Region
price.quote       lesend    Monatsbetrag einer Zusammenstellung berechnen
docs.search       lesend    Dokumentation nach Stichwort durchsuchen
metrics.query     lesend    Messreihen einer Ressource abfragen
instance.create   gesperrt  --read-only ist gesetzt
instance.delete   gesperrt  --read-only ist gesetzt
nodepool.scale    gesperrt  --read-only ist gesetzt
 
# Ein Werkzeugaufruf des Agenten und die Antwort des Servers, gekürzt.
-> resource.list  { "type": "compute.instance", "region": "fra1", "limit": 2 }
<- {
     "data": [
       { "id": "srv_8d41ac", "name": "web-01", "state": "running", "flavor": "nx-4-8" },
       { "id": "srv_8d41b0", "name": "web-02", "state": "stopped", "flavor": "nx-4-8" }
     ],
     "page": { "next_cursor": "eyJhIjoic3J2Xzhk", "has_more": true },
     "meta": { "request_id": "req_c1f9a2be40", "read_only": true }
   }
 
# Schreibend nur mit ausdrücklicher Freigabe — und mit demselben
# Idempotenz-Schlüssel wie ein HTTP-Aufruf, damit ein Wiederholungsversuch
# des Agenten keine zweite Instanz erzeugt.
$ entronyx mcp serve --allow-write instance.create --project prj_4c81f0
-> instance.create { "name": "web-03", "flavor": "nx-4-8", "region": "fra1",
                     "idempotency_key": "6f2a-web03-20260829" }
<- { "id": "srv_8d41c4", "state": "provisioning", "meta": { "reused": false } }
Zurück kommt derselbe Umschlag wie über HTTP: data, page und meta mit der Anfragekennung, dazu read_only als Zustand des Servers. Schreibende Werkzeuge nehmen denselben Idempotenz-Schlüssel entgegen wie ein HTTP-Aufruf — ein Agent, der nach einer Zeitüberschreitung wiederholt, erzeugt damit keine zweite Instanz.

Werkzeuge, die der Server anbietet

Sechs lesende und drei schreibende. Die Trennung verläuft nicht nach Bereichen, sondern nach Wirkung: Alles, was einen Zustand ändert oder Kosten auslöst, steht auf der schreibenden Seite und ist ohne ausdrückliche Freigabe gesperrt.

Werkzeuge des MCP-Servers mit Zweck und Wirkung
WerkzeugZweckWirkung
resource.listRessourcen eines Projekts auflisten, seitenweise über Cursorlesend
resource.getEine Ressource vollständig lesen, inklusive Zustand und Etikettenlesend
catalog.searchFlavors, Abbilder und Speicherklassen einer Region durchsuchenlesend
price.quoteMonatsbetrag einer geplanten Zusammenstellung berechnenlesend
docs.searchDokumentation nach Stichwort durchsuchen, mit Pfadangabelesend
metrics.queryMessreihen einer Ressource über einen Zeitraum abfragenlesend
instance.createInstanz erzeugen — mit Idempotenz-Schlüssel des Aufrufsschreibend
instance.deleteInstanz abbauen, Volumes bleiben erhaltenschreibend
nodepool.scaleKnotengruppe eines Clusters auf eine Zielgröße bringenschreibend

Freigegeben wird einzeln: --allow-write instance.create gibt genau dieses Werkzeug frei und kein weiteres. Ohne Angabe läuft der Server lesend, auch ohne --read-only.

Rechtevergabe

Ein Agent handelt nicht mit Absicht, sondern mit Wahrscheinlichkeit. Die Frage ist deshalb nicht, ob er einen falschen Aufruf macht, sondern was der falsche Aufruf anrichten kann.

Bibliotheken

Neun Sprachen, drei Reifegrade

Die offiziellen Bibliotheken entstehen aus derselben OpenAPI-Beschreibung wie die Dokumentation. Deshalb kann keine von ihnen einen Endpunkt anders benennen als die Schnittstelle — und deshalb erscheint ein neues Feld dort am selben Tag.

Bibliotheken je Sprache mit Paketname, Reifegrad und Anmerkung
SprachePaketReifegradAnmerkung
Gogithub.com/entronyx/entronyx-gooffiziellAus der OpenAPI-Beschreibung erzeugt, Kontexte und Wiederholung eingebaut
Pythonentronyx (PyPI)offiziellSynchron und asynchron, vollständige Typangaben
TypeScript@entronyx/sdk (npm)offiziellLäuft in Node und in der Edge-Laufzeit, keine Abhängigkeiten
Terraformentronyx/entronyxoffiziellRegistry-Provider, Version ~> 2.4
Rustentronyx (crates.io)gepflegtVon uns gebaut, folgt der API mit einigen Wochen Abstand
Javacloud.entronyx:entronyx-sdkgepflegtJava 21 aufwärts, ohne Spring-Bindung
PHPentronyx/entronyx-phpgemeinschaftlichExtern gepflegt, PSR-18-Client frei wählbar
Rubyentronyx (RubyGems)gemeinschaftlichExtern gepflegt, deckt Compute und Storage ab
.NETEntronyx.Sdk (NuGet)gemeinschaftlichExtern gepflegt, .NET 8 aufwärts

Für jede Sprache ohne Eintrag bleibt der Weg über die OpenAPI-Beschreibung: Sie erzeugt mit den üblichen Generatoren einen Client, der dieselben Namen trägt wie unsere eigenen Bibliotheken.

Was die drei Reifegrade zusagen

Und was sie ausdrücklich nicht zusagen. Ein Reifegrad ist hier eine Verpflichtung, keine Einschätzung der Codequalität.

offiziell
Von uns gebaut und veröffentlicht. Neue Endpunkte sind spätestens mit dem Erscheinen der API enthalten, Fehler werden im selben Zyklus behoben wie in der API selbst.
gepflegt
Von uns gebaut, aber nachgelagert aktualisiert. Ein neuer Endpunkt kann einige Wochen fehlen; dann bleibt der Weg über den rohen HTTP-Aufruf der Bibliothek.
gemeinschaftlich
Außerhalb entstanden. Wir verweisen darauf, prüfen die Veröffentlichung auf Schadcode und melden Abweichungen — eine Zusage zu Aktualität oder Vollständigkeit geben wir nicht.

Zwei Beispiele mit derselben Aufgabe

Instanzen auflisten und eine erzeugen — dieselben Feldnamen, dieselben Fehlercodes und derselbe Idempotenz-Schlüssel wie im HTTP-Aufruf. Die Bibliotheken verstecken das Blättern über den Cursor und wiederholen 429 und 5xx von sich aus.

Was der Block bewirkt: Er läuft über alle Instanzen in fra1 und erzeugt danach eine weitere — mit Idempotenz-Schlüssel, damit ein zweiter Anlauf keine zweite Instanz erzeugt.

Python
# pip install entronyx
from entronyx import Client, ApiError
 
# Ohne Argument liest der Client ENTRONYX_TOKEN und ENTRONYX_PROJECT.
client = Client()
 
# Blättern erledigt der Iterator; der Cursor bleibt unsichtbar.
for instance in client.compute.instances.list(region="fra1"):
    print(instance.name, instance.network.ipv4)
 
try:
    created = client.compute.instances.create(
        name="web-03",
        flavor="nx-4-8",
        region="fra1",
        image="debian-13",
        ssh_keys=["key_7a21bc"],
        idempotency_key="6f2a-web03-20260829",
    )
except ApiError as err:
    # Dieselben Codes wie über HTTP — 429 und 5xx wiederholt der Client selbst.
    print(err.code, err.message, err.request_id)
else:
    print(created.id, created.state)
Zurück kommt je Durchlauf ein Objekt mit Name und Adresse, am Ende Kennung und Zustand der neuen Instanz. Schlägt der Aufruf fehl, trägt ApiError Code, Meldung und Anfragekennung — dieselben drei Felder wie der Fehlerumschlag der Schnittstelle. Ohne Argument liest der Client ENTRONYX_TOKEN und ENTRONYX_PROJECT aus der Umgebung.

Was der Block bewirkt: Dieselbe Aufgabe in TypeScript — auflisten, dann erzeugen, mit demselben Schlüssel und denselben Feldern.

TypeScript
// npm install @entronyx/sdk
import { Entronyx, ApiError } from "@entronyx/sdk";
 
const client = new Entronyx({ project: "prj_4c81f0" });
 
// listAll blättert über den Cursor, list gibt eine einzelne Seite zurück.
for await (const instance of client.compute.instances.listAll({ region: "fra1" })) {
  console.log(instance.name, instance.network.ipv4);
}
 
try {
  const created = await client.compute.instances.create({
    name: "web-03",
    flavor: "nx-4-8",
    region: "fra1",
    image: "debian-13",
    sshKeys: ["key_7a21bc"],
    idempotencyKey: "6f2a-web03-20260829",
  });
  console.log(created.id, created.state);
} catch (error) {
  if (error instanceof ApiError) console.error(error.code, error.requestId);
  else throw error;
}
Zurück gibt listAll einen asynchronen Iterator und blättert dabei selbst; list liefert eine einzelne Seite samt Cursor, wenn die Anwendung das Blättern selbst führen will. Feldnamen erscheinen hier in der in JavaScript üblichen Schreibweise und werden vom Client übersetzt.

Erst das Werkzeug, dann die Referenz

Ein Token, eine Projekt-ID, fünf Minuten

Für den Einstieg genügt ein Token mit engem Bereich und die Kennung eines Projekts. Welches der sechs Werkzeuge danach das richtige ist, steht in der Tabelle am Kopf dieser Seite: Die Aufgabe entscheidet, nicht der Funktionsumfang — der ist bei allen sechs derselbe.

Grundpfad
api.entronyx.cloud/v2
Provider
entronyx/entronyx
MCP-Werkzeuge
6 lesend, 3 schreibend
Idempotenz-Schlüssel
24 h gültig