Hyper-Effiziente Container-Orchestrierung für moderne Hosting-Plattformen
Schluss mit schwerfälligen Monolithen und Session-Chaos. Ignite Containers liefert die moderne, API-first Container Control Plane für Cloud-Provider, Gaming-Hoster und SaaS-Plattformen. Maximale Dichte, minimale Latenz und nahtlose Integration in jedes Billing-System.
Maximale Skalierung. Zero Overhead.
Warum moderne Infrastruktur-Teams von Legacy-Panels auf Ignite Containers umsteigen:
Radikal Headless & API-First
Ihre Kunden bleiben in Ihrer eigenen Markenwelt. Schließen Sie WHMCS, Ignite oder Ihr Custom-Portal in Minuten über Scoped API-Keys an – ganz ohne Cookie-Sessions.
Autonome Self-Healing Engine
Desired-State Reconciliation: Die Control Plane definiert den Soll-Zustand, autonome Node-Agents gleichen Abweichungen in Echtzeit ab. Nie wieder hängende Server.
Next-Gen Port Orchestration
Vergessen Sie Port-Kollisionen. Nutzen Sie atomare Zuweisungen per SKIP LOCKED, individuelle Bind-IPs und separate Listener für maximale Netzwerksicherheit.
Hardened Workload Defense
Multi-Tenant Isolation auf Enterprise-Niveau: Rootless Docker Daemon, Sockguard Policy Filter mit Default-Deny und strikte Linux-Cgroup Limits.
Universal Pterodactyl Egg Engine
Bestehende Eggs im Pterodactyl-Format (v1 und v2) laufen unverändert weiter – inklusive Variablen und Installer-Skripten. Profitieren Sie von SemVer-Versionierung, Ed25519-Signierung und automatischer Config-Umschreibung.
Developer Experience der Extraklasse
Offizielle First-Party SDKs für TypeScript, Rust und PHP, vollwertige OpenAPI 3 Dokumentation und eine native Desktop Management GUI für Admins.
Getrennte Verantwortlichkeiten.Klare Systemgrenzen.
Moderne Micro-Orchestrierung statt Monolith: Die Control Plane verwaltet den Soll-Zustand, während dezentrale Node-Agents die Ausführung isolieren.
Gehärtet nach Defense-in-Depth Prinzipien
Entwickelt für geschäftskritische Multi-Tenant Plattformen mit strikter Sicherheits-Architektur.
256-Bit Scoped API Keys
Zustandslos gespeicherte, gepfefferte HMAC-SHA256 Hashes mit präzisen Berechtigungen und TTL-Verfall.
Versiegelte Node Tokens
Node-Agent Authentifizierungstoken werden at-rest mit XChaCha20-Poly1305 verschlüsselt gespeichert.
Kryptografische Signaturkette
Jeder Steuerbefehl wird über Methode, Pfad, Timestamp, Nonce und Body-Hash signiert und validiert.
Rootless Workload-Isolation
Container laufen isoliert unter unprivilegierten Host-UIDs. Kein Zugriff auf den Host-Root.
Sockguard Policy Proxy
Schützt den Container-Socket mit Default-Deny-Regeln gegen unberechtigte Mounts und Exec-Aufrufe.
Argv-First Execution
Direktes Spawning von Prozessen ohne zwischengeschaltete Shell-Interpreter.
Kryptografische Vertrauenskette (Proof Chain)
Jeder Datenübergang von der API bis zur Container-Ausführung ist mathematisch abgesichert
Ignite Containers vs. Pterodactyl
Zwei unterschiedliche Ansätze: Reine API-First Control Plane für Provider vs. integriertes Endnutzer-Panel.
Architektur- & Feature-Gegenüberstellung
Detaillierter Vergleich der beiden Systeme nach Kernkriterien
| Feature / Fähigkeit | Ignite Containers | Pterodactyl |
|---|---|---|
1. Architektur & Sicherheit | ||
Reines API-only Modell (Keine User-Accounts) | API-Keys sind die einzige Identität. Keine Benutzerkonten, keine Sessions, kein CSRF-Overhead. | Fest integrierte Benutzerverwaltung mit Logins, Passwörtern, 2FA und Browser-Sessions. |
Integriertes Endkunden-Webpanel | Konzeptioneller Unterschied: Reine API für Provider. Kundenverwaltung & Billing verbleiben im externen Portal (WHMCS, Ignite, etc.). | Integriertes Kunden-Webinterface mit Serveransicht, Rollen und Benutzerrechten. |
Feingranulare Scopes & Expiry-TTL | Gezielte Scopes (z. B. servers:power, logs:stream), Server-Allowlists und Ablaufdaten. | Grobe Trennung in Application-Keys (Admin) und Client-Keys (User). |
Strukturierte Audit-Logs aller Mutationen | GET /audit-events protokolliert jede API-Mutation mit Key-ID, Aktion und JSON-Metadaten. | Aktivitäten-Protokoll im Web-Panel für Benutzeraktionen. |
Sockguard Policy Proxy (Socket-Filterung) | Vorgeschalteter Sockguard-Proxy filtert Docker-Socket-Aufrufe mit Default-Deny gegen unerlaubte Mounts & Execs. | Direkte Kommunikation zwischen Wings und dem Docker-Daemon-Socket (Standard oder Rootless). |
Multi-Node Architektur & Daemon | Zustandsloser Rust-Agent auf jedem Node mit autonomem Reconcile-Loop. | Go-basierter Node-Daemon (Wings) auf jedem Worker. |
Online Node-Token Rotation | POST /nodes/{id}/rotate-token rotiert Agent-Tokens im laufenden Betrieb. | Erfordert manuelle Bearbeitung der Konfigurationsdatei auf dem Node. |
Wartungsmodus & Heartbeat-Überwachung | maintenance-Flag sperrt neue Zuweisungen; Agenten melden Status alle 10 Sekunden. | Wartungsmodus im Panel aktivierbar; Wings meldet Status regelmäßig. |
Host-Updates & Reboot-Helper (hostctl) | Privilegiertes ignite-containers-hostctl Tool für Paket-Updates und Reboots über API. | Host-OS-Wartung muss vollständig manuell per SSH durchgeführt werden. |
2. Workloads & Kubernetes | ||
Kubernetes Workload-Treiber | Deployment + PVC pro Server, Services (ClusterIP/NodePort/LB), Ingress & NetworkPolicies. | Nicht unterstützt (Wings benötigt direkten Zugriff auf Docker). |
Server-Transfer & Live-Migration | POST /servers/{id}/transfer mit copy-Modus (S3/Backup) oder shared-Modus (K8s RWX Cutover). | Integrierter Node-zu-Node Server-Transfer über Websocket/Archiv. |
Power-Aktionen (Start/Stop/Restart/Kill) | Power-Signale über transaktionale Jobs; Reconciler garantiert gewünschten Zustand. | Power-Steuerung über Wings und WebSocket. |
Server-Reinstallation mit Daten-Erhalt | POST /servers/{id}/reinstall führt Installer neu aus; persistente Daten bleiben unberührt. | Führt das Installationsskript im bestehenden Serververzeichnis erneut aus. |
Suspend & Resume | POST /servers/{id}/suspend stoppt Workload und blockiert alle Aktionen bis Resume. | Server kann im Panel gesperrt und wieder freigegeben werden. |
Flottenweite Bulk-Operationen | POST /servers/bulk/power und /bulk/command zur Massensteuerung. | Befehle und Power-Aktionen müssen pro Server einzeln getriggert werden. |
CSI VolumeSnapshot Backups | Unterstützt VolumeSnapshot-Klassen für Kubernetes-Storage. | Nicht unterstützt. |
Helm Chart für Cluster-Installation | Offizielles Helm-Chart für API, Postgres, Ingress und Agent-RBAC in deploy/helm. | Kein offizielles Helm-Chart. |
3. Netzwerk & Storage | ||
Atomare Port-Allokation (SKIP LOCKED) | Bulk-Portbereiche, atomare Vergabe via FOR UPDATE SKIP LOCKED in Postgres. | Port-Bereiche und Zuweisungen über MySQL-Tabellen. |
Zusatz-Ports zur Laufzeit anbinden | Dynamisches Hinzufügen/Entfernen von Zusatzports; Primärport bleibt geschützt. | Zuweisung und Entfernung zusätzlicher Allocations im Server-Menü. |
Getrennte Listener für API und Admin-UI | Eigene BIND- und ADMIN_BIND-Konfigurationen, um Admin-UI und API auf getrennte Sockets/VLANs zu legen. | Panel-Weboberfläche und /api Routen werden gemeinsam über dieselbe Webserver-Konfiguration ausgeliefert. |
Integrierte Caddy Reverse-Proxy Steuerung | API-verwaltetes Routing mit automatischer TLS-Zertifikatsausstellung (ACME). | Separater Webserver (Nginx/Apache) muss manuell eingerichtet und gepflegt werden. |
Dateimanager (CRUD & Chmod) | API-Dateimanager mit Symlink-Sandbox (5 MiB Inline-Handling + Archivierung). | Dateibrowser im Web-Panel mit Code-Editor. |
Archiv-Verwaltung (tar.gz, tgz, tar) | POST /files/compress und /decompress mit Traversal- und Link-Schutz. | Packen und Entpacken von Archiven im Web-Panel. |
SFTP-Zugang mit temporären Zugangsdaten | Temporäre per-Server Credentials mit TTL und Chroot auf das Server-Volume. | SFTP-Daemon in Wings mit statischem Panel-Passwort. |
Backups (Lokal & S3-kompatibel) | Lokal auf dem Node oder via S3, Retention-Policies und Cross-Node Restore. | Erstellung, Download und Wiederherstellung von Backups. |
Server-Datenbanken (MariaDB / MySQL) | Host-Cluster, Erstellen/Löschen von DB + User und versiegelte Passwörter. | Verwaltung von Datenbank-Hosts und Anlegen von DBs pro Server. |
Geplante Aufgaben (Cron Schedules) | 5-Feld Cron-Parser, Aktionen (Power, Command, Backup) und manueller Testlauf. | Cron-basierte Schedules für Power-Aktionen, Befehle und Backups. |
4. Templates & Ökosystem | ||
Pterodactyl Egg JSON Import (v1 & v2) | Vollständiger Import von Eggs im Pterodactyl-Format v1 und v2 – inklusive Variablen und Installern. | Ursprüngliches Standardformat von Pterodactyl. |
Konfigurations-Umschreibung (YAML, JSON, Properties, XML) | Automatische Umschreibung von Config-Dateien bei Erstellung und bei jedem Boot. | Rewriter passt Serverkonfigurationen bei Start an. |
Startbefehl-Rendering & Shell-Modi | Argv-First mit konfigurierbaren Shell-Modi (auto / never / always). Startbefehle werden als strukturiertes Parameter-Array zerlegt. | Startbefehle werden als zusammenhängender String gerendert und an das Entrypoint-Skript des Containers übergeben. |
Unveränderliche Versionierung (SemVer) | Templates sind unveränderlich versioniert; Server pinnen Versionen explizit. | Änderungen an Eggs überschreiben die bestehende Definition. |
Ed25519 Signierte Auto-Update-Feeds | Vorlagen tragen kanonische SHA-256 Digests und Ed25519-Signaturen. | Manuelle JSON-Exporte / Importe ohne kryptografische Signatur. |
Live-Konsole & Log-Streaming | Authentifizierter SSE-Log-Stream (GET /logs/stream) + PTY-Befehlseingabe über die API. | Websocket-Verbindung direkt zum Wings-Daemon mit PTY-Terminal. |
OpenAPI 3.0 & Swagger UI | Automatisch generiertes openapi.json und interaktives Swagger UI unter /docs. | Eigene Dokumentation, aber kein standardisiertes OpenAPI-Dokument. |
Offizielle SDKs (TypeScript, Rust, PHP) | First-Party SDKs für TypeScript (Zero Runtime Dependencies), Rust und PHP. | REST-API vorhanden, aber keine offiziellen Client-SDKs (nur Community-Pakete). |
Pterodactyl Client-API Kompatibilität | Kompatibilitäts-Subset unter /api/client (Server, Power, Konsole, Dateien). | Nativer Standard. |
Cross-Plattform Desktop Management GUI | Dedizierte Desktop-App für Administratoren mit SSE-Live-Konsole. | Keine Desktop-App vorhanden (nur Web-Panel). |
HMAC-Signierte Webhooks & Event-Stream | Dauerhafte Retry-Outbox für server.created, state_changed, deleted, transferred. | Webhooks nur über Drittanbieter-Erweiterungen. |
API-Keys sind die einzige Identität. Keine Benutzerkonten, keine Sessions, kein CSRF-Overhead.
Fest integrierte Benutzerverwaltung mit Logins, Passwörtern, 2FA und Browser-Sessions.
Konzeptioneller Unterschied: Reine API für Provider. Kundenverwaltung & Billing verbleiben im externen Portal (WHMCS, Ignite, etc.).
Integriertes Kunden-Webinterface mit Serveransicht, Rollen und Benutzerrechten.
Gezielte Scopes (z. B. servers:power, logs:stream), Server-Allowlists und Ablaufdaten.
Grobe Trennung in Application-Keys (Admin) und Client-Keys (User).
GET /audit-events protokolliert jede API-Mutation mit Key-ID, Aktion und JSON-Metadaten.
Aktivitäten-Protokoll im Web-Panel für Benutzeraktionen.
Vorgeschalteter Sockguard-Proxy filtert Docker-Socket-Aufrufe mit Default-Deny gegen unerlaubte Mounts & Execs.
Direkte Kommunikation zwischen Wings und dem Docker-Daemon-Socket (Standard oder Rootless).
Zustandsloser Rust-Agent auf jedem Node mit autonomem Reconcile-Loop.
Go-basierter Node-Daemon (Wings) auf jedem Worker.
POST /nodes/{id}/rotate-token rotiert Agent-Tokens im laufenden Betrieb.
Erfordert manuelle Bearbeitung der Konfigurationsdatei auf dem Node.
maintenance-Flag sperrt neue Zuweisungen; Agenten melden Status alle 10 Sekunden.
Wartungsmodus im Panel aktivierbar; Wings meldet Status regelmäßig.
Privilegiertes ignite-containers-hostctl Tool für Paket-Updates und Reboots über API.
Host-OS-Wartung muss vollständig manuell per SSH durchgeführt werden.
Deployment + PVC pro Server, Services (ClusterIP/NodePort/LB), Ingress & NetworkPolicies.
Nicht unterstützt (Wings benötigt direkten Zugriff auf Docker).
POST /servers/{id}/transfer mit copy-Modus (S3/Backup) oder shared-Modus (K8s RWX Cutover).
Integrierter Node-zu-Node Server-Transfer über Websocket/Archiv.
Power-Signale über transaktionale Jobs; Reconciler garantiert gewünschten Zustand.
Power-Steuerung über Wings und WebSocket.
POST /servers/{id}/reinstall führt Installer neu aus; persistente Daten bleiben unberührt.
Führt das Installationsskript im bestehenden Serververzeichnis erneut aus.
POST /servers/{id}/suspend stoppt Workload und blockiert alle Aktionen bis Resume.
Server kann im Panel gesperrt und wieder freigegeben werden.
POST /servers/bulk/power und /bulk/command zur Massensteuerung.
Befehle und Power-Aktionen müssen pro Server einzeln getriggert werden.
Unterstützt VolumeSnapshot-Klassen für Kubernetes-Storage.
Nicht unterstützt.
Offizielles Helm-Chart für API, Postgres, Ingress und Agent-RBAC in deploy/helm.
Kein offizielles Helm-Chart.
Bulk-Portbereiche, atomare Vergabe via FOR UPDATE SKIP LOCKED in Postgres.
Port-Bereiche und Zuweisungen über MySQL-Tabellen.
Dynamisches Hinzufügen/Entfernen von Zusatzports; Primärport bleibt geschützt.
Zuweisung und Entfernung zusätzlicher Allocations im Server-Menü.
Eigene BIND- und ADMIN_BIND-Konfigurationen, um Admin-UI und API auf getrennte Sockets/VLANs zu legen.
Panel-Weboberfläche und /api Routen werden gemeinsam über dieselbe Webserver-Konfiguration ausgeliefert.
API-verwaltetes Routing mit automatischer TLS-Zertifikatsausstellung (ACME).
Separater Webserver (Nginx/Apache) muss manuell eingerichtet und gepflegt werden.
API-Dateimanager mit Symlink-Sandbox (5 MiB Inline-Handling + Archivierung).
Dateibrowser im Web-Panel mit Code-Editor.
POST /files/compress und /decompress mit Traversal- und Link-Schutz.
Packen und Entpacken von Archiven im Web-Panel.
Temporäre per-Server Credentials mit TTL und Chroot auf das Server-Volume.
SFTP-Daemon in Wings mit statischem Panel-Passwort.
Lokal auf dem Node oder via S3, Retention-Policies und Cross-Node Restore.
Erstellung, Download und Wiederherstellung von Backups.
Host-Cluster, Erstellen/Löschen von DB + User und versiegelte Passwörter.
Verwaltung von Datenbank-Hosts und Anlegen von DBs pro Server.
5-Feld Cron-Parser, Aktionen (Power, Command, Backup) und manueller Testlauf.
Cron-basierte Schedules für Power-Aktionen, Befehle und Backups.
Vollständiger Import von Eggs im Pterodactyl-Format v1 und v2 – inklusive Variablen und Installern.
Ursprüngliches Standardformat von Pterodactyl.
Automatische Umschreibung von Config-Dateien bei Erstellung und bei jedem Boot.
Rewriter passt Serverkonfigurationen bei Start an.
Argv-First mit konfigurierbaren Shell-Modi (auto / never / always). Startbefehle werden als strukturiertes Parameter-Array zerlegt.
Startbefehle werden als zusammenhängender String gerendert und an das Entrypoint-Skript des Containers übergeben.
Templates sind unveränderlich versioniert; Server pinnen Versionen explizit.
Änderungen an Eggs überschreiben die bestehende Definition.
Vorlagen tragen kanonische SHA-256 Digests und Ed25519-Signaturen.
Manuelle JSON-Exporte / Importe ohne kryptografische Signatur.
Authentifizierter SSE-Log-Stream (GET /logs/stream) + PTY-Befehlseingabe über die API.
Websocket-Verbindung direkt zum Wings-Daemon mit PTY-Terminal.
Automatisch generiertes openapi.json und interaktives Swagger UI unter /docs.
Eigene Dokumentation, aber kein standardisiertes OpenAPI-Dokument.
First-Party SDKs für TypeScript (Zero Runtime Dependencies), Rust und PHP.
REST-API vorhanden, aber keine offiziellen Client-SDKs (nur Community-Pakete).
Kompatibilitäts-Subset unter /api/client (Server, Power, Konsole, Dateien).
Nativer Standard.
Dedizierte Desktop-App für Administratoren mit SSE-Live-Konsole.
Keine Desktop-App vorhanden (nur Web-Panel).
Dauerhafte Retry-Outbox für server.created, state_changed, deleted, transferred.
Webhooks nur über Drittanbieter-Erweiterungen.
Plug & Play Integration für Entwickler
Integrieren Sie Container-Management in jede Web-App mit offiziellen SDKs für TypeScript, Rust und PHP.
import { IgniteContainersClient } from '@att-it-cloud-services/ignite-containers-client';
const client = new IgniteContainersClient({
baseUrl: 'https://api.games.example.com',
apiKey: process.env.IGNITE_CONTAINERS_KEY!,
});
// Create server with 4GB RAM and atomic auto-allocation
const server = await client.createServer({
nodeId: 'node_fra_01',
templateId: 'tmpl_paper_minecraft',
name: 'survival-fra-01',
externalRef: 'customer-whmcs-4291',
autoAllocations: 1,
limits: {
memoryMb: 4096,
diskMb: 10240,
cpuMillis: 2000,
pidsLimit: 512,
},
});
console.log('Server provisioned:', server.id, server.primaryPort);Ignite Containers Desktop App
Cross-Plattform Management- & Debug-App mit interaktiver SSE/WebSocket Live-Konsole: