Cloud-Infrastruktur für Trading-Strategien
Keine Server zu verwalten. Kein Kubernetes zu lernen. Keine Terminals, die offen bleiben müssen.
Verbinden Sie ein GitHub-Repository, wählen Sie eine Region und Ihre Trading-Strategie läuft auf einer für den Dauerbetrieb optimierten TradingHost-Infrastruktur. TradingHost übernimmt Rechenleistung, Orchestrierung, Netzwerk-Routing der Laufzeitumgebung und die operative Steuerung unter Ihrer Bereitstellung. Sie konzentrieren sich ganz auf Ihre Strategie.
Das erhalten Sie
- 99,99 % Infrastruktur-SLA
- Containerisierte Laufzeiten
- Multi-Regionen-Deployment
- Steuerung für Laufzeit-Restarts
- Streaming-Logs
- GitHub-nativer Workflow
- Keine selbst verwalteten Server
Sektion 01 · Managed Cloud, verständlich erklärt
Neu im Bereich Managed Cloud-Infrastruktur?
Wer schon einmal eine Trading-Strategie auf einem VPS betrieben hat, kennt den Aufwand: auf dem Server einloggen, Updates einspielen, Prozess-Manager konfigurieren, sich mit Terminal-Sitzungen herumschlagen und nachts um drei Uhr nach Fehlern suchen, um das System neu zu starten. Man ist ständig mit der Serverpflege beschäftigt.
Eine Managed Cloud-Infrastruktur dreht das Prinzip um. Sie übergeben der Plattform einfach den Code aus Ihrem GitHub-Repository. Die Plattform führt ihn aus, hält ihn am Laufen und informiert Sie über den Status. Sie müssen kein Systemadministrator mehr sein, sondern können sich wieder ganz auf das Traden oder Entwickeln konzentrieren.
Das ist TradingHost. Ihr Code liegt auf GitHub. Um die Infrastruktur kümmern wir uns.
Managed Cloud definiert
TradingHost führt Ihren Trading-Code auf einer verwalteten Cloud-Infrastruktur aus. TradingHost verwaltet die Rechenleistung, die Orchestrierung, das Netzwerk-Routing der Laufzeitumgebung und die operativen Kontrollen unterhalb Ihrer Bereitstellung. Kunden greifen nicht direkt auf die zugrunde liegenden Host-Server zu.
Sektion 02 · Zuverlässigkeit
99,99 % Infrastruktur-SLA für die Ebene unter Ihrer Laufzeitumgebung
TradingHost garantiert eine Infrastruktur-SLA von 99,99 % für die Verfügbarkeit von Netzwerk, Rechenzentrum und Stromversorgung, vorbehaltlich der SLA-Bedingungen und -Ausschlüsse.
TradingHost bietet eine reine Infrastruktur-SLA. Die tatsächliche Verfügbarkeit Ihrer Strategie hängt zusätzlich von Ihrem Code, den APIs von Brokern und Börsen, Zugangsdaten, Abhängigkeiten, Drittanbieter-Diensten und der Zustandswiederherstellung ab.
Die SLA von TradingHost bezieht sich ausschließlich auf die Infrastrukturebene: die Verfügbarkeit von Netzwerk, Rechenzentrum und Stromversorgung. Sie garantiert nicht die fehlerfreie Funktion von Benutzercode, Broker- oder Börsen-APIs, GitHub, Drittanbieter-Diensten, Zugangsdaten, Abhängigkeiten oder dem In-Memory-Zustand Ihrer Strategie.
- Steuerung für Laufzeit-Restarts
- Wenn ein Strategieprozess unerwartet beendet wird, kann TradingHost ihn gemäß den Restart-Richtlinien der Laufzeitumgebung neu starten und den Fehler in Ihren Logs anzeigen. Das genaue Restart-Verhalten hängt von der Konfiguration Ihrer Bereitstellung ab.
- Infrastruktur-Wiederherstellung
- Sofern unterstützt, kann die Orchestrierungsebene betroffene Laufzeiten bei Störungen der zugrunde liegenden Infrastruktur neu starten oder auf andere Ressourcen verschieben. Ihre Strategie muss dennoch so konzipiert sein, dass sie nach einem Neustart sicher weiterlaufen kann.
- Multi-Regionen-Deployment
- Sie entscheiden, in welcher Region Ihre Laufzeitumgebung ausgeführt wird. Sollte es in einer Region zu Performance-Einbußen kommen, können Sie Ihre Strategie in Sekundenschnelle in einer anderen Region bereitstellen – direkt über das Dashboard oder aus Ihrer KI-IDE via MCP.
SLA-Ausschlüsse
Die Infrastruktur-SLA gilt nicht bei folgenden Ereignissen. Die vollständige Liste finden Sie in unseren Allgemeinen Geschäftsbedingungen.
- Geplante Wartungsarbeiten und Notfallwartungsfenster
- Geplante Migrationen
- Kontosperrung oder Kündigung des Dienstes
- Höhere Gewalt
- Ausfälle von Upstream-Providern
- ISP-Probleme auf Kundenseite
- Software, die in den Runtimes des Kunden ausgeführt wird
- Angriffe Dritter, Viren und Server-Kompromittierungen
- Fehler durch Benutzeraktivitäten
Sektion 03 · Auf einen Blick
TradingHost in zehn Zeilen
Die gesamte Plattform im schnellen Überblick. Jede Zeile verweist auf einen Bereich oder eine Seite mit weiteren Details.
- Infrastruktur
- Managed Cloud, containerbasiert.
- Was du verwaltest
- Strategiecode, Handelslogik, Broker- und Börsenkonfiguration sowie Risikokontrollen.
- Was TradingHost verwaltet
- Rechenleistung, Betriebssystem, Orchestrierung, Runtime-Netzwerk und Infrastrukturbetrieb.
- Serverzugriff
- Kein Kundenzugriff auf die zugrunde liegenden Host-Server.
- Isolation
- Kunden-Runtimes sind von den Runtimes anderer Kunden isoliert.
- Strategien pro Runtime
- Eine oder mehrere, je nach Deployment-Konfiguration.
- Regionen
- Mehrere, siehe Regionen.
- Kubernetes-Kenntnisse nötig?
- Nein.
- Zuverlässigkeitsmodell
- Runtime-Neustart-Optionen, Health-Monitoring, Streaming-Logs und Infrastruktur-SLA.
- SLA
- 99,99 % Infrastruktur-SLA für Netzwerk, Rechenzentrum und Stromversorgung (unterliegt Ausschlüssen).
Sektion 04 · Funktionsweise
Drei Layer, von denen du nur einen nutzt
Drei Layer liegen zwischen dir und der zugrunde liegenden Cloud. Du interagierst immer nur mit einem davon. Genau diese Trennung ist der Punkt: Du schreibst deinen Trading-Code, pushst ihn zu GitHub und deine Strategie läuft. TradingHost kümmert sich um die Rechenleistung, die Orchestrierung, das Runtime-Netzwerk und die operativen Kontrollen unterhalb deines Deployments.
Control Plane
Was du siehst: Das Dashboard, der Deploy-Flow, die Logs und der MCP-Server. Jede Kundeninteraktion findet hier statt.
Runtime
Der Container, in dem deine Strategie tatsächlich läuft. Konfiguriert über dein GitHub-Repository und den Deploy-Flow. Du loggst dich nie direkt dort ein.
Infrastruktur
Rechenleistung, Orchestrierung, Runtime-Netzwerk und operative Kontrollen. Verwaltet von TradingHost. Kunden haben keinen Zugriff auf die zugrunde liegenden Host-Server.
Sektion 05 · TradingHost vs. VPS
Ein VPS gibt dir einen Server. TradingHost gibt deinem Code eine Umgebung, in der er läuft.
TradingHost ist kein VPS mit schönerer Oberfläche. Es ist eine speziell für Trading-Code entwickelte Infrastruktur. Dashboard, Runner, Secrets-Verwaltung und Lifecycle-Steuerung sind bereits vollständig eingerichtet und einsatzbereit.
Auf einem VPS
- Sie verwalten den Server
- Per RDP oder SSH einwählen
- Abhängigkeiten manuell installieren
- Terminal-Sessions aktiv halten
- Nach Logdateien suchen
- Betriebssystem patchen
- Dienste nach Abstürzen manuell neu starten
- Server-zentriert
Auf TradingHost
- Sie verwalten Ihre Strategie
- Dashboard oder MCP nutzen
- Im Repository definieren
- Strategien laufen in verwalteten Runtimes
- Logs werden direkt ins Dashboard gestreamt
- Wir kümmern uns um das Betriebssystem
- Automatische Neustarts
- Strategie-zentriert
Bereich 06 · Was Sie nicht mehr tun müssen
Dinge, die nicht mehr Ihre Aufgabe sind
Kein offenes Terminal auf dem Desktop. Keine manuellen Neustarts nach Abstürzen. Wir übernehmen das alles für Sie.
- Betriebssysteme
- Kernel-Updates
- Sicherheitspatches
- Container-Scheduler
- Netzwerkkonfiguration
- Firewalls
- Hardware-Monitoring
- Kapazitätsplanung
- Neustarts
- Health-Monitoring
Sie müssen auch kein Kubernetes lernen. Wir nutzen es im Hintergrund, weil es das richtige Tool für die Orchestrierung langlebiger Workloads im großen Stil ist – aber Sie bekommen davon nichts mit. Für Sie zählen nur Ihr Repository, eine Region und der Deploy-Button.
Bereich 07 · Was in Ihrer Hand bleibt
Die Trading-Entscheidungen treffen weiterhin Sie
TradingHost führt den Code aus. Die Trading-Entscheidungen, das Risikomodell und die Broker-Verbindung bleiben in Ihrer Hand.
- Strategie schreiben
- Verbindung zum Broker oder zur Exchange herstellen
- Risikoparameter festlegen
- Positionsgrößen und Order-Handling bestimmen
- Vor dem Live-Gang testen
- Das eigene Trading-Verhalten überwachen
Bereich 08 · Transparenz
Klare Grenzen, offen kommuniziert
Keine Diskrepanz zwischen Marketing und Realität.
Was das 99,99 % SLA abdeckt
Das SLA von TradingHost gilt für die Infrastrukturebene: Netzwerk, Rechenzentrum und Stromverfügbarkeit. Es garantiert nicht, dass User-Code, Broker-APIs, Exchange-APIs, GitHub, Drittanbieter-Dienste, Zugangsdaten, Abhängigkeiten oder der In-Memory-Status der Strategie fehlerfrei funktionieren.
Die Verfügbarkeit der Strategie hängt zudem von Ihrem Code, Broker- und Börsen-APIs, Zugangsdaten, Abhängigkeiten, Drittanbieter-Diensten und der Zustandswiederherstellung ab. Die vollständigen SLA-Bedingungen und -Ausschlüsse finden Sie in unseren Allgemeinen Geschäftsbedingungen.
- TradingHost bietet keinen Shell-Zugriff auf die zugrunde liegenden Server.
- TradingHost sichert den In-Memory-Status Ihrer Strategie bei Neustarts nicht. Strategien sollten ihren Status über Broker-APIs oder externe Speicher wiederherstellen.
- TradingHost garantiert keine spezifischen Latenzen zu bestimmten Brokern. Die Latenz hängt von der gewählten Region, den Netzwerkbedingungen und der Infrastruktur des Brokers ab.
- TradingHost ist kein Broker und keine Börse. Ihre Strategie verbindet sich direkt.
FAQ
Häufig gestellte Fragen
Das 99,99-%-SLA deckt die Verfügbarkeit der TradingHost-Infrastruktur für Netzwerk, Rechenzentrum und Stromversorgung gemäß den SLA-Bedingungen und -Ausschlüssen ab. Es garantiert nicht die Uptime von Strategie-Code, Broker-APIs, Börsen-APIs, Drittanbieter-Diensten, Anmeldedaten, Abhängigkeiten oder dem In-Memory-Status der Strategie.
Nein. Das SLA gilt ausschließlich für die Infrastrukturebene. Ihre Strategie kann weiterhin durch Codefehler, Fehlkonfigurationen, ungültige Anmeldedaten, Broker- oder Börsenausfälle, Rate-Limits, Probleme mit Abhängigkeiten, Fehler bei der Zustandswiederherstellung oder manuelle Bedienfehler fehlschlagen.
Ja. Die Runtimes der Kunden sind voneinander isoliert. Eine Runtime kann je nach Deployment-Konfiguration eine oder mehrere Strategien ausführen, aber Strategien aus verschiedenen Kundenkonten teilen sich niemals dieselbe Runtime-Umgebung.
Nein. Ein VPS bietet Ihnen einen Remote-Server, den Sie selbst verwalten müssen. TradingHost führt Ihren Trading-Code auf einer verwalteten Cloud-Infrastruktur aus. Sie verbinden einfach ein GitHub-Repository und wir kümmern uns um den Rest.
Nein. TradingHost nutzt Kubernetes im Hintergrund, aber Sie kommen damit nie direkt in Berührung. Sie verbinden einfach GitHub, wählen eine Region und starten das Deployment.
TradingHost zeigt den Fehler im Deployment-Status und in den Logs an. Je nach Runtime-Konfiguration und Fehlertyp wird der Strategieprozess entweder automatisch neu gestartet oder erfordert ein manuelles Eingreifen.
Sofern unterstützt, kann TradingHost betroffene Runtimes neu starten oder auf eine fehlerfreie Infrastruktur verschieben. Ihre Strategie muss dennoch so konzipiert sein, dass sie sich nach einem Neustart sicher wiederherstellt.
Ja. Wählen Sie beim Deployment aus den unterstützten Regionen, damit Ihre Runtime nahe an Ihrem Broker oder Ihrer Börse liegt. Die aktuelle Liste finden Sie auf der Seite „Regionen“.
Nein. Der In-Memory-Status sollte niemals als dauerhaft betrachtet werden. Ihre Strategie sollte ihren Zustand aus Broker-APIs, externen Datenbanken oder persistenten Dateien selbstständig wiederaufbauen.
Nein. TradingHost ist eine vollständig verwaltete Infrastruktur. Sie steuern alles über das Dashboard, MCP und die Runtime-Logs.
Deployen Sie Ihre erste Strategie
Verbinden Sie GitHub, wählen Sie eine Region, konfigurieren Sie Ihre Runtime und deployen Sie Ihre erste Strategie auf der TradingHost-Infrastruktur.