STRYKE Hub
STRYKE Hub ist aktuell in der geschlossenen Beta. Du bekommst vollen Zugriff auf alle bereits freigegebenen Features und hast direkten Draht zum Entwicklerteam — ohne Ticket-System, ohne First-Level-Callcenter. Beta-Teilnehmer erhalten dauerhafte Sonderkonditionen beim Launch und frühen Zugang zu neuen Funktionen, sobald sie aus dem Staging in die Produktion wandern.
Die Beta ist ein frühzeitiger Zugang zum vollständigen STRYKE Hub. Du arbeitest mit der echten Produktivumgebung — keine Demo, keine künstlichen Limits, keine abgespeckten Features. Alles was live ist, kannst Du nutzen: Sliplane Container verwalten, ALL-INKL Domains und Postfächer anlegen, WordPress deployen, Teams einladen, den AES-256-GCM Credential Vault befüllen. Parallel zur Nutzung fließt Dein Feedback direkt in die Roadmap — viele Beta-Nutzer sehen ihre Vorschläge innerhalb weniger Tage im Produkt.
Ja. Während der gesamten Beta-Phase ist die Nutzung von STRYKE Hub kostenfrei. Du zahlst keinen Setup-Preis, keine Monatsgebühr, keine Feature-Limits. Die Infrastruktur-Kosten (ALL-INKL Pakete, Sliplane Container, Domains, Postfächer) laufen wie gewohnt über die Rechnung des jeweiligen Providers bzw. über STRYKE als Reseller — STRYKE Hub selbst ist im Beta-Zeitraum das gratis Dashboard obendrauf. Erst nach dem offiziellen Launch gelten die regulären Hub-Tarife. Beta-Teilnehmer bekommen dauerhafte Rabatte, die es danach nicht mehr gibt.
Nach der Beta gibt es vier Hauptpakete, passend zu den beiden Hosting-Welten, die wir abdecken:
Zusätzliche Domains (de, com, net, org, eu, io, shop, online) und Postfächer kommen als Add-ons dazu. Alle Preise stammen aus unserer zentralen Pricing-API — im Hub werden sie niemals fest einprogrammiert, sondern live nachgezogen. Die tagesaktuelle Liste findest Du auf pricing.strykehub.de. Beta-Teilnehmer erhalten beim Umstieg exklusive Sonderkonditionen.
Vier handfeste Vorteile, die es nach dem Launch nicht mehr gibt:
Der Übergang ist nahtlos. Du musst nichts migrieren, nichts neu einrichten und nichts exportieren. Workspaces, Hosting-Accounts, Teams, Vault-Einträge, Permission-History, Pricing-Zuordnungen — all das bleibt erhalten. Einige Wochen vor dem offiziellen Launch informieren wir alle Beta-Teilnehmer per E-Mail: Ab diesem Stichtag greifen die regulären Tarife (abzüglich der Beta-Rabatte). Wer nicht weitermachen will, hat Zeit für einen geordneten Export; wer bleibt, klickt einmal auf "Tarif bestätigen" und arbeitet ohne Unterbrechung weiter.
Nein. Und auch nach der Beta nicht. Du zahlst per SEPA-Überweisung oder SEPA-Lastschrift. Die Rechnung kommt automatisch per E-Mail — eine klassische deutsche Rechnung mit USt-ID-Ausweis, so wie Du sie auch von ALL-INKL oder Sliplane kennst. Keine Kreditkarten-Hinterlegung, keine Abo-Tokens bei Drittanbietern. Deine Rechnung läuft in Deutschland, nach deutschen Regeln, über ein deutsches Rechnungssystem.
Drei Wege, alle funktionieren:
Antwortzeit während der Beta liegt werktags bei wenigen Stunden, oft deutlich schneller. Was wir verbessern, sagen wir Dir explizit zurück — kein „wurde als gelöst markiert" ohne Info.
Die Beta richtet sich an Unternehmer, Agenturen und kleine bis mittlere Teams, die aktiv Hosting verwalten — eigene Projekte oder Kunden-Seiten. Ideal sind Freelancer mit mehreren Kundenprojekten, Marketing-Agenturen mit einem festen Kunden-Stamm, Inhouse-Marketing-Abteilungen oder Entwickler-Teams, die Container-Workloads und klassisches WordPress-Hosting kombinieren. Für reine Privatnutzer ohne Team-Use-Case ist der Hub aktuell überdimensioniert. Anfrage über strykehub.de/#beta — wir schalten gestaffelt frei, damit der direkte Support-Kanal nicht überläuft.
Ein Account reicht — dahinter verwaltest Du beliebig viele Workspaces, Teams, Brands und Projekte. Rollen und Berechtigungen sind sauber getrennt, jeder Zugang ist jederzeit widerrufbar, und kein Mitarbeiter sieht jemals ein Passwort, das er nicht sehen soll. Genau für diesen Use-Case — Entscheider mit mehreren Projekten, Agenturen mit Teams, Freelancer mit Kunden — wurde STRYKE Hub gebaut.
In der Beta-Phase läuft die Registrierung in zwei Bahnen: Entweder Du bekommst eine Einladung von einem bestehenden Workspace-Owner (Mitarbeiter, Kunde, Kollege) — dann klickst Du den Einladungs-Link, setzt Dein Passwort, fertig. Oder Du meldest Dich direkt für die Beta an und bekommst einen Onboarding-Link per E-Mail, über den Du einen neuen Workspace als Owner anlegst. In beiden Fällen gibt es keine App zu installieren, keine Kreditkarte zu hinterlegen und kein Abo-Tool zu koppeln. Der Hub läuft komplett im Browser.
Auf der Login-Seite gibt es den Link "Passwort vergessen?". Du gibst Deine E-Mail-Adresse ein, bekommst einen zeitlich begrenzten Reset-Token per Mail (gültig nur wenige Stunden, einmal verwendbar) und setzt Dein neues Passwort. Wir speichern Passwörter ausschließlich als Bcrypt-Hash — auch unser Administrator kann Dein Passwort nicht einsehen. Falls Du auch keinen Zugriff mehr auf Deine E-Mail hast, schreib uns an mail@stryke-marketing.de; wir verifizieren Dich über einen alternativen Kanal, bevor wir das Konto freischalten.
STRYKE Hub hat zwei Berechtigungs-Ebenen, die kombiniert werden:
Die Kombination ist feinkörnig: Ein Mitarbeiter kann z.B. Member im Workspace sein, aber auf einem bestimmten Hosting-Account nur Viewer — oder umgekehrt eine externe Person als External im Workspace, die auf exakt einen Kunden-Account Editor-Rechte hat. Jede Änderung landet in der Permission History — immutable, append-only, mit Zeitstempel und Urheber.
Der Workspace ist die oberste Organisationsebene. Er bündelt alles, was zu einem Unternehmen, einer Agentur oder einem Mandat gehört: Team-Mitglieder, Hosting-Accounts (ALL-INKL und Sliplane), Vault-Einträge, Brands, Projekte, Rechnungsdaten. Zwischen verschiedenen Workspaces gibt es keine geteilten Daten und keine Querzugriffe — ein Mitarbeiter, der in Workspace A ist, sieht nichts von Workspace B, auch wenn der gleiche Owner beide Workspaces führt. Das ist nicht nur eine UI-Trennung, sondern in der Datenbank sauber über Workspace-IDs abgesichert.
Ja, das ist sogar der Regelfall. Mit einem einzigen Login verwaltest Du beliebig viele Workspaces — z.B. "Agentur intern", "Kunde Müller GmbH", "Eigenprojekt Nebenverdienst", "Mandat Bürogemeinschaft". Du wechselst zwischen ihnen wie zwischen Browser-Tabs. Jede Deiner Rollen (Owner, Member, External) wird pro Workspace separat verwaltet — Du kannst Owner in Deinem Agentur-Workspace sein und gleichzeitig External in einem Kunden-Workspace, der Dich nur für ein Projekt eingeladen hat.
Einladung läuft per E-Mail mit einem zeitlich begrenzten, signierten Token (standardmäßig 48 Stunden gültig, nur einmal verwendbar — reduziertes Phishing-Risiko). Du wählst beim Versand bereits die Workspace-Rolle (Owner, Member, Viewer, External) und optional direkte Ressourcen-Zugriffe. Der Eingeladene klickt den Link, legt ein Passwort fest, ist sofort im Workspace. Während er dort arbeitet, sieht er zu keinem Zeitpunkt KAS-Passwörter, Sliplane-Tokens, SMTP-Credentials oder andere Zugangsdaten — alle API-Calls laufen über den STRYKE-Backend-Proxy, der die verschlüsselten Credentials erst zur Laufzeit im Speicher entschlüsselt und nach dem Request wieder verwirft.
Ein einziger Klick. Als Workspace-Owner entfernst Du den User aus dem Team, und sein Zugriff ist sofort entzogen — für den Workspace selbst und automatisch (Cascade) für alle Hosting-Accounts, Vault-Einträge, Brands und Projekte, auf die er direkt oder via Shared-Role Zugriff hatte. Jede einzelne dieser Revoke-Aktionen landet in der Permission History mit einer gemeinsamen Kaskaden-ID, damit Du bei einem späteren Audit exakt nachvollziehen kannst, wann welcher Zugriff entzogen wurde. Und das Wichtigste: kein einziges Passwort und kein einziger Token muss geändert werden. Der Ex-Mitarbeiter konnte die Zugangsdaten zu keinem Zeitpunkt lesen — Revoke heißt Revoke, nicht „und jetzt noch zehn Passwörter zurücksetzen". Genau das ist der USP von STRYKE Hub.
Die Hierarchie lautet Workspace → Brand → Projekt → Ressource. Der Workspace ist das Unternehmen, die Brand ist eine Marke oder Sparte (z.B. Agentur mit mehreren Marken, Unternehmen mit Tochterfirmen), das Projekt ist ein konkretes Mandat oder ein Kunde. Ressourcen — Hosting-Accounts, Vault-Einträge, Domains — hängen je nach Bedarf direkt am Workspace oder an einem Brand/Projekt. Brands und Projekte sind optional: Kleinere Teams arbeiten oft flach direkt im Workspace, größere Agenturen nutzen die vollständige Struktur, um Zugriffe sauber zu staffeln. Jede Ebene hat eigene Rollen und taucht in der Permission History auf.
Aktuell läuft der Login über E-Mail und Passwort mit serverseitigem Bcrypt-Hash. Eine echte 2FA-Implementierung (TOTP-Apps wie Google Authenticator, 1Password, Authy — optional WebAuthn/Passkeys für die Zukunft) ist fest auf der Roadmap und wird in der Benutzermanagement-Phase eingeführt. Beta-Teilnehmer erhalten Zugang, sobald das Feature aus dem Staging in die Produktion wandert. In der Zwischenzeit gilt: nutze ein starkes, einzigartiges Passwort (der integrierte Passwort-Generator im Vault hilft dabei) und ein E-Mail-Postfach, das selbst 2FA-gesichert ist.
Dafür ist die External-Rolle gebaut. External-Mitglieder sind Teil des Workspaces, sehen aber standardmäßig nichts — keine Mitglieder-Liste, keine Hosting-Accounts, keine Vault-Einträge. Erst wenn Du einer External-Person explizit Zugriff auf eine einzelne Ressource gibst (z.B. Editor-Rolle auf einem Hosting-Account), wird genau diese Ressource für sie sichtbar. Perfekt für Szenarien wie „Freelancer-Entwickler bekommt für vier Wochen Sliplane-Deploy-Rechte auf Projekt X", „Partner-Agentur bekommt DNS-Editing auf zwei Kunden-Domains", „Entwickler-Studio sieht WordPress-Admin ohne den ALL-INKL-KAS-Login". Nach Projektende: ein Klick, und der Zugang ist weg — kein Passwort-Wechsel nötig, kein Risiko vergessener Credentials.
Der AES-256-GCM verschlüsselte Credential Vault ist eine der beiden tragenden USP-Säulen von STRYKE Hub. Alle Zugangsdaten — KAS-Reseller-Credentials, Sliplane Bearer Token, FTP- und DB-Passwörter, WordPress App-Passwords — liegen ausschließlich verschlüsselt in der Datenbank und werden nur zur Laufzeit beim Backend-Proxy entschlüsselt. Der Browser sieht nie ein Klartext-Secret. Server stehen in Deutschland, die Architektur ist DSGVO-konform gebaut.
Jeder Vault-Eintrag wird mit AES-256-GCM verschlüsselt — das ist ein authentifizierter Algorithmus, der sowohl Vertraulichkeit als auch Integrität garantiert (d.h. manipulierter Ciphertext wird beim Entschlüsseln abgelehnt). Der pro-Workspace-Schlüssel wird zur Laufzeit per HKDF-SHA256 aus einem Workspace-Master-Secret und der WorkspaceId als Salt abgeleitet (versioniert über einen Info-String — Rotation ist damit eine reine Konfigurationsänderung, keine Daten-Migration). Metadaten wie Titel und Icon-URL bleiben im Klartext (damit Suche und Sortierung ohne Entschlüsselung funktionieren) — die eigentlichen Secrets (Passwörter, API-Tokens, CVV-Codes) liegen ausschließlich im verschlüsselten Feld.
Nein. Die Klartext-Secrets existieren nur in zwei Situationen: (1) im Moment, in dem Du sie im Hub eintippst — da verschlüsseln wir sie direkt beim Backend-Eingang, bevor sie in die Datenbank wandern; und (2) im RAM des Backend-Prozesses während eines Proxy-Calls, für die exakte Dauer einer API-Anfrage an KAS oder Sliplane. Danach werden sie verworfen. Der Browser, das Frontend-Bundle und alle Mitarbeiter-Geräte sehen zu keinem Zeitpunkt das Raw-Secret. Unser Anspruch: der Client sieht nie ein Raw-Credential.
Nein. Das STRYKE-Admin-Panel zeigt ausschließlich Metadaten: Anzahl der Vault-Einträge pro Workspace, letzter Zugriff, Typ des Eintrags, Status-Flags. Niemals Klartext-Secrets. Diese Regel ist im Code fest verankert — die Admin-Oberfläche ruft die Entschlüsselungs-Routine schlicht nicht auf. Einen Workaround gibt es nicht: Wenn wir den Klartext bräuchten, müssten wir Dein Workspace-Master-Secret kennen — und das tun wir per Design nicht, solange wir nicht aktiv Dein Feature nutzen.
Ein klassischer Passwortmanager ist im Kern eine Copy-Paste-Maschine: Er zeigt Dir Dein Passwort, Du kopierst es, fügst es irgendwo ein. Sobald Du copy-paste machst, verlässt das Secret den Manager. STRYKE Hub ist für den Hosting-Use-Case anders gebaut: Der Vault speichert das Secret, aber das Frontend zeigt es typischerweise gar nicht an — stattdessen drückst Du einen Button ("Container deployen", "Domain anlegen", "Postfach erstellen"), und das Backend führt den API-Call mit dem verschlüsselten Secret im Namen des Users aus. Ergebnis: Ein Mitarbeiter kann die ALL-INKL-Domain administrieren, ohne jemals das KAS-Passwort gesehen zu haben. Wenn er das Unternehmen verlässt, reicht ein Revoke-Klick — kein einziges Passwort muss gewechselt werden.
Selbst ein vollständiger Datenbank-Dump wäre für den Angreifer wertlos — ohne das Master-Secret für die HKDF-Ableitung und den workspace-spezifischen Schlüssel kommt er an keinen einzigen Klartext-Eintrag. Das Master-Secret liegt außerhalb der Datenbank (im verschlüsselten Secrets-Store der Backend-Infrastruktur), und die Schlüssel werden pro Request im RAM abgeleitet. Zusätzlich trennen wir Workspaces auf DB-Ebene streng voneinander — ein geleakter Schlüssel eines Workspaces würde nicht die Secrets anderer Workspaces entschlüsseln, weil in die HKDF-Ableitung die WorkspaceId als Salt eingeht. Die Kombination aus authentifizierter Verschlüsselung, per-Workspace-Schlüsselableitung und separatem Master-Secret-Storage ist gezielt als Defense-in-Depth aufgebaut.
Ja. Entwicklung und Hosting sitzen in Deutschland, die Datenverarbeitung unterliegt deutschem und europäischem Datenschutzrecht, und wir erstellen einen Auftragsverarbeitungs-Vertrag (AVV) auf Anfrage. Personenbezogene Daten werden ausschließlich zweckgebunden verarbeitet. Permission History ermöglicht eine DSGVO-Auskunft auf Knopfdruck. Der Campaign Link Tracker arbeitet vollständig ohne Cookies und mit IP-Hashing (SHA-256 mit server-seitigem Salt), damit Du keine Consent-Banner schalten musst. Die volle Datenschutzerklärung findest Du unter privacy.strykemarketing.de.
In Deutschland. Backend, Datenbank (PostgreSQL) und Redis laufen auf unserer Sliplane-Infrastruktur an deutschen Standorten. Die Sliplane-Container-Hosts stehen in Falkenstein und Nürnberg (deutsche Rechenzentren); optional sind für Kunden-Workloads zusätzlich die Standorte Helsinki, Singapur, Ashburn (US-East) und Hillsboro (US-West) buchbar — das ist aber eine Kunden-Entscheidung pro Server und keine Default-Konfiguration. Die ALL-INKL-Integration verbindet sich mit dem KAS von ALL-INKL, ebenfalls ein deutscher Anbieter mit Rechenzentren in Deutschland.
Die per-Workspace-Schlüssel werden mit jedem Request neu abgeleitet — sie existieren im Klartext nur im RAM eines einzelnen Backend-Requests. Das Workspace-Master-Secret wird in den HKDF-Info-String hineinversioniert (aktuell). Eine Rotation des gesamten Verschlüsselungs-Schemas ist damit eine reine Versions-Änderung: neuer Info-String → alle neuen Einträge verwenden die neue Ableitung, bestehende werden im Hintergrund reencryptet. Ohne Ausfallzeit, ohne Migration zum kopieren. Ein geleakter Schlüssel eines einzelnen Requests wäre außerdem unbrauchbar, weil er nur für diesen einen Request gilt.
Aktuell fünf Typen, die alle realen Hosting-Use-Cases abdecken:
Zu jedem Typ gehören passende Felder im UI (Generator für Passwörter, Kartennummern-Maskierung, Token-Reveal mit Klickschutz).
Ein Vault-Eintrag kann gezielt mit einzelnen Usern, ganzen Teams oder dem gesamten Workspace geteilt werden — mit exakt einer von drei Capabilities:
Shares können zusätzlich per Scopes feingranular begrenzt werden (z.B. read:posts, write:posts) und erhalten optional ein Ablaufdatum. Jede Änderung landet in der Permission History.
Ja. Der Vault hat einen Import/Export-Assistenten, der die gängigen Formate liest: 1Password (CSV und 1PUX), Bitwarden (unverschlüsseltes JSON) und das native STRYKE-Export-Format. Import läuft clientseitig durch den Parser, jedes Element wird Dir vor dem Speichern zur Bestätigung gezeigt — so landet kein vergessener Eintrag aus dem alten Manager im neuen Vault, und Du kannst Kategorien direkt sauber setzen. Export in die gleichen Formate funktioniert jederzeit (auch bei Vertragsende), damit Du nie in einem Lock-in sitzt.
Jede sicherheitsrelevante Aktion — Vault-Eintrag erstellt, geteilt, benutzt, gelöscht; Hosting-Zugriff gewährt oder entzogen; Team-Mitglied eingeladen oder entfernt — landet in der Permission History. Die Einträge sind append-only: sie werden nie überschrieben oder gelöscht, auch nicht bei Account-Löschung (archivierter Zustand nach DSGVO-Fristen). Jeder Eintrag hat Zeitstempel, Urheber, Ziel-Ressource, Aktionstyp und eine Kaskaden-ID, die zusammengehörende Revoke-Kaskaden gruppiert. Das Log ist per Knopfdruck exportierbar — Pflicht für Audits und Zertifizierungen, praktisch für jede interne Revisions-Anfrage.
Sliplane ist unser Partner für Container-Hosting — von ein paar Services für den Nebenverdienst bis zu Dedicated-Servern für produktive App-Stacks. Im Hub bekommst Du ein aufgeräumtes Cockpit: Server-Liste mit Größe und Standort, Service-Deploys per Klick, Logs und Metriken live, Custom Domains und Let's-Encrypt-SSL. Alle Sliplane-Calls laufen über unseren Backend-Proxy; der Bearer-Token liegt AES-256-GCM verschlüsselt im Vault und verlässt ihn nie.
Sliplane ist ein deutscher Cloud-Container-Hoster, mit dem sich Docker-Images auf dedizierten VMs deployen lassen — Server erstellen, Services darauf starten, Custom Domains mit automatischem SSL hängen, Volumes für Persistenz mounten, Environment-Variablen pflegen, Logs und Metriken ansehen. Im STRYKE Hub bekommst Du dafür eine UI mit einem Cockpit pro Workspace: alle Deine Sliplane-Server in einer Liste, Service-Detail-Seiten mit Deploy-Button, Live-Logs und Ressourcen-Charts. Du musst nicht ins Sliplane-Dashboard wechseln — und wenn Du einen Mitarbeiter einlädst, braucht er keinen Sliplane-Account, sondern nur die richtige Vault-Capability auf dem passenden Eintrag.
Sliplane bietet sechs Instance-Typen an, von kompakt bis Dedicated :
Du kannst Server später rescalen, ohne den Container neu zu bauen (maximal zehn Rescales pro Stunde, siehe unten).
Sechs Rechenzentren stehen zur Auswahl: Falkenstein und Nürnberg in Deutschland (unsere Default-Empfehlung für EU-Kunden und DSGVO-sensitive Workloads), Helsinki in Finnland (zweiter EU-Standort mit guter Nord-Anbindung), Singapur für APAC-Latenz, Ashburn für US-Ostküste und Hillsboro für US-Westküste. Du wählst den Standort beim Erstellen eines Servers — ein späterer Umzug geht nur über neu aufsetzen (Sliplane hat keine Live-Migration), aber dank der deklarativen Service-Konfiguration im Hub ist das meistens eine Sache von Minuten.
Die tagesaktuellen Beträge findest Du jederzeit auf pricing.strykehub.de; im Hub werden sie live aus der zentralen Pricing-Quelle geladen — nie fest einprogrammiert. Abgerechnet wird monatlich über die STRYKE-Rechnung: Du bekommst eine ordentliche deutsche Rechnung mit USt-ID-Ausweis per E-Mail und zahlst per SEPA-Überweisung.
Nach dem Anlegen eines Services (Image, Port, ENV-Variablen, optionale Volumes) drückst Du im Service-Detail auf Deploy. Das Backend schickt den entschlüsselten Bearer-Token an die Sliplane-Steuerungs-API, stößt den Build an, und der Hub streamt den Progress zurück in die UI. Auto-Deploy bei jedem Push auf den Branch lässt sich pro Service als Toggle aktivieren. Pausieren, Unpausen und einen Container stoppen geht genauso über Buttons im Hub — ohne jemals in das Sliplane-Dashboard zu wechseln, ohne dass ein Mitarbeiter einen Sliplane-Account braucht.
Aktuell gilt für Sliplane das „Bring your own Token"-Modell: Du legst in Deinem Sliplane-Account (oder in einem gemeinsam mit STRYKE für Dich angelegten) einen Bearer-Token mit Read/Write-Rechten an und hinterlegst ihn im Hub. STRYKE verschlüsselt diesen Token AES-256-GCM und nutzt ihn ausschließlich serverseitig für Proxy-Calls. Ein vollautomatisches Reseller-Modell mit zentralem STRYKE-Master-Token für Kunden-Provisionierung ist in Order-Pipeline Phase 6 vorgesehen, steht als einschaltbares Feature bereit und wird nach interner Freigabe aktiv geschaltet — Sliplane-Server kosten reales Geld, und dieser Schalter wird erst nach klarer Freigabe aktiv.
Sliplane schützt die API mit klaren Limits, die Du im Hub-Betrieb fast nie spürst — aber sie sind gut zu kennen:
Der Hub zeigt Limits im Fehlerfall transparent an und queued Deploys automatisch, wenn Du bei einem Release-Fenster nahe ans Limit kommst. Für die große Mehrheit der Agentur- und Produktions-Setups liegen diese Werte deutlich über dem Bedarf.
Ja — mit einer Einschränkung zum heutigen Stand. Das Container-Log ist im Hub pro Service abrufbar, Sliplane-Events (Deploy-Start, Build-Complete, Container-Crash) werden in Echtzeit angezeigt. Das vollständige Sliplane-Dashboard mit Live-Streaming-Logs, Ressourcen-Charts über längere Zeiträume und Multi-Service-Metriken-Vergleich landet in Order-Pipeline Phase 6. Die Backend-Routen sind bereits da; das Feature ist reine Frontend-Arbeit auf existierendem Proxy. Beta-Teilnehmer bekommen Zugriff, sobald es in den Staging-Release wandert.
Pro Service hängst Du eine oder mehrere Custom Domains an. Du bekommst im Hub angezeigt, welchen DNS-Eintrag (A- oder CNAME-Record) Du bei Deinem Domain-Provider setzen musst — wenn die Domain selbst bei ALL-INKL via STRYKE liegt, kannst Du den DNS-Editor des Hubs direkt öffnen und den Eintrag mit einem Klick anlegen. Let's Encrypt-SSL wird von Sliplane automatisch für jede verifizierte Domain ausgestellt und erneuert — der Hub zeigt den Ablaufzeitpunkt in der Service-Übersicht, damit Du nie mit einem abgelaufenen Zertifikat überrascht wirst.
Für Datenbank-Container, File-Uploads oder andere persistente Workloads legst Du Volumes im Hub an, hängst sie an einen Service und mountest sie auf einen Pfad. Die Volumes leben außerhalb des Container-Lifecycles — ein Redeploy löscht Daten nicht. Im Hub siehst Du die Volume-Größe, den Mountpoint und kannst Volumes pro Service klonen (z.B. für Staging aus Produktions-Daten). Backup-Snapshots und Automation dafür landet, wie die erweiterten Metriken, in Phase 6 der Order-Pipeline.
Du kannst pro Service beliebige ENV-Variablen anlegen — jede bekommt im Hub einen Secret-Toggle. Mit aktiviertem Secret-Flag wird der Wert nach dem Speichern im Frontend nur noch redacted (mit *****) angezeigt; im Sliplane-API-Response kommt ebenfalls ein leerer String zurück. Nicht-Secret-ENV-Variablen bleiben im Hub sichtbar und auditierbar, damit Team-Mitglieder Konfigurationen nachvollziehen können. Für STRYKE-eigene Production gelten zusätzlich harte Schutzregeln — dieselbe Vorsicht empfehlen wir jedem Kunden-Setup.
Ja — beides mit einem Klick im Service-Detail. Pausieren stoppt den Container, ohne ihn zu löschen (spart Ressourcen auf dem Host, Daten bleiben erhalten). Unpausen startet ihn wieder. Rescale wechselt die Server-Größe (z.B. von Base auf Medium, wenn der Traffic wächst) — das geht live, begrenzt auf zehn Rescales pro Stunde. Zusätzlich lassen sich Services delete-n, was Container und Volume-Verknüpfung (nicht die Volumes selbst) entfernt. Jede dieser Aktionen landet im Audit-Log mit Urheber und Zeitstempel.
ALL-INKL (über die KAS-API) ist unser Partner für klassisches Managed Hosting — Webspace, Domains, Postfächer, MySQL-Datenbanken, WordPress. STRYKE ist registrierter KAS-Reseller, deshalb musst Du weder einen KAS-Account anlegen noch irgendwo KAS-Zugangsdaten eingeben. Du klickst im Hub auf „Hosting bestellen", wir richten den Sub-Account auf unserer Reseller-Infrastruktur ein und geben ihn Dir als fertiges Produkt. Im Hub verwaltest Du alles, was Du sonst im KAS-Backend machen würdest — nur schneller, team-fähig und mit revocable access statt geteilter Passwörter.
ALL-INKL ist ein deutscher Hoster aus Friedrichroda mit einem klassischen Managed-Hosting-Stack: Webspace mit PHP-Unterstützung, MySQL/MariaDB-Datenbanken, unbegrenzt vielen Domains und Subdomains, Postfächern mit Webmail, FTP-Zugängen und einem Software-Installer für WordPress, Joomla, Typo3 und weitere Systeme. Die Steuerung erfolgt normalerweise im KAS-Kundenbackend unter kas.all-inkl.com. STRYKE Hub ersetzt dieses Interface vollständig: Du bekommst im Hub ein Hosting-Cockpit pro Account mit allen Domains, Postfächern, Datenbanken, FTP-Usern, Cronjobs und SSL-Zertifikaten in einer Ansicht — und Du kannst diese Sicht team-fähig teilen, ohne dass jemand das KAS-Passwort kennt.
Nein. Das ist der Kern unseres Modells. STRYKE ist KAS-Reseller und legt Sub-Accounts auf der eigenen Reseller-Infrastruktur an. Du siehst nie ein w012345-Login, nie ein Passwort — der Sub-Account-Login ist für Dich nur eine technische Kennung, kein Zugangsweg. Alle Operationen (Domain anlegen, Postfach erstellen, DNS-Eintrag ändern, WordPress installieren) laufen serverseitig über unsere Reseller-Credentials, die AES-256-GCM verschlüsselt in STRYKEs Umgebung liegen und Deinen Browser nie erreichen. Wenn ein Mitarbeiter Dein Hosting verwaltet und morgen geht, entziehst Du ihm den Zugang per Klick — Du musst kein Passwort ändern, weil er nie eins hatte.
Drei Pakete, passgenau für verschiedene Seiten-Größen und Team-Szenarien:
allinkl-privatplus).allinkl-premium).allinkl-business).Zusätzliche Domains und Postfächer buchst Du als Add-on dazu — die Preise dafür laufen über separate Catalog-Slugs ( email-basic, email-business). Alle Beträge liest der Hub live aus der Pricing-API ; tagesaktuell auf pricing.strykehub.de.
Ja — ALL-INKL erlaubt je nach Paket mehrere eigenständige Domains pro Sub-Account, und der Hub bildet das sauber ab. In der Domain-Übersicht siehst Du alle registrierten Domains mit Status (aktiv, expiriert, DKIM gesetzt ja/nein, SSL ja/nein), kannst eine neue Domain über den Hub bestellen (dann läuft der komplette Registrierungs- und Provisionierungs-Flow über die Order Pipeline) oder eine bereits bei einem anderen Registrar gehaltene Fremd-Domain per DNS-Eintrag auf Deinen Sub-Account zeigen lassen. Jede Domain bekommt ihre eigene DNS-Zone, eigene Subdomains, eigene Postfächer.
Über den Sub-Domain-Manager in der jeweiligen Domain-Detailseite. Du wählst die Parent-Domain (z.B. beispiel.de), trägst den gewünschten Subdomain-Namen ein (blog, shop, staging), optional einen abweichenden DocumentRoot-Pfad, und der Hub legt die Subdomain direkt beim Hoster an. Die Subdomain ist unmittelbar danach routbar — SSL lässt sich pro Subdomain einzeln über Let's Encrypt automatisieren (siehe unten). Subdomains lassen sich jederzeit umbenennen oder löschen; alle Änderungen landen im Aktivitäts-Verlauf.
Der DNS-Editor im Hub deckt alle gängigen Record-Typen ab: A (IPv4), AAAA (IPv6), CNAME (Alias), MX (Mailserver, mit Priority), TXT (SPF, DKIM, Verification-Tokens), SRV (Service-Records, z.B. für XMPP/SIP), NS (Delegation) und CAA (Certificate Authority Authorization). Alle Schreib- und Leseoperationen laufen serverseitig über unsere Hoster-Anbindung — Du musst Dich nirgends einloggen oder eine externe DNS-Oberfläche öffnen. Jede Änderung wird sofort aktiv — bei Änderungen mit hohem Auswirkungs-Risiko (MX, NS) zeigt der Hub eine Bestätigungs-Maske mit Diff, damit kein Flüchtigkeitsfehler einen Mailflow stoppt.
Im Hub wählst Du die Domain, gibst den lokalen Teil an (z.B. info), setzt ein Initial-Passwort und die gewünschte Quota (pro Paket unterschiedlich, üblicherweise pro Postfach zwischen 500 MB und mehreren GB). Nach dem Speichern ist das Postfach sofort nutzbar — per IMAP/POP3, per ALL-INKL-Webmail oder später im Hub-eigenen Webmailer (siehe Kategorie „Webmailer"). Passwörter lassen sich jederzeit im Hub zurücksetzen, ohne dass der Team-Kollege der das Postfach erstellt hat ein altes Passwort kennen muss — jeder mit der passenden Freigabe kann den Reset auslösen.
Ja — alle drei direkt im Hub, pro Postfach:
Das spart den Kontextwechsel ins Hoster-Backend für jede einzelne Einstellung — und Änderungen sind im Aktivitäts-Verlauf nachvollziehbar, statt in einem Admin-Interface zu verschwinden, in das nur eine Person Zugang hatte.
Pro Domain oder Subdomain aktivierst Du Let's Encrypt mit einem einzigen Klick auf den Button „SSL aktivieren" in der Domain-Detailseite. Der Hub schickt den Auftrag an den Hoster, ALL-INKL stellt das Zertifikat automatisch aus und erneuert es danach eigenständig, bevor es abläuft. Der Hub zeigt den SSL-Status (aktiv, ausstehend, Fehler) und das Ablaufdatum in der Übersicht — Du wirst also vorgewarnt, falls ALL-INKL ein Renewal einmal nicht durchbekommt (selten, aber möglich bei DNS-Verifizierungs-Problemen). Kostet extra nichts; Let's Encrypt ist in allen Paketen inkludiert.
Ja, FTP-Benutzer legst Du im Hub komplett verwalten: Anlegen, Pfad-Scope setzen (welche Verzeichnisse der User sehen darf), Passwort setzen, aktivieren, deaktivieren, löschen. Passwort-Rotation läuft wie überall im Hub: Du setzt einen neuen Wert, der Hub überträgt die Änderung an den Hoster und der Aktivitäts-Verlauf protokolliert, wer es wann gemacht hat. ALL-INKL unterstützt sowohl FTP als auch sFTP (Port 22); der Hub zeigt Dir in der FTP-Detailseite beide Verbindungsdaten.
Über den Datenbank-Manager im Hub. Du klickst „Datenbank anlegen", gibst einen Namen, wählst den Zeichensatz (UTF-8 ist Default), setzt ein Passwort — fertig. ALL-INKL liefert Dir Host, Port und Datenbank-Nutzer, und der Hub zeigt Dir dazu einen direkten phpMyAdmin-Link, der die Anmeldung als Einmal-Token mitgibt, damit Du kein separates Passwort abtippen musst. Datenbank-Löschungen laufen mit Bestätigungs-Maske (Name tippen) — Rollback gibt es nicht; das steht explizit im Aktivitäts-Verlauf, damit im Nachgang klar ist, wer was gelöscht hat.
Ja, direkt im Hub. Du trägst den auszuführenden Pfad bzw. URL ein, wählst das Zeitintervall (Minute, Stunde, Tag, Wochentag, Monat in klassischer Cron-Syntax), optional eine E-Mail-Adresse für Fehlerbenachrichtigungen. Cronjobs werden serverseitig bei ALL-INKL ausgeführt — keine zusätzliche STRYKE-Infrastruktur dazwischen. Alle Ausführungs-Logs landen wie gewohnt im Log-Verzeichnis Deines Hosting-Accounts; der Hub zeigt aktuelle Laufzeiten als Hinweis in der Cronjob-Liste.
Ja — der Software-Installer von ALL-INKL ist komplett in den Hub integriert. Du wählst eine Ziel-Domain oder Subdomain, pickst das Paket (WordPress ist die häufigste Wahl, daneben Joomla, Typo3, Drupal, phpBB, Nextcloud und weitere), legst Admin-Credentials und Site-Titel fest, und der Installer zieht das Paket automatisch. Nach der Installation bekommst Du im Hub direkt den „Admin-Bereich öffnen"-Link — inklusive Auto-Login, falls es WordPress ist und der WordPress-Connector aktiv ist. Für produktive Setups empfehlen wir, direkt nach der Installation ein Backup in der Hoster-Oberfläche anzustoßen, da eine Hub-native Backup-Funktion für ALL-INKL aktuell noch nicht verfügbar ist.
Drei zusätzliche Bausteine, die im Hub sichtbar sind:
Der Webmailer im Hub ist direkt auf Deine ALL-INKL-Postfächer abgestimmt. Er spricht ausschließlich Deine ALL-INKL-Postfächer per IMAP und SMTP — kein Gmail-OAuth, kein Outlook, kein Microsoft Graph. Dadurch bleiben die Credentials AES-256-GCM verschlüsselt im Credential Vault, werden serverseitig entschlüsselt und zum Provider geleitet — der Browser sieht nie den Postfach-Login. Das Feature landet im Rahmen von Order-Pipeline Phase 6; Backend-Ports und Routen sind vorbereitet, die Postfach-Operationen nutzen im Hintergrund native IMAP-Befehle statt einer Drittanbieter-Abstraktion.
Ja — im Rahmen von Phase 6 der Order-Pipeline. Der Hub-Webmailer ist für das Lesen, Beantworten, Verfassen, Verschieben, Markieren und Löschen von Nachrichten ausgelegt, inklusive Anhängen, Ordnerverwaltung und Suche über den IMAP-Index. Für jedes Deiner angelegten ALL-INKL-Postfächer bekommst Du im Hub eine Mail-Ansicht, die auf denselben IMAP/SMTP-Kanälen läuft wie der native ALL-INKL-Webmailer, nur in der STRYKE-UI und ohne Kontextwechsel. Bis das Feature produktiv ist, nutzt Du den Webmailer von ALL-INKL oder klassische IMAP-Clients (Thunderbird, Apple Mail, Outlook) — alle Postfachdaten, die der Hub dafür braucht, kannst Du mit einem Klick als vorkonfiguriertes Setup exportieren.
Ausschließlich für Postfächer, die über unsere ALL-INKL-Reseller-Infrastruktur angelegt wurden. Gmail, Outlook, Microsoft 365, iCloud und andere externe IMAP-Accounts gehören nicht zum Funktionsumfang des Hub-Webmailers — er ist gezielt für Deine ALL-INKL-Postfächer gebaut, damit jede Operation sauber und ohne Umwege läuft. Für Fremd-Postfächer nutzt Du weiterhin den gewohnten Client; der Hub konzentriert sich auf die Postfächer, die er direkt verwaltet.
Funktional ja — in einigen Punkten sogar mehr. Weil wir auf nativen IMAP-Befehlen sitzen statt auf einer Drittanbieter-Abstraktion, können wir Mailbox-Operationen (Verschieben, Löschen, Markieren, Suchen) effizienter bündeln und in Batches abarbeiten. Gleichzeitig profitiert der Hub-Webmailer vom STRYKE-Designsystem: einheitliche Tastaturkürzel mit den restlichen Hub-Modulen, Dark Mode, gleiches Such-Bedienkonzept wie in Vault und Hosting. Reine E-Mail-Verwaltung auf Provider-Ebene (DKIM-Setup, Spam-Filter, Autoresponder) bleibt im Hosting-Bereich — das ist eine klare Trennung zwischen „Mail schreiben und lesen" (Webmailer) und „Postfach verwalten" (Hosting).
Ja. Der Webmailer listet alle verbundenen ALL-INKL-Postfächer in einer Sidebar — pro Workspace, pro Brand und pro Projekt sortiert. Du springst zwischen Postfächern mit einem Klick, ohne Neu-Login; die Credentials bleiben serverseitig im Vault und der Hub hält nur kurzlebige Session-Cookies für die IMAP-Verbindung. Eine Mail von Postfach A nach Postfach B verschieben geht über klassische Kopier-Operationen (IMAP unterstützt kein direktes Server-zu-Server-Move zwischen zwei verschiedenen Accounts); der Hub macht das transparent für Dich. Mit den Team-Rollen und der Vault-Capability USE kannst Du einem Kollegen Zugriff auf ein Postfach geben, ohne dass er jemals das Postfach-Passwort sieht — der USP aus Vault und Team-Management gilt auch hier.
Der Hub-Webmailer wird von Tag eins auf Responsive gebaut — dieselbe UI-Disziplin wie die restlichen Hub-Module. Listen-Ansicht, Mail-Detail, Schreiben-Dialog funktionieren auf Desktop, Tablet und Smartphone ohne separate Apps. Native iOS- oder Android-Apps sind aktuell nicht geplant — Mobile-IMAP-Clients wie Apple Mail oder Outlook-Mobile sind ausgereift genug, dass eine eigene App Dir keinen echten Mehrwert bringen würde. Statt doppelter Infrastruktur konzentrieren wir uns darauf, dass der Browser-Client auf dem Handy genauso sauber funktioniert wie am Desktop.
Der Webmailer ist als Phase 6 der Order-Pipeline eingeplant. Die Infrastruktur-Bausteine sind vorbereitet: IMAP-Library und SMTP-Library sind im Backend verfügbar, Vault-Integration für Postfach-Credentials ist über den Credential Vault abgebildet, und die Routing-Schicht für Live-Mail-Operationen ist mitgedacht. Was noch offen ist, ist die eigentliche UI-Arbeit und das sorgfältige Testen gegen reale ALL-INKL-Postfächer. Einen verbindlichen Launch-Termin geben wir erst nach einer stabilen Testphase bekannt — Beta-Teilnehmer bekommen Zugriff, sobald der Webmailer produktionsreif getestet ist, und Feedback aus dieser Runde fließt direkt in die letzten Feinheiten vor dem allgemeinen Launch.
Deine Mails liegen dort, wo sie hingehören — auf dem ALL-INKL-IMAP-Server deines Postfachs. Der Hub ist keine Archiv-Plattform und kopiert keine Mail-Inhalte in eine eigene Datenbank. Was im Hub läuft, ist ein schlanker IMAP-Proxy: Beim Öffnen eines Ordners liest der Server die Message-Header über unsere IMAP-Verbindung live vom Postfach, beim Öffnen einer einzelnen Mail wird nur der angeforderte Body nachgeladen. Für das Tempo setzen wir einen kurzlebigen In-Memory-Cache pro Session ein (Header-Cache für Ordnerlisten, IMAP-IDLE für neue Nachrichten) — dieser Cache verfällt beim Logout oder nach wenigen Minuten Inaktivität. Persistent gespeichert werden bei uns nur Metadaten, die für die Hub-Features zwingend nötig sind: Audit-Log-Einträge (wer hat wann welches Postfach geöffnet), Einstellungen wie Signaturen und Entwürfe (wenn Du sie serverseitig speicherst) sowie Flags wie „Ordner-Favoriten". Das heißt umgekehrt: Wenn Du ein Postfach bei ALL-INKL löschst, sind die Mails weg — der Hub hat keine Zweitkopie. Wer ein Archiv braucht, exportiert es aus dem nativen Webmailer oder setzt einen klassischen IMAP-Client als Backup-Knoten ein.
Das ist explizit unterstützt — und einer der Gründe, warum der Hub-Webmailer den nativen ALL-INKL-Webmailer in Team-Szenarien ablöst. Weil Postfach-Credentials nie im Browser landen, sondern pro Request aus dem Credential Vault serverseitig entschlüsselt werden, kann jedes Team-Mitglied mit Vault-Capability USE oder ADMIN sein eigenes IMAP-Login parallel aufbauen — es gibt keinen „einen Login, den sich alle teilen"-Konflikt, weil kein Klartext-Passwort durch mehrere Browser geistert. IMAP selbst ist Multi-Session-fähig: Zwei gleichzeitig geöffnete Verbindungen zum selben Postfach sehen Ordner-Inhalte synchron, weil jede Mail-Aktion (Löschen, Verschieben, Flagge setzen) über serverseitige IMAP-Befehle läuft und das Postfach beim Provider die Wahrheit hält. Beim Senden nutzt der Hub unser SMTP-Versand über SMTP — auch hier ist parallel kein Problem, weil jeder Send-Request eine eigene SMTP-Transaktion ist. Was der Hub zusätzlich liefert: Jede Team-Aktion landet im Permission-History-Audit mit Nutzer-Angabe, Zeitstempel und Kaskaden-ID — wenn zwei Kollegen beim Postfach-Aufräumen durcheinanderkommen, ist nachvollziehbar, wer welche Mail verschoben oder gelöscht hat. Entzieht der Owner einem Kollegen die USE-Capability, stoppt dessen nächste IMAP-Session sofort — kein Postfach-Passwort-Wechsel nötig (Revocable-Access-USP).
Anhänge: Der Hub lädt Attachments beim Lesen einer Mail direkt vom ALL-INKL-IMAP-Server in Deinen Browser-Download — ohne Zwischenspeicher auf unseren Servern. Beim Schreiben werden Anhänge per MIME-Multipart über unser SMTP-Versand an den SMTP-Server übergeben; die klassischen ALL-INKL-Postfach-Limits (z.B. ~20 MB Message-Size bei vielen Paketen) gelten 1:1 weiter, weil wir nichts verändern — der Hub ist Proxy, nicht Filter. Der Upload zeigt Dir vor dem Abschicken, ob die Gesamtgröße innerhalb des Provider-Limits liegt. Entwürfe: Der Hub speichert Drafts standardmäßig in den Drafts-Ordner deines Postfachs per IMAP-APPEND — das heißt, angefangene Mails sind auch im nativen Webmailer, in Thunderbird oder Apple Mail sichtbar und Du kannst nahtlos zwischen Clients wechseln. Wer ausschließlich im Hub arbeitet, kann zusätzlich lokale Hub-Drafts aktivieren (serverseitig beim Hub gespeichert, an User + Postfach gebunden, AES-256-GCM verschlüsselt) — praktisch für Formularfelder wie Empfänger-Vorschläge, die der Webmailer aus Team-Kontakten vervollständigen soll. Signaturen: Liegen als Postfach-gebundene Einstellung im Hub-User-Profil (HTML und Plain-Text-Variante, optional mit Team-Logo); die Signatur wird beim Senden serverseitig in die Mail injiziert, bevor unser SMTP-Versand die Transaktion startet. So hast Du pro Team-Postfach dieselbe Marken-Signatur, unabhängig davon, welcher Kollege gerade sendet — ohne dass Du einzeln pro Mitarbeiter eine Signatur in ALL-INKL pflegen musst.
Bestellen läuft im Hub als Self-Service: Du wählst ein Hosting-Produkt, schickst die Bestellung ab, bekommst automatisch eine deutsche Rechnung per E-Mail, überweist per SEPA — und sobald Dein Zahlungseingang erkannt wird, richtet der Hub den Sub-Account, die Domain, das erste Postfach, Let's-Encrypt-SSL und die Willkommens-Mail automatisch ein. Niemand aus dem Team muss je ins ALL-INKL-Backend oder ins Sliplane-Dashboard, um eine Bestellung manuell auszulösen.
In der Sidebar unter „Hosting" findest Du die Wizards für die drei Bestell-Strecken: Neues ALL-INKL Hosting, Neuer Sliplane Server (Freigabe erforderlich) und Domain registrieren. Jeder Wizard führt Dich durch Paketwahl, gewünschte Domain und Basis-Konfiguration und legt am Ende eine offene Bestellung an. Alle Preise liest der Wizard live aus unserer Preis-Quelle — es gibt keinen fest einprogrammierten Preis. Nach dem Absenden landest Du auf der Bestell-Detailseite mit Live-Statusanzeige.
Der Hub durchläuft einen klaren Ablauf: (1) Deine Bestellung wird mit Provider (ALL-INKL, Sliplane oder reine Domain), gewünschter Domain und Konfiguration angelegt. (2) Im selben Schritt bekommst Du eine deutsche Rechnung per E-Mail, die Bestellung geht in „Warten auf Zahlung". (3) Wir prüfen alle 5 Minuten automatisch den Zahlungseingang. (4) Sobald Deine Überweisung erkannt wird, schaltet die Bestellung auf „Bezahlt" und wandert in die Einrichtungs-Queue (ALL-INKL und Sliplane laufen getrennt). (5) Der Einrichter legt idempotent Sub-Account, Domain (bei Registrierung), erstes Postfach, Let's-Encrypt-SSL und die Willkommens-Mail an — jeder Schritt prüft vorher den Ist-Zustand und überspringt, was schon erledigt ist. (6) Am Ende markiert der Hub die Bestellung als „Aktiv" und Du kannst sofort loslegen.
Der Ablauf ist linear: Offen → Warten auf Zahlung → Bezahlt → Wird eingerichtet → Aktiv. Alternativ-Endstatus sind Fehlgeschlagen (alle automatischen Versuche aufgebraucht) und Storniert (Du hast storniert, solange die Bestellung noch offen oder auf Zahlung wartet). Im Hub siehst Du diese Status als Timeline auf der Bestell-Detailseite — jeder Übergang trägt Zeitstempel (Zahlungseingang, Einrichtungs-Beginn, Fehlerzeitpunkt), und jeder Statuswechsel landet im Aktivitäts-Verlauf, damit nachvollziehbar bleibt, wer wann was ausgelöst hat.
Per SEPA-Überweisung auf eine ordentliche deutsche Rechnung. Sobald Du eine Bestellung abschickst, erzeugt der Hub automatisch einen Beleg mit Rechnungs-Nummer, Positionen, Deiner Adresse und dem Zahlungsziel und schickt ihn Dir per E-Mail; gleichzeitig findest Du ihn im Hub unter "Meine Rechnungen". Sobald der Zahlungseingang erkannt wird, schaltet die Bestellung binnen 5 Minuten auf Bezahlt und die automatische Einrichtung startet — ohne manuellen Schritt auf Deiner oder unserer Seite.
Der Einrichter ist auf Wiederholbarkeit ausgelegt: jeder Schritt (Sub-Account, Domain, Mailbox, SSL, Rechnung, Willkommens-Mail) ist idempotent, damit ein Crash in der Mitte nicht zu halb-eingerichteten Accounts führt. Bei einem Fehler wird der Schritt automatisch mit exponentiellem Backoff wiederholt — maximal drei Versuche pro Bestellung. Nach drei Fehlversuchen wird die Bestellung als „fehlgeschlagen" markiert und unser Team informiert. Wir finden die Ursache (z. B. Domain-Konflikt, Rate-Limit beim Provider), lösen sie manuell auf und starten die Einrichtung neu. Du bekommst in dem Fall eine E-Mail mit Erklärung und Lösungsschritten; die Rechnung bleibt bestehen, aber Deine Zahlung wird nie „verschluckt".
Ja. Unter Meine Bestellungen siehst Du alle Deine Bestellungen mit Filter nach Status, Provider und Zeitraum. Ein Storno ist möglich, solange Deine Bestellung noch offen ist oder auf Zahlung wartet — nach dem Zahlungseingang läuft die Einrichtung automatisch durch, und eine bereits laufende Einrichtung brechen wir nicht mitten ab (Risiko von Halb-Zuständen). Änderungen an Paketgröße oder Domain während einer laufenden Bestellung sind nicht vorgesehen — in dem Fall einfach stornieren und neu bestellen oder nach Aktivierung das bestehende Paket upgraden.
Sliplane-Bestellungen lösen pro Server reale Kosten aus — oft höhere Summen als ein einzelnes ALL-INKL-Paket. Deshalb gilt: Sliplane-Einrichtung läuft erst nach einer internen Freigabe pro Bestellung. In der Praxis heißt das: Der Wizard legt Deine Bestellung sauber an, die Rechnung wird gestellt, Zahlung läuft ganz normal — aber der letzte Schritt, das Aufrufen des Sliplane-Einrichters, wird erst dann ausgeführt, wenn unser Team die Strecke freigeschaltet hat. Das kostet ein paar Minuten mehr, verhindert aber teure Fehlbuchungen in der frühen Phase.
Jede Bestellung ist an eine Firma gebunden — die Firma ist die Rechnungs-Einheit, auf die der Beleg ausgestellt wird. Wer für eine Firma bestellen darf, regelt das Firmen-Rechte-Modell mit zwei Stufen: Buchen (nur bestellen) und Buchen + Verwalten (bestellen plus Firmenstammdaten und Rechnungsadressen pflegen). Der Owner einer Firma hat implizit immer Buchen + Verwalten — Du kannst also ohne Setup für Deine eigene Firma bestellen. Delegierte Team-Mitglieder brauchen einen explizit vergebenen Firmen-Rechte-Eintrag, der jederzeit wieder entzogen werden kann. Bevor der Hub irgendeine Bestellung auslöst, prüft er diese Berechtigung — ohne passendes Recht wird die Bestellung sofort mit einer Zugriff-verweigert-Meldung abgelehnt. Für die Nachvollziehbarkeit trennt der Hub zwei Felder: der Rechnungs-Owner ist die Firma, der tatsächlich auslösende Nutzer wird zusätzlich gespeichert. So bleibt exakt nachvollziehbar, welcher Mitarbeiter welche Bestellung im Namen welcher Firma gebucht hat — DSGVO-Accountability ohne Passwort-Sharing.
An drei Stellen, alle redundant. (1) E-Mail: Die offizielle Rechnung kommt als PDF-Anhang an die Rechnungs-Adresse der Firma, sobald die Bestellung in „Warten auf Zahlung" wechselt. (2) Hub-UI: Auf der Bestell-Detailseite siehst Du die Rechnungsnummer (menschen-lesbar, z. B. RE-2026-0042) und den PDF-Download prominent platziert. (3) Abrechnungs-Bereich: Im Abrechnungs-Bereich findest Du alle Belege mit Zahlungsstatus und Download-Link. Wichtig für die Buchhaltung: Belege werden GoBD-konform 10 Jahre archiviert — Du musst selbst keine Kopien vorhalten. Bei einem Storno im erlaubten Fenster wird automatisch eine passende Gutschrift erzeugt, damit keine offenen Belege in Deiner Buchhaltung bleiben.
Nichts Schlimmes — der Hub ist genau für diesen Fall gebaut. Sobald Du „Jetzt bestellen" geklickt hast, existiert die Bestellung vollständig auf unserer Seite: als Bestellung, als Beleg und (nach Zahlung) als Job in der Einrichtungs-Queue. Der Browser hält zu keinem Zeitpunkt kritischen Zustand. Schließt Du das Fenster mitten im Wizard bevor „Jetzt bestellen" geklickt wurde, ist die Eingabe weg — der Hub speichert absichtlich keine halb-ausgefüllten Bestellungen. Nach dem Absenden läuft alles unabhängig weiter. Beim nächsten Login zeigt Meine Bestellungen den aktuellen Status in Echtzeit. Stirbt ein Einrichtungs-Schritt mittendrin, greift die Idempotenz-Garantie: jeder Teilschritt (Sub-Account, Domain, Postfach, SSL) prüft vorher den Ist-Zustand und überspringt, was schon erledigt ist — Du bekommst keine doppelten Domains, keine Duplikat-Postfächer, keine doppelte Rechnung. Nach drei Fehlversuchen geht die Bestellung auf „fehlgeschlagen" und unser Team wird informiert. Du bekommst zusätzlich immer eine E-Mail-Benachrichtigung: Willkommens-Mail bei Erfolg, Fehler-Info mit Lösungsschritten bei Misserfolg. Selbst wenn Du 24 Stunden offline bist, verpasst Du den Status nicht.
STRYKE Hub bestellt Domains eigenständig über einen offiziellen Domain-Reseller . Das gilt sowohl für Bestellungen, die Teil eines neuen Hosting-Pakets sind, als auch für reine Domain- oder Postfach-Zusatzbuchungen. Auch hier gilt: keine Drittanbieter-Konten, keine manuellen Panels, keine fest einprogrammierten Preise — alles läuft durch die Order Pipeline und die Pricing-API.
Im Domain-Wizard wählst Du die gewünschte Domain (z. B. meineagentur.de), der Hub prüft live beim Registrar, ob die Domain frei ist, zeigt Dir den exakten Preis aus unserer Preis-Quelle und erzeugt bei „Jetzt bestellen" eine Bestellung. Die Registrierung läuft dann über denselben automatischen Ablauf wie ein Hosting-Paket: Rechnung → Zahlung → Registrierung beim Registrar → Default-DNS-Zone anlegen → Bestätigungs-Mail. Deine Inhaber-Daten werden beim ersten Mal aus Deinen Workspace-Stammdaten erzeugt und danach wiederverwendet — Du musst Deine Adresse nicht für jede Domain neu tippen.
Aktuell liegen Preise für folgende TLDs in der Pricing-API:,,,,,,. Das deckt die typischen Agentur-Szenarien (Firmen-Domain, internationale Handelsmarke, EU-weite Projekte, Tech-Produkte, Online-Shops, Kampagnen-Seiten) zuverlässig ab. Weitere TLDs lassen sich auf Anfrage ergänzen — dafür legt das STRYKE-Team einen neuen Pricing-Eintrag im Admin-Panel an, und ab Cache-Ablauf (max. 5 Min) ist die neue TLD im Wizard wählbar. Technisch kann der Registrar deutlich mehr, die Einschränkung ist rein preisseitig — wir wollen keine TLD freischalten, deren Gebühren wir nicht sauber abbilden.
Ja. Im Wizard wählst Du statt „Neu registrieren" die Option „Transfer", gibst die Domain und den Auth-Code (EPP-Code) des bisherigen Registrars an und bestätigst die Inhaberdaten. Der Hub erzeugt wie bei einer Neuregistrierung eine Bestellung, Du bekommst eine Rechnung über die Transfer-Gebühr, und nach Zahlung startet der Transfer beim Registrar. TLD-spezifische Fristen (bei .de sehr kurz, bei .com bis zu 5 Tage, je nach abgebendem Registrar) zeigt der Hub im Status; in der Zwischenzeit bleibt die Domain beim alten Anbieter aktiv — wir schalten sie erst auf STRYKE-DNS, wenn der Transfer bestätigt ist. Hinweis: Für manche TLDs braucht der Transfer eine Freigabe des alten Registrars per Mail — der Hub erinnert Dich daran und zeigt den erwarteten Ablauf als Checkliste.
Nach erfolgreicher Registrierung legt der Worker (oder bei Zusatz-Domains auf bestehendem Hosting direkt der ALL-INKL-Sub-Flow) folgendes an: (1) Eine Default-DNS-Zone mit A-Record auf den STRYKE-Sub-Account-Server (bei ALL-INKL-Paketen) bzw. einen Park-Eintrag bei reiner Domain-Bestellung. (2) MX-Records für die ALL-INKL-Mailserver, falls ein Postfach im selben Bestellvorgang ausgewählt wurde. (3) SPF-TXT-Record als Basis-Schutz gegen Spoofing. (4) Let's Encrypt SSL, automatisch ausgestellt sobald die Domain beim Hoster ankommt — bei Neuregistrierungen klappt das meist innerhalb von 10–30 Minuten, bei Transfers erst nach abgeschlossenem Transfer. Alle Einträge kannst Du danach im DNS-Editor frei anpassen oder löschen — die Default-Einrichtung ist nur ein sicherer Startzustand.
Zwei Wege, je nach Szenario. Variante 1 — Postfach in bestehendem ALL-INKL-Paket: Du legst im Hosting-Dashboard unter „E-Mail → Postfach erstellen" einfach ein neues Postfach an. Das Postfach ist im inkludierten Kontingent Deines Pakets enthalten — kein separater Bestellvorgang, keine neue Rechnung, solange Du im Limit bleibst. Variante 2 — Eigenständige E-Mail-Pakete (Basic oder Business) sind für Kunden gedacht, die nur Mail wollen, keinen Webspace. Auch diese laufen durch den normalen Bestell-Ablauf mit Rechnung und automatischer Einrichtung. Postfach-Quota, Weiterleitungen, Autoresponder und Spamfilter konfigurierst Du nach Aktivierung wie in der Kategorie „ALL-INKL Managed Hosting" beschrieben.
Technisch sind beide dasselbe — ein Eintrag beim Registrar, den Du im Hub vollständig verwaltest. Der Unterschied liegt im Preismodell und im automatisch angelegten Zubehör. Eine Standalone-Domain (Order vom Typ) kostet Dich nur die jährliche Registrar-Gebühr aus der Pricing-API, hat aber keinen Webspace, kein Postfach, keinen automatischen SSL-Host. Sie eignet sich für Weiterleitungen, Kampagnen-Redirects, Domain-Reservierungen oder wenn Du selbst DNS-Einträge zu externen Services (z.B. Vercel, Notion, Landing-Page-Builder) pflegst. Eine Domain im Hosting-Paket ist an Deinen ALL-INKL-Sub-Account gebunden: inklusive DocumentRoot, DNS mit automatischem A- und MX-Record, Let's Encrypt SSL, anlegbaren Subdomains und Postfächern im Kontingent. Du kannst Standalone-Domains jederzeit nachträglich auf ein Hosting-Paket routen lassen — der Hub legt dann die fehlenden Records an und aktiviert SSL.
Sobald die automatische Einrichtung durch ist, ist die Domain bei ALL-INKL im Sub-Account registriert und Deine Bestellung steht auf „Aktiv". Für die tatsächliche globale Erreichbarkeit zählen aber noch zwei Faktoren: (1) DNS-Propagation — A/MX/TXT-Records brauchen bis zu mehreren Stunden, bis sie bei allen Resolvern ankommen (bei .de-Domains meist unter 30 Minuten, bei Transfers auch mal länger). Der Hub zeigt den letzten DNS-Lookup-Status in der Domain-Detailseite, damit Du erkennst, wann die Welt Deine Einträge sieht. (2) SSL-Zertifikat — Let's Encrypt benötigt eine erfolgreiche HTTP-Challenge auf der Ziel-Domain, was erst nach abgeschlossener DNS-Propagation klappt; bei frischen Domains empfehlen wir, 10–15 Minuten nach Aktivierung einen zweiten SSL-Renewal-Versuch zu starten, wenn der erste noch nicht durchging. Für Postfächer sind IMAP und SMTP unmittelbar nach Anlage erreichbar — der Versand nach außen kann allerdings erst dann zuverlässig starten, wenn der empfangende Server die neuen MX- und SPF-Records Deiner Domain sieht.
Der Campaign Link Tracker ist ein Hub-natives Kampagnen-Modul für Agenturen und Inhouse-Teams: personalisierte Tracking-Links pro Influencer oder Kanal, Echtzeit-Klicks und Conversions, Read-Only-Stats für den Endkunden — und das alles DSGVO-konform, ohne Cookies, ohne Fingerprinting, ohne Drittanbieter. Das Modul läuft komplett auf STRYKE-Sliplane-Infrastruktur und benötigt KEINE Hosting-Credentials — jeder Hub-Nutzer kann es sofort einsetzen, auch im Free Mode.
Der typische Use Case aus: eine Agentur managt eine Influencer-Kampagne für einen Kunden. Pro Influencer generiert sie im Hub einen personalisierten Tracking-Link wie /go/fruehlingssale/lisa, verteilt ihn an den Creator, misst live, wie viele Klicks und Conversions jeder einzelne Link bringt — und gibt dem Auftraggeber einen Read-Only-Zugang zum Analytics-Dashboard. Das funktioniert genauso für Newsletter-Kampagnen (Link pro Segment), Podcast-Sponsorings (Link pro Show), Print-Anzeigen mit QR-Code, Messe-Auftritte (Link pro Stand) oder interne A/B-Tests über verschiedene Kanäle. Solange es darum geht, „welcher Kanal bringt mir welchen Traffic und welche Conversions", ist der Campaign Tracker schneller eingerichtet als jedes klassische Analytics-Setup und dabei deutlich DSGVO-freundlicher.
Nein. Der Campaign Tracker ist eine Hub-native USP-Säule, die auch OHNE hinterlegtes Sliplane- oder ALL-INKL-Konto funktioniert. Jeder Hub-Nutzer kann sofort nach dem Login eine Kampagne anlegen, Tracking-Links generieren, Viewer einladen und Stats einsehen. Du musst keine externe Domain verbinden, keinen Server provisionieren und keine API-Schlüssel hinterlegen — das Kampagnen-Modul läuft komplett auf STRYKEs eigener Infrastruktur. Wenn Du später willst, kannst Du die Redirect-Domain (/go/*) auf eine eigene Kampagnen-Subdomain legen — aber das ist optional, nicht Voraussetzung.
Das Format ist https://[domain]/go/[campaignSlug]/[linkSlug] — zum Beispiel /go/fruehlingssale/lisa. Beide Slugs werden im Backend strikt gegen eine Allowlist validiert (eine strikte Zeichen-Allowlist), damit keine URL-Injection möglich ist. Beim Klick auf den Link passiert exakt das: (1) der Hub prüft serverseitig, ob Kampagne und Link existieren; (2) es wird ein Klick-Eintrag mit Zeitstempel, gehashter IP, grobem Device-String und Referer (falls gesendet) gespeichert; (3) der Nutzer wird sofort auf die hinterlegte Ziel-URL weitergeleitet. Kein Cache, keine Cookie-Header, keine Session, keine Zwischen-Seite, keine externen Tracker — der Nutzer merkt nichts außer einer minimalen Weiterleitung. Der Endpoint ist rate-limited, damit Bot-Scraping keine Statistiken verfälscht.
Geloggt wird pro Klick: timestamp, ipHash (SHA-256 mit festem Server-Salt-Pepper, NIE die Klartext-IP), ein abgeleiteter device-String (mobile / desktop / tablet, basierend auf User-Agent), der referer-Header (falls der Browser ihn sendet) und optional ein grob-regionaler country-Code. Bewusst nicht geloggt werden: Klartext-IPs (nirgends — weder in DB, Logs noch Traces), der vollständige User-Agent-String, City-Level-Geolocation, Fingerprinting-Daten (Canvas, WebGL, Screen-Resolution), Cookies oder Session-Identifier. Conversions landen als ein Conversion-Eintrag mit dem Webhook-Payload als JSON-Referenz — ebenfalls ohne IP, ohne Cookie. Jede dieser Begrenzungen ist strikt im Code umgesetzt — nicht nur in den Dokumenten versprochen.
Für reine Klick-Messung mit dem Campaign Tracker: Nein. Da keine Cookies gesetzt werden, keine Tracker-Scripts im Browser landen und IPs ausschließlich als gehashter Wert auf unserem Server existieren, fällt die Messung unter den Bereich „technisch notwendige Weiterleitung mit anonymisierter Reichweitenmessung" — das ist ohne separate Cookie-Einwilligung nach TTDSG/DSGVO erlaubt. Was Du trotzdem tun solltest: in Deiner Datenschutzerklärung kurz erwähnen, dass Du STRYKE Campaign Tracker zur Reichweitenmessung nutzt und IPs nur gehasht verarbeitet werden. Wenn Du Conversions loggst, die personenbezogene Daten enthalten (Name, E-Mail, Bestellsumme), gelten für diese Werte natürlich die normalen DSGVO-Regeln deines Shops oder CRMs — das ist unabhängig vom Campaign Tracker. Im Zweifel: mit Deinem Datenschutzbeauftragten abstimmen, aber der Tracker selbst ist so gebaut, dass er das Banner nicht auslöst.
Du lädst den Kunden im Kampagnen-Bereich als Mitglied mit der Rolle Viewer ein. Der Kunde bekommt keinen neuen Login, keinen Token-Link, keine Magic-URL — der Kunde meldet sich als regulärer Hub-Nutzer an (Free-Account reicht) und bekommt dann ausschließlich Read-Only-Zugriff auf diese eine Kampagne. Konkret heißt das: Er sieht sie in /dashboard/link-tracker, kann die Detailseite und das Stats-Dashboard öffnen, aber er kann keine Links anlegen, keine Mitglieder einladen und keine Kampagnen-Einstellungen ändern — alles gesteuert durch unsere Berechtigungs-Prüfung. Zieht der Kunde weiter, entfernst Du ihn mit einem Klick in der Mitglieder-Liste — der Zugriff ist in derselben Sekunde weg, ohne dass Du irgendwo ein Passwort wechseln musst. Jeder Zugriff-Grant und -Entzug landet automatisch im Aktivitäts-Verlauf mit Ressource-Typ „Kampagne", damit Du in jedem Audit sauber nachweisen kannst, wer wann Einsicht hatte.
Zusätzlich zum Klick kannst Du Conversions messen — also ob aus dem Klick auch eine Bestellung, Anmeldung oder ein Download wurde. Dafür stellt der Hub den öffentlichen Endpoint POST /api/campaigns/:id/webhook/conversion bereit, den Du aus Deinem Shop, CRM oder Landingpage-Builder aufrufst. Die Zuordnung zum konkreten Link passiert über einen ref-Parameter im Payload (z.B. „ref": „lisa" für den Link-Slug) oder alternativ über Referer-Matching. Payload-Größe ist auf 32 KB limitiert, der Endpoint ist rate-limited, und der Body landet als JSON in — Du entscheidest, welche Felder (Bestellsumme, Produkt-ID, Warenkorb) Du mitgeben willst. Wichtig: Der ref-Parameter wird ausschließlich für die Zuordnung genutzt, niemals als -Key interpretiert. Im Analytics-Dashboard siehst Du danach pro Link Klicks, Conversions und Conversion-Rate nebeneinander.
Das Dashboard unter /dashboard/link-tracker/[id]/stats bündelt mehrere Ansichten: (1) ein Bar-Chart „Klicks pro Link", damit Du sofort siehst, welcher Influencer oder Kanal am besten performt. (2) eine Timeline-Line-Chart, die Klicks pro Tag aggregiert — perfekt, um Kampagnen-Peaks, Wochenend-Effekte und Nachlauf zu erkennen. (3) eine Tabelle mit Conversions pro Link inklusive Conversion-Rate. (4) eine Device-Verteilung (mobile/desktop/tablet), damit Du siehst, ob Deine Zielgruppe eher aus der Hosentasche oder vom Schreibtisch kommt. Das Dashboard passt sich farblich automatisch an den Dark/Light-Mode Deines Hubs an. Die Daten werden live ausgeliefert; ein CSV-Export für die Reporting-Runde beim Kunden ist auf der Roadmap.
Ja — genau dafür ist „Custom Subdomains" gebaut. Statt Deine Tracking-Links auf go.strykehub.com zu zeigen, hinterlegst Du im Hub unter /dashboard/link-tracker/domains eine beliebige FQDN aus Deinem Besitz: Subdomain (klick.kundendomain.de, go.meine-agentur.de) oder Apex (trackingmarke.de). Das hat zwei Vorteile: (a) Brand-Ownership — Dein Kunde sieht eine Domain, die zur Kampagne passt, nicht einen fremden Tracker; (b) volle Kontrolle — ziehst Du die Domain später bei einem anderen Anbieter, nimmst Du die URL-Struktur einfach mit. Der Flow ist als 3-Step-Wizard im Fullscreen aufgebaut: (1) Hostname eingeben und gegen ^(?=.{1,253}$)([a-z0-9]...)(\.[a-z0-9]...)+$ validieren — RFC-1035-konform, lowercase, kein Trailing-Dot; (2) TXT-Record plus Routing-Record setzen und über „Jetzt prüfen" verifizieren lassen; (3) Erfolgsseite mit Live-Tracking-URL-Preview. Nach der Verifikation zieht der Hub automatisch Let's Encrypt SSL über Sliplane — Du musst nichts weiter tun. Die Domain ist Workspace-scoped, ein Hostname kann nicht doppelt angelegt werden (ein klarer Fehler), und der Zugriff prüft gegen die Workspace-Rolle — VIEWER und EXTERNAL dürfen keine Domains anlegen.
Der Hub erkennt beim Anlegen automatisch, ob Deine Domain eine Apex-Domain (Stamm-Domain ohne Präfix wie trackingmarke.de) oder eine Subdomain (klick.kundendomain.de) ist — inklusive Sonderfälle wie co.uk, com.au oder co.jp, die der Wizard automatisch erkennt. Abhängig davon zeigt Step 2 des Wizards genau die DNS-Records an, die Du brauchst: Record 1 ist immer ein TXT-Eintrag — Name _stryke-verify.<deinhostname>, Wert der vom Hub generierte Verifikations-Token (32 Base64-URL-Zeichen, kryptografisch zufällig). Record 2 hängt vom Hostname-Typ ab: bei einer Subdomain ein CNAME auf ; bei einer Apex-Domain ein ALIAS oder ANAME auf denselben Target. Weil nicht jeder Registrar ALIAS/ANAME unterstützt, zeigt der Wizard bei Apex-Hostnames zusätzlich eine Registrar-Warnung mit Ja/Nein-Liste (Cloudflare, DNSimple, Route 53 und DNS Made Easy: unterstützen ALIAS; IONOS, Strato, Namecheap, Google Domains: oft nur A-Records — dann lieber eine Tracking-Subdomain nutzen). Beim Klick auf „Jetzt prüfen" löst der Server einen echten eine echte DNS-Abfrage auf, vergleicht den gefundenen Token mit dem gespeicherten und setzt bei Match den Verifikations-Zeitpunkt; danach attacht ein Sliplane-API-Call die Domain an unseren Backend-Service, Let's Encrypt zieht innerhalb weniger Minuten das Zertifikat, und der SSL-Status wird im Dashboard laufend aktualisiert. DNS-Propagation kann 1–10 Minuten dauern — dafür zeigt der Wizard einen Retry-Hint statt einer harten Fehlermeldung.
Der STRYKE Key ist ein langlebiger API-Token im Format `stk_live_<32 base64url chars>`, mit dem externe Tools — n8n, GitHub Actions, Postman, eigene Skripte — den Hub wie ein eingeloggter User ansprechen. Scoped, widerrufbar, auditierbar, ohne JWT-Login-Flow. Status: aktuell als Konzept dokumentiert und in Vorbereitung, der Release folgt nach dem Hosting-Dashboard. In dieser Sektion erklären wir das Modell transparent, damit Du die Integration planen kannst.
Ein STRYKE Key ist ein langlebiger, persönlicher API-Token im Format stk_live_ gefolgt von 32 base64url-Zeichen (z.B. stk_live_a7f3k9m2x8b6v4n1q5r7t9w3y2u8p0s4). Er ersetzt den JWT-Login-Flow für externe Tools, damit Du STRYKE-Hub-Endpoints aus n8n-Workflows, GitHub-Actions, Postman oder Deinen eigenen Skripten ansprechen kannst, ohne jedes Mal Username/Passwort zu tippen. Status laut (Stand 2026-04): Konzept dokumentiert, Datenmodell designed, Implementierung geplant nach dem Hosting-Dashboard-Release. In der Zwischenzeit deckt einen Asset-Proxy-Key (Asset-scoped, siehe unten) bereits einen Großteil der Automations-Use-Cases ab. Sobald der STRYKE Key live geht, findest Du die Verwaltung unter /dashboard/profile/api-keys.
STRYKE Hub kennt drei Auth-Mechanismen für Menschen und Maschinen — jeder für einen eigenen Use Case. JWT: Der klassische Login-Token für Browser-User in der Hub-UI, kurzlebig, wird bei Inaktivität erneuert. STRYKE Key: user-scoped, langlebig, für externen Programmier-Zugang — die maschinelle Variante deines Logins. Asset-Proxy-Key: asset-scoped, schmal begrenzt — z.B. „mein n8n darf genau dieses eine Postfach lesen, aber sonst nichts". Wenn Du eine Automation baust, die nur eine einzelne Mailbox, DNS-Zone oder Sliplane-Service benötigt, nimm Asset-Proxy-Key. Wenn Du ein Skript baust, das Dir Hosting + Orders + Team kreuzt (z.B. nächtliche Kunden-Reports), nimm STRYKE Key. Beide sind serverseitig getrennt implementiert und tauschbar.
Ein STRYKE Key trägt explizite Scopes — kein Master-Key, kein „darf alles" by default. Die erste Tranche an Scopes: (GET auf /api/hosting/*), (POST/PATCH/DELETE auf /api/hosting/*), (GET auf /api/orders/*), (Bestellungen via POST /api/orders/hosting anlegen), (Proxy-Calls auf die eigenen Assets — niemals fremde), team:read (Workspace-Members lesen) und team:write (Einladungen aussprechen, Rollen ändern — nur wenn der Key-Besitzer OWNER im Workspace ist). Wichtig: Scopes authentifizieren den Key — autorisiert wird zusätzlich über die bestehende unsere Berechtigungs-Prüfung. Heißt: Ein Key mit darf trotzdem nur die Hosting-Accounts anfassen, auf die auch der Besitzer selbst Schreibrechte hat.
Nein. Der STRYKE Key ist kein Asset-Decryption-Key und wird es nie sein. Er authentifiziert den Aufrufer wie ein eingeloggter User — mehr nicht. Wenn Dein Key eine Operation anstößt, die einen Vault-Eintrag braucht (z.B. einen Proxy-Call zu Deiner ALL-INKL-Maske mit -Scope), läuft die Entschlüsselung weiter ausschließlich auf dem Server, mit der bestehenden AES-256-GCM-Architektur und dem Workspace-workspace-spezifischem Schlüssel, das nie das Backend verlässt. Selbst wenn ein STRYKE Key gestohlen wird, bekommt der Angreifer niemals die rohen KAS- oder Sliplane-Passwörter in die Hand — nur die Möglichkeit, Proxy-Operationen auszuführen, die der legitime User auch machen dürfte. Zusammen mit der sofortigen Widerrufbarkeit (siehe unten) ist das eine zusätzliche Sicherheits-Schicht gegenüber klassischen „Master-API-Keys".
Der Flow unter /dashboard/profile/api-keys: (1) Erzeugen — Du klickst „Neuer Key", gibst ein Label (z.B. „n8n Production") und die gewünschten Scopes an; das Backend erzeugt 32 zufällige Bytes, speichert nur den SHA-256-Hash in die gespeicherte Hash-Form und zeigt Dir den Raw-Key genau einmal in einem Copy-Dialog. Danach ist er bei uns unwiderruflich gelöscht — verlierst Du ihn, musst Du rotieren. (2) Nutzen — als Header Authorization: Bearer stk_live_…, parallel oder als Ersatz zum JWT. Die Middleware die Key-Middleware prüft Hash-Match, Scope-Coverage und optionale IP-Allowlist. (3) Rotieren — POST /api/api-keys/:id/rotate legt einen neuen Key mit identischen Scopes an und markiert den alten sofort als widerrufen. (4) Widerrufen — POST /api/api-keys/:id/revoke setzt Widerruf-Zeitpunkt mit Sofort-Effekt; der nächste Request mit diesem Key bekommt 401, ohne dass irgendein Cache erst ablaufen müsste.
Ja — beides ist im Datenmodell vorgesehen. Ablaufdatum: Ablaufdatum ist optional; default ist leer = unbegrenzt gültig. Für CI/CD-Pipelines, die Du nur für ein Projekt brauchst, empfehlen wir, ein Datum zu setzen — dann räumt der Hub den Key automatisch auf. IP-Allowlist: IP-Liste ist ein optionales Array von CIDR-Blöcken (z.B. ['203.0.113.0/24', '198.51.100.42/32']). Requests, die nicht aus einem dieser Blöcke kommen, landen mit 403 und hinterlassen einen Eintrag im Aktivitäts-Log. Sinnvoll für n8n-Server mit fester Outbound-IP, GitHub-Actions mit IP-Set oder interne Admin-Skripte vom Büronetz. Wenn Du die Allowlist leer lässt, akzeptiert der Key Requests von überall — das ist für Browser-basierte Tools wie Postman praktisch, für Produktiv-Automationen eher unerwünscht.
Ja. Bei jedem erfolgreichen Request aktualisiert die Middleware letzte Nutzung und letzte IP am Key — so erkennst Du in der UI auf einen Blick, welche Keys aktiv sind und welche seit Wochen kein Tool mehr benutzt hat (gute Kandidaten fürs Aufräumen). Jeder fehlgeschlagene Auth-Versuch (falscher Hash, abgelaufener Key, IP nicht in Allowlist, Scope fehlt) landet zusätzlich im dem Aktivitäts-Log mit IP, User-Agent und Grund — damit Du Brute-Force-Versuche frühzeitig siehst. Wenn ein Key team:write- oder -Operationen ausführt, gelten dieselben-Permission-History-Pflichten wie für UI-Aktionen: jeder Grant, Revoke, Rollen-Update wird mit Quelle „API" geloggt, damit im Nachhinein klar ist, ob eine Änderung vom Browser oder von einer Automation kam.
In allen Fällen wandert der Key als Authorization: Bearer stk_live_…-Header in den HTTP-Request — der Hub behandelt ihn parallel zu JWT. Beispiele: curl — curl -H "Authorization: Bearer $STRYKE_KEY" https://hub.strykemarketing.de/api/hosting/accounts. n8n — in der HTTP-Request-Node als „Header Auth"-Credential mit Name Authorization und Value Bearer {{ $env.STRYKE_KEY }}; den Token selbst legst Du als n8n-Secret ab, damit er nicht im Workflow-JSON landet. GitHub Actions — Token als Repository-Secret (secrets.STRYKE_KEY) und im Step via curl -H "Authorization: Bearer ${{ secrets.STRYKE_KEY }}" …. Wichtig in allen Fällen: niemals den Raw-Key in ein Git-Repo committen, nicht in Log-Output schreiben und bei Verdacht auf Leak sofort widerrufen — ein rotierter Key ist binnen Sekunden erzeugt, ein geleakter Key kostet im Zweifel viel mehr.
Ja. das Workspace-Feld deines Keys ist optional: Setzt Du den Key bei der Erzeugung auf eine konkrete Workspace, gilt er ausschließlich für Endpoints in diesem Kontext — Requests auf andere Workspaces liefern 403, selbst wenn der Besitzer dort ebenfalls Rechte hätte. Das ist besonders nützlich für Agenturen, die pro Kunden-Workspace einen eigenen Key an eine Automation hängen wollen: Kündigt ein Kunde, revokst Du genau den einen Key, alle anderen laufen unverändert weiter. Ohne gesetzten eine Workspace-Zuordnung gilt der Key über alle Workspaces, in denen der User Mitglied ist — praktisch für Solo-Nutzer mit nur einer Workspace oder Admins, die Cross-Workspace-Reporting-Skripte bauen. Die Entscheidung triffst Du einmalig bei der Erzeugung; sie lässt sich nachträglich nicht verändern — im Zweifel rotierst Du und engst den Scope beim neuen Key ein.
Vier Tarife, klar abgegrenzt, quartalsweise abgerechnet: Free zum Kennenlernen, Basic für den Einstieg, Pro für wachsende Agenturen und Enterprise für Teams ohne Grenzen. Die tagesaktuellen Preise und die genaue Gegenüberstellung findest Du jederzeit auf strykehub.com/abo — wir ziehen sie dort live aus unserem Rechnungssystem.
Wir arbeiten mit vier Tarifen: Free zum Kennenlernen, Basic für den Einstieg mit echten Workspace-Rechten, Pro für aktive Agenturen mit mehreren Marken und Teams, Enterprise für Teams, die ohne Obergrenze arbeiten wollen. Jeder Tarif hat fest definierte Grenzen für Team-Mitglieder, Hosting-Accounts, Domains, Postfächer, Campaigns und Vault-Einträge — die genaue Gegenüberstellung findest Du auf strykehub.com/abo. Preise ziehen wir dort live aus unserem Rechnungssystem, sodass Du immer den aktuellen Stand siehst; abgerechnet wird quartalsweise.
Wenn Du Dich neu im Hub registrierst, läuft Dein Account automatisch 14 Tage auf dem Basic-Tarif — ohne Zahlungsdaten und ohne Aktivierungs-Klick. Du kannst in dieser Zeit Workspaces anlegen, Team-Mitglieder einladen, Hosting-Accounts verbinden und den Vault ausprobieren, genau wie ein bezahlender Basic-Kunde. Nach Ablauf der zwei Wochen wandert Dein Account automatisch auf Free, wenn Du bis dahin nicht upgradest — Deine Daten bleiben dabei vollständig erhalten.
Ja, in beide Richtungen. Ein Upgrade auf Basic, Pro oder Enterprise wird sofort wirksam — Du kannst direkt mit den neuen Grenzen arbeiten, sobald die Rechnung bezahlt ist. Ein Downgrade wird zum Ende des laufenden Quartals aktiv, damit keine anteiligen Rechnungen oder ungenutzte Restlaufzeiten übrig bleiben; bis dahin behältst Du den vollen Funktionsumfang Deines aktuellen Tarifs.
Alles bleibt da — kein Account wird gelöscht, keine Einstellungen gehen verloren. Der Zugang wird auf einen Lese-Modus umgeschaltet: Du siehst weiterhin Deine Hosting-Accounts, Domains, Vault-Einträge und Team-Mitglieder, kannst aber keine neuen Bestellungen auslösen oder bestehende Einstellungen ändern, solange Du auf Free stehst. Sobald Du wieder auf Basic, Pro oder Enterprise upgradest, schaltet sich alles sofort frei und Du arbeitest ohne Unterbrechung weiter.
Du bekommst pro Quartal eine ordentliche deutsche Rechnung per E-Mail — mit Rechnungsnummer, USt-Ausweis und SEPA-Zahlungsziel, genau wie bei jeder anderen Bestellung im Hub. Der Quartalsrhythmus hält Deine Buchhaltung ruhig: ein Beleg, ein Zahlungseingang, ein klarer Abrechnungszyklus. Kündigen kannst Du zum Quartalsende, jederzeit im Hub mit einem Klick.
Enterprise ist für Teams gebaut, die ohne Obergrenzen arbeiten wollen — unbegrenzte Team-Mitglieder, Hosting-Accounts, Domains, Postfächer, Campaigns und Vault-Einträge, dazu Live-Support und Permission-Export für strukturierte Audits. Typischer Einstiegspunkt: wenn Pro mit zehn Team-Mitgliedern und fünfzehn Hosting-Accounts eng wird oder eine Compliance-Abteilung ein exportierbares Berechtigungsprotokoll verlangt. Setup und Konditionen klären wir im Gespräch — die Anfrage läuft über das Kontaktformular, verlinkt direkt auf strykehub.com/abo.
Du bekommst eine ordentliche deutsche Rechnung: SEPA-Überweisung, klare Beträge, steuerberater-kompatibler Aufbau, GoBD-konform archiviert. Jeder Beleg wird automatisch im Hintergrund erzeugt — kein Checkout-Hakeln, kein Wochenend-Ausfall, kein Karten-Lock-in. Wer eine USt-ID hinterlegt, bekommt EU-Reverse-Charge automatisch korrekt ausgewiesen.
Per SEPA-Überweisung auf deutsche Rechnung. Sobald Du eine Bestellung abschickst, bekommst Du automatisch eine Rechnung mit fortlaufender Rechnungsnummer, allen Positionen, Deiner Adresse und dem Zahlungsziel — als PDF per E-Mail und parallel im Hub unter „Meine Rechnungen". Sobald Dein Zahlungseingang bei uns erkannt wird, schaltet sich Deine Bestellung automatisch auf „Bezahlt" und die Einrichtung beginnt — ohne einen manuellen Schritt auf Deiner oder unserer Seite.
Nein — Du zahlst per SEPA-Überweisung auf eine deutsche Rechnung. Eine saubere Rechnung mit steuerberater-freundlicher Nummerierung und korrektem USt-Ausweis passt zu Deiner Buchhaltung, statt zu US-Karten-Routing. Wer zwingend Karten-Charging braucht (z. B. monatliche Auto-Renewals ohne SEPA-Mandat), ist bei einem klassischen Cloud-Provider wie Hetzner oder DigitalOcean besser aufgehoben.
Genau einmal pro Bestellung, sobald Du im Wizard auf „Jetzt bestellen" geklickt hast und die Bestellung in den Zahlungs-Warte-Status wechselt. Dein Beleg enthält die Positionen aus dem Wizard, Deine hinterlegte Rechnungsadresse und die richtige Steuer-Logik (Inland 19 %, EU-Reverse-Charge 0 %, Drittland 0 %). Rechnungsnummer und Beleg-PDF werden dauerhaft an Deiner Bestellung gespeichert — auch Folge-Rechnungen für Renewals (z. B. Domain im 12-Monats-Zyklus) erzeugen einen eigenen Beleg, jeweils rund 30 Tage vor Ablauf.
Im Hub unter Meine Bestellungen hängt an jeder Bestellung die zugehörige Rechnungsnummer plus Status-Badge (Offen / Bezahlt / Storniert / Mahnung). Ein Klick öffnet die offizielle PDF-Rechnung — exakt das Dokument, das auch Dein Steuerberater bekommt, mit allen gesetzlichen Pflichtangaben. Eine Workspace-weite Übersicht aller Belege (mit Filter nach Jahr, Status, Provider) wird mit dem dedizierten Abrechnungs-Bereich ausgeliefert; bis dahin erreichst Du jede Rechnung über die zugehörige Bestellung.
STRYKE prüft alle 5 Minuten alle offenen Bestellungen auf Zahlungseingang. Sobald Deine Überweisung gutgeschrieben ist, wird Deine Bestellung automatisch auf „Bezahlt" gesetzt und wandert in die Einrichtungs-Queue. Praktisch heißt das: Überweisung am Vormittag → Hosting läuft am Nachmittag, ohne dass jemand von uns aktiv werden muss.
Solange Deine Bestellung auf Zahlung wartet, kannst Du sie mit einem Klick im Hub stornieren — wir erzeugen dann automatisch eine passende Gutschrift, damit Deine Buchhaltung sauber bleibt. Bezahlst Du erst nach Wochen, wird die Bestellung trotzdem provisioniert, sobald die Zahlung eingeht. Bei dauerhafter Nicht-Zahlung lösen wir manuell Mahnungen aus; nach drei Mahnstufen wird die Bestellung als „fehlgeschlagen" markiert und die Rechnung storniert. Bereits eingerichtetes Hosting bleibt davon zunächst unberührt, kann aber bei länger offenen Beträgen pausiert werden — wir kommunizieren das jeweils per E-Mail vorab.
Beim ersten Kauf legen wir einen Abrechnungs-Kontakt für Deinen Workspace an. Dafür brauchen wir: Rechnungsadresse (Pflicht — Land, PLZ, Ort, Straße), E-Mail für den Beleg-Versand, optional Firma, USt-ID und eine abweichende Lieferadresse. Privatpersonen lassen Firma und USt-ID leer, alle anderen Felder bleiben gleich. Einzelunternehmer geben ihre Steuernummer als USt-ID ein, wenn sie eine haben — Kleinunternehmer nach § 19 UStG markieren das im Profil, dann weisen wir die Mehrwertsteuer auf der Rechnung explizit als nicht berechnet aus.
Hinterlegst Du eine gültige USt-ID aus einem anderen EU-Land (z. B. ATU…, FR…, IT…), markieren wir Deinen Kontakt als „EU mit USt-ID" und alle folgenden Rechnungen werden automatisch mit 0 % Mehrwertsteuer und dem Hinweis „Steuerschuldnerschaft des Leistungsempfängers / Reverse Charge" erstellt — Du verbuchst die USt selbst in Deinem Heimatland. Deutsche Kunden bekommen 19 % MwSt. wie üblich. Drittland (Schweiz, UK, USA, …) läuft als steuerbefreite Auslandsleistung ohne MwSt., aber mit dem entsprechenden Hinweis. Die USt-ID prüfen wir nicht aktiv per VIES-Lookup — die Verantwortung für die Korrektheit liegt bei Dir.
STRYKE Hub trennt zwei Audit-Schichten sauber: ein generisches Aktivitäts-Log für jede sicherheitsrelevante Aktion und eine spezialisierte, append-only Permission-History für jeden Rollen-Wechsel. Beide sind unveränderlich, beide enthalten niemals Geheimnisse — und beide erlauben Dir, einem Auditor binnen Minuten zu beweisen, wer wann welchen Zugang hatte.
Zwei aufeinander abgestimmte Audit-Schichten: (1) Das generische dem Aktivitäts-Log-Modell speichert jede sicherheitsrelevante Aktion (z. B.,) zusammen mit Actor, Workspace, Entity, IP-Adresse, User-Agent und einer Kaskaden-ID. (2) Die spezialisierte dem Permission-History-Log protokolliert jede Rollen-Änderung an Workspace, Asset, Hosting-Account, Campaign oder Vault-Eintrag — mit Aktion (Vergabe / Änderung / Entzug / Abgelaufen), alter und neuer Rolle, Subject, Performer und Quelle (UI / API / Einladung / Kaskade / Ablauf). Du findest diese Einträge im Verlauf-Tab unter /dashboard/access, im Freigabe-Dialog jedes Hosting-Accounts und in der Detail-Seite jedes Team-Mitglieds — jeweils read-only.
Das dem Aktivitäts-Log trackt eine breite Palette: Asset-CRUD (Create, Update, Delete, Version-Restore), Login-/Logout-Events, fehlgeschlagene Auth-Versuche, Vault-Decrypt-Calls, KAS-Reseller-Operationen, Order-Statuswechsel und jede Permission-Änderung. Die dem Permission-History-Log ist die typisierte, strukturierte Teilmenge davon — sie greift exakt dann, wenn eine Rolle entsteht (Vergabe), sich ändert (Änderung), entzogen wird (Entzug) oder durch Ablaufdatum erlischt (Abgelaufen). Bei Rollen mit Berechtigungs-Stufen (Asset/Workspace/Brand/Project) speichern wir die Level-Zahl (Stufen-Werte); bei String-Rollen (Hosting-Share, Campaign-Member, Vault-Share) die Rolle als String (Alt-/Neu-Rolle). So passt eine einzige Tabelle für beide Berechtigungs-Welten im Hub.
Nein. Die dem Permission-History-Log ist im Service-Layer hart als append-only und immutable implementiert — es gibt keine Update-, Delete- oder Soft-Delete-Methode, weder über die UI noch über die API. Selbst selbst Administratoren haben keinen Endpoint, um historische Einträge zu manipulieren. Die einzige Schreib-Operation ist create, validiert über strikte Action-Regeln: ein Vergabe darf keinen Alt-Rolle tragen, ein Entzug keinen Neu-Rolle, ein Änderung braucht beide Felder. Verstößt ein interner Service-Call dagegen, wirft der Service einen Validierungs-Fehler — die Geschichte deines Workspaces lässt sich also nicht „glätten", weder durch uns noch durch Dich.
Eine UUID, die wir generieren, wenn eine Aktion eine Kaskade auslöst: Beispiel — Du entfernst einen Mitarbeiter aus dem Workspace, und in Folge werden 12 seiner Hosting-Account-Shares automatisch revoked. Statt 13 zusammenhanglose Einträge in der History zu produzieren, erzeugt das System einmalig eine gemeinsame Kaskaden-ID und schreibt sie auf jeden einzelnen der 13 Einträge. Im Verlauf-Tab kannst Du dann nach genau dieser Kaskaden-ID filtern (/api/permission-history/correlation/:id) und siehst die komplette Kaskade als Gruppe — „Max hat um 14:32 Uhr Anna entfernt → 12 Shares automatisch revoked". Das ist die Grundlage, um Mitarbeiter-Austritte sauber gegenüber Auftraggebern zu dokumentieren.
Niemals. Die dem Permission-History-Log kennt nur Rollen-Strings und Level-Zahlen — kein Klartext-Passwort, kein verschlüsselter Payload, kein API-Key wandert je in die Tabelle. Auch im generischen dem Aktivitäts-Log liegt im das Metadaten-Feld-Feld nur, was sich geändert hat (z. B. {"oldName": "X", "newName": "Y"}) — Vault-Entry-Decrypts speichern „User X hat Vault-Eintrag Y entschlüsselt", aber nicht das Geheimnis selbst. Damit bleibt die Audit-Historie auch bei einem hypothetischen Datenleck wertlos für Angreifer: sie verrät, dass etwas passiert ist, aber nie was geheim war.
Sobald ein Workspace-Owner einen Mitarbeiter entfernt, läuft folgender Cascade automatisch durch: (1) das System erzeugt eine gemeinsame Kaskaden-ID, (2) der Workspace-Membership-Eintrag wird revoked und in Permission-History-Log mit source: 'UI' + dieser Kaskaden-ID protokolliert, (3) der Service iteriert über alle Ressourcen-Berechtigungen, Hosting-Account-Freigaben, Kampagnen-Mitgliedschaften und Vault-Freigaben dieses Users im Workspace und revoked sie mit source: 'CASCADE' plus derselben Kaskaden-ID, (4) parallel werden alle aktiven STRYKE-API-Keys (STRYKE-Keys) des Users in diesem Workspace-Scope auf widerrufen gesetzt. Nach einem einzigen Klick existiert für diesen User kein lebender Zugang mehr — kein Passwort wurde geändert, kein Credential rotiert, weil sein Zugriff nie auf Passwörtern beruhte, sondern auf widerruflichen Rollen.
Aktuell unbefristet in der Postgres-Datenbank — Audit-Daten zu löschen würde dem Sinn der Tabelle widersprechen (sie sollen ja gerade die Vergangenheit konservieren). Sollte ein Workspace-Owner einen User vollständig nach DSGVO-Art. 17 löschen lassen, anonymisieren wir den Eintrag: das Subject-Feld wird auf leer gesetzt, der Foreign Key löst auf automatisch leer gesetzt (so im Schema definiert), aber die Aktion bleibt mit Zeitstempel und Performer in der Historie — sonst würde der Cascade-Beweis „Anna hat am Tag X 12 Shares verloren" verschwinden. Workspace-Owner können auf Anfrage einen vollständigen DSGVO-Auskunfts-Export ihres Audit-Trails als JSON oder CSV bekommen.
Für die eigene Person ja: /api/permission-history/subject/:userId liefert Dir alle Einträge, in denen Du Subject warst — also jede Rolle, die Dir je gewährt, geändert oder entzogen wurde, über alle Workspaces hinweg. Für Deinen kompletten Account-Export (Profil, Memberships, vergebene Shares, Audit-Trail, Vault-Metadaten ohne Klartext-Geheimnisse) gibt es aktuell den manuellen Weg über das Support-Formular — der Self-Service-Export ist Teil der DSGVO-Compliance-Phase und steht auf der Roadmap. Workspace-Owner bekommen denselben Export für ihre eigenen Workspaces, inklusive aller Member und der zugeordneten Hosting-Accounts.
STRYKE Hub ist gebaut für alle, die Hosting-Zugänge nicht selbst bedienen, aber kontrollieren müssen — Entscheider mit mehreren Projekten, Agenturen mit Teams und Kunden, Inhouse-Marketing-Abteilungen mit wechselnden Mitarbeitern, Multi-Brand-Unternehmer mit getrennten Firmen, Dev-Teams mit CI/CD-Automationen. Überall wo Logins nicht mehr per E-Mail weitergereicht werden sollen, sondern als widerrufbare Rollen vergeben werden müssen, sitzt der Use-Case.
Ja — und zwar ab dem ersten Kundenprojekt. Du legst pro Kunde einen eigenen Workspace an (Daten und Permissions sauber getrennt), packst die KAS-Reseller-Sub-Account-Credentials oder Sliplane-Bearer-Token in den AES-256-GCM Vault und arbeitest fortan über die Hosting-Masken: Domains, DNS, Postfächer, Cronjobs, Datenbanken, FTP, WordPress-Install — ohne Dich je wieder im KAS-Backend einzuloggen. Der USP für Solo-Freelancer ist nicht das Team-Sharing (das brauchst Du erst bei Mitarbeit), sondern die zentrale Konsole: ein Login statt zehn Provider-Backends, der integrierte Webmailer für KAS-Mailboxen, der Permission-History-Trail als Beweismittel-Sammlung gegenüber Kunden („wer hat wann was geändert"), und das Rechnungs-System, das Deine STRYKE-Rechnungen automatisch erzeugt. Kommt später ein Sub-Kontraktor oder eine Werkstudent:in dazu, lädst Du sie als External ein und gibst genau die Ressourcen frei, an denen sie arbeiten — kein Account-Sharing nötig.
Agenturen sind der Kern-Use-Case. Konkret: Du legst je Kunde einen Workspace an oder bündelst alle Kunden in Workspace → Brand → Project-Hierarchie — beides funktioniert. Mitarbeiter ziehst Du als Member rein, externe Freelancer als External mit nur den explizit freigegebenen Ressourcen, Junior-Devs bekommen Editor-Rechte auf einzelne Hosting-Accounts, ohne ins Vault-Geheimnis zu sehen. Die Vault-Architektur macht den Unterschied: Ein Mitarbeiter bedient die KAS-Maske eines Kunden, ohne jemals die KAS-Reseller-Credentials selbst zu sehen — der Backend-Proxy entschlüsselt sie zur Laufzeit, der Browser bekommt nur die Operation. Verlässt der Mitarbeiter die Agentur, revokst Du seine Workspace-Membership: Cascade-Logik entzieht binnen Sekunden alle Hosting-Account-Shares, Vault-Shares, Campaign-Memberships und STRYKE-API-Keys — kein Passwort wechseln, keine Briefings an alle Kunden, kein Restrisiko.
Multi-Workspace ist Tag-1-Architektur. Ein Login, beliebig viele Workspaces, jeder vollständig isoliert: eigene Mitglieder, eigene Hosting-Accounts, eigene Vault-Einträge, eigene Rechnungsadresse, eigene Kampagnen. Jedes Datenmodell, das Kunden-Inhalte trägt (Hosting-Account, Asset, Vault-Eintrag, Kampagne, Ressourcen-Berechtigung), ist fest an eine Workspace-Zuordnung gekoppelt — Querzugriffe zwischen Workspaces sind auf Datenbank-Ebene unmöglich. In der UI wechselst Du oben links zwischen Workspaces wie zwischen Browser-Tabs; jede Permission-History-Abfrage, jede Rechnung, jeder Vault-Filter ist automatisch Workspace-scoped. Für Holdings mit mehreren Marken oder Beraterinnen mit Co-Founder-Rollen in mehreren Firmen ist das die saubere Trennung — ohne dass Du Dich pro Firma neu einloggen musst.
Inhouse-Marketing leidet typisch unter Passwort-Chaos: Der Online-Marketing-Manager hat das KAS-Login, der Praktikant kennt das WordPress-Admin-Passwort, die Freelance-SEA-Beraterin hat ihr eigenes Google-Ads-Login (das ist Feature-Branch und nicht Hub-Scope, aber das DNS für die Landing-Page betreut der Hub), der Dev-Lead loggt sich gelegentlich in Sliplane ein. Wenn jemand geht, weiß keiner mehr genau, was rotiert werden muss. STRYKE Hub setzt dem ein Ende: Alle Hosting-Zugänge wandern in den Vault, jedes Team-Mitglied bekommt seine eigene Hub-Identität und nur die Rollen, die es operativ braucht (Member fürs Team, Editor auf bestimmten Hosting-Accounts, Viewer auf den Rest). Wechsel von Mitarbeitern werden zur Verwaltungs-Routine: Workspace-Membership entziehen → Cascade-Revoke → fertig. Der CMO sieht im Permission-History-Tab die letzten 30 Tage Rollen-Bewegungen ohne IT-Anfrage; Audit-Reports für Compliance-Audits oder ISO-Vorbereitung sind ein DB-Export entfernt.
Dev-Teams kombinieren STRYKE Hub mit dem STRYKE Key API : Die Pipeline in n8n, GitHub Actions, GitLab CI oder einem eigenen Skript bekommt einen stk_live_-Token mit eng gefassten Scopes (z.B. nur auf einen bestimmten Workspace, optional mit IP-Allowlist). Der Token wird im Secret-Store des CI hinterlegt, die Pipeline ruft Hub-Endpoints für DNS-Updates nach Deploys, Container-Restarts auf Sliplane, WordPress-Plugin-Installs nach Release oder Postfach-Provisioning für neue Mitarbeiter — alles ohne, dass im CI-Runner jemals die KAS- oder Sliplane-Master-Credentials liegen. Verliert ein Token Vertrauen (Repo-Leak, Mitarbeiter weg), wird er per One-Click revoked — Sofort-Effekt, kein Cache-Wartezeit. Wer die Pipeline besser auditieren will, nimmt zusätzlich Permission-History-Log mit source: 'API' als nachvollziehbares Logbuch automatisierter Schreib-Operationen.
Ja, weil die Workspace-Trennung sauber DSGVO- und steuer-relevant ist. Jedes Workspace bekommt seine eigene Rechnungsadresse und USt-ID — pro Workspace werden Rechnungen mit dem Reverse-Charge-Mechanismus oder Inland-19%-Steuersatz automatisch korrekt ausgestellt. Ein Holding-Unternehmer mit DE-GmbH und AT-GmbH hat zwei Workspaces, kann aber zwischen beiden mit einem Login wechseln, dieselben Mitarbeiter beiden Workspaces als External hinzufügen (oder eben nicht), und sieht in jedem Workspace nur die jeweilige Hosting-Landschaft. Die Brand-Hierarchie (Workspace → Brand → Project) ist die zweite Stufe: Ein Werbe-Unternehmer mit zehn Marken kann sie alle in einem Workspace führen und je Brand getrennte Hosting-Accounts, Domains, Postfächer halten — operatives Tagesgeschäft, ohne ein neues Hub-Konto pro Marke aufzuziehen.
Technisch funktioniert STRYKE Hub ab 1 Person — die zentrale Konsole für Domains, Postfächer, DNS, FTP, Datenbanken, Cronjobs, WordPress-Installs und Sliplane-Container ist auch für Solo-Hoster ein Zeitsparer (kein Tab-Wechsel zwischen KAS-Backend, Sliplane Dashboard, drei WordPress-Admins, FileZilla und Webmail-Login). Der echte USP — Sharing ohne Credential-Weitergabe + Audit-Trail + Cascade-Revoke — entfaltet sich aber ab dem Moment, wo eine zweite Person mitarbeitet: Werkstudent, Freelancer, Co-Founder, Buchhaltungs-Outsourcing, Praktikant. Faustregel aus der Praxis: Sobald Du einmal pro Quartal jemand Neues onboarden oder offboarden musst, hat sich der Hub schon nach zwei Wechseln finanziell und nervlich amortisiert — gegenüber dem Aufwand, KAS-Passwörter zu rotieren, Sliplane-Bearer-Tokens neu zu erzeugen und allen Beteiligten neue Logins zu mailen.
Ehrlich abgegrenzt: (1) Wer kein eigenes Hosting verwaltet, sondern alles auf Wix, Squarespace, Shopify oder einem reinen Builder-Tool laufen lässt — hier gibt es nichts zu broker-ten. (2) Wer ein generisches SaaS-Multi-Provider-Dashboard sucht für Slack + HubSpot + Klaviyo + Salesforce + Notion — STRYKE Hub ist Hosting-fokussiert, Social-Media- und CRM-Integrationen sind kein Teil der aktuellen Hauptversion. (3) Wer zwingend Kreditkarten-Abo-Abrechnung braucht — STRYKE Hub läuft über ordentliche deutsche Rechnungen per SEPA-Überweisung. (4) Wer einen vollwertigen 1Password-Ersatz für 200 verschiedene Logins quer durch alle Lebensbereiche sucht — der Vault ist auf Hosting-Credentials und Hub-relevante Geheimnisse fokussiert, nicht auf Familien-Streaming-Konten. (5) Wer einen reinen IaaS-Anbieter wie Hetzner Cloud direkt bevorzugt und keinen Wert auf Provider-Abstraktion legt — dann reicht die Hetzner-Console allein.
In der Beta gibt es keinen Helpdesk, keine Service-Desk-Nummer und kein Ticket-System mit Wartemusik — Du erreichst direkt die Menschen, die den Hub bauen. Antwort innerhalb weniger Stunden ist die Regel, oft schneller. Nach dem Launch läuft der reguläre Support werktags Mo–Fr 10–18 Uhr (CET) über das Support-Formular, E-Mail und den In-Product „Fehler melden"-Button mit automatischem Browser-Kontext.
Drei Kanäle, die Du frei wählen kannst, je nach Anliegen: Support-Formular auf support.strykehub.de für strukturierte Bug-Reports mit Screenshot-Upload, Kategorie-Auswahl und automatischem Routing direkt in unser Dev-Board — geeignet für reproduzierbare Fehler oder Feature-Wünsche, die jemand anders im Team mitlesen soll. E-Mail an mail@stryke-marketing.de für offene Fragen, Pricing-Themen, Vertragliches oder alles, was länger ist als ein Tweet. In-Product „Fehler melden"-Button auf jeder Hub-Fehler-Seite, der Browser-Version, aktuelle Route, eingeloggter User und letzte Aktion automatisch anhängt — perfekt für „das hat gerade nicht funktioniert"-Momente, ohne dass Du Screenshots organisieren musst. Für sicherheitsrelevante Meldungen (vermutete Schwachstelle, Vault-Anomalie, verdächtige Audit-Einträge) gilt der Hinweis: nicht ins öffentliche Formular — sondern direkt per Mail an die genannte Adresse mit dem Betreff SECURITY.
In der Beta-Phase: werktags innerhalb weniger Stunden, häufig binnen 30–60 Minuten — weil Deine Nachricht direkt bei einem Entwickler landet, nicht bei einem Tier-1-Callcenter, das Dich später eskaliert. Am Wochenende und an Feiertagen antworten wir bei Bedarf, aber nicht garantiert. Nach dem offiziellen Launch wechseln wir auf reguläre Support-Zeiten Mo–Fr 10–18 Uhr (CET): First-Response in der Regel innerhalb desselben Werktages, längere Themen (Bug-Analyse, Migration, Datenexport) bekommen ein Erstfeedback mit Aufwandsabschätzung. Wenn Du auf eine Nachricht binnen 48 h werktags keine Antwort hast, ist sie verloren gegangen — schick sie nochmal über einen anderen Kanal, das ist nie ein Problem.
Nein — aktuell nicht. STRYKE Hub ist in der Beta, eine vertraglich zugesicherte Service-Level-Agreement (z.B. „99,9 % Verfügbarkeit, 4 h Reaktionszeit") wäre unseriös, solange wir noch in den letzten Phasen des Refactor-Plans sind. Was Du heute hast, ist Best-Effort-Support auf hohem Antwort-Niveau, eine transparente Roadmap, und einen schnellen Draht für Eskalationen. Mit dem Launch wird ein einheitliches SLA-Modell für alle Tarife veröffentlicht; Beta-Teilnehmer bekommen die Konditionen mindestens vier Wochen vor Inkrafttreten zur Vorab-Sicht. Für reine Hosting-Provider-Verfügbarkeit (KAS-Server, Sliplane-Container) gelten weiterhin die SLAs der jeweiligen Anbieter — der Hub ist die Steuerebene, nicht das Hosting.
Eine öffentliche Status-Seite (status.strykehub.de mit Komponenten-Übersicht, Incident-Historie und RSS-Feed) ist Teil der Phase-4-Polish-Roadmap und kommt mit dem offiziellen Launch. Bis dahin gilt: aktive Incidents kommunizieren wir via Hub-internem Banner über alle Workspaces („Wartung läuft", „Postfach-Sync verzögert") plus per E-Mail an die Workspace-Owner, wenn das Problem länger als 30 Minuten dauert. Bei Provider-Problemen (KAS hat einen Ausfall, Sliplane macht Wartung) merkst Du das im jeweiligen Hosting-Tab über rote Status-Badges und konkrete Fehlermeldungen — wir verschleiern nichts hinter generischen „Etwas ist schiefgegangen"-Texten. Wer regelmäßig automatisierte Status-Checks aus n8n oder einem Monitoring-Tool fahren will, hat über den STRYKE Key API ohnehin den nötigen Read-Access auf /api/health-ähnliche Endpoints.
Schneller hilft uns, was wir reproduzieren können. Bewährt: (1) was hast Du gemacht — der konkrete Klick-Pfad oder API-Aufruf, idealerweise mit Workspace-Name und Ressourcen-ID (Hosting-Account-Slug, Asset-ID), damit wir denselben Datenstand sehen. (2) was hast Du erwartet, (3) was ist passiert — Screenshot oder kurzer Bildschirm-Mitschnitt schlägt jede Beschreibung. (4) Browser + OS (steht im Bug-Footer), (5) Zeitpunkt ungefähr, weil unsere Logs Zeitstempel-indiziert sind. Der In-Product „Fehler melden"-Button packt 1, 4 und 5 automatisch ein — den ergänzt Du nur um „was wolltest Du tun". Sicherheits-relevante Bugs (Vault-Verhalten, Permission-Fehler, sichtbare Daten anderer Workspaces) bitte vertraulich behandeln — nicht im öffentlichen Formular, sondern per E-Mail mit Betreff SECURITY und ohne Screenshots in unverschlüsselten Cloud-Drives.
Genauso wie Bugs — über Support-Formular oder E-Mail, mit Tag „Feature-Wunsch". In der Beta wandert nahezu jede Idee zumindest in die Diskussion auf unserem Dev-Board, viele direkt in einen aktiven Sprint. Wir antworten transparent: „Geplant für Phase X", „Klingt gut, aber wir sehen es im Konflikt mit Y", oder „Nicht für diesen Use-Case, weil Z" — keine generischen „danke für Dein Feedback"-Schleifen. Wenn Du eine Feature-Idee mit anderen Beta-Teilnehmern teilst und Resonanz bekommst, sag uns das — Mehrfach-Wünsche steigern die Priorität sichtbar. Implementiert wird priorisiert nach Roadmap-Plan: Hosting-Dashboard, Vault, Order-Pipeline, Permission-System, Webmailer, STRYKE Key API. Themen außerhalb dieses Korridors (zum Beispiel Social-Media-Dashboards, Kreditkarten-Abo-Systeme, generische SaaS-Broker) sind nicht Teil der Hauptversion und werden auch durch Wünsche nicht reaktivierbar.
Datenschutzerklärung: privacy.strykemarketing.de — beschreibt was wir wo speichern (Workspace-Daten in der Postgres-DB, Vault-Inhalte AES-256-GCM-verschlüsselt, Audit-Trail unbefristet außer auf DSGVO-Antrag), Datenflüsse zu Sub-Auftragsverarbeitern (KAS All-Inkl als Hosting-Provider, Sliplane für Container, unser Rechnungssystem für die Belege), und die Verfahren für DSGVO-Auskunft (Art. 15) und Löschung (Art. 17). Impressum: auf strykehub.de und strykemarketing.de jeweils im Footer — STRYKE Marketing als Anbieter mit deutscher Postanschrift, Geschäftsführer, USt-ID, Kontakt. AGB: aktuell wird die finale Beta-Vereinbarung pro Workspace beim Onboarding angezeigt; mit dem Launch erscheint eine permanente AGB-Seite mit Versionshistorie. Wer Auftragsverarbeitungs-Vertrag (AVV) nach Art. 28 DSGVO benötigt, fordert ihn per Mail an — wir schicken ein vorausgefülltes Standard-AVV-PDF zu, das Du nur noch gegenzeichnen musst.
Eine vollständige öffentliche API-Doku im Stil von Stripe/GitHub („alle Endpoints, alle Parameter, alle Beispiel-Responses") ist mit dem offiziellen Launch des STRYKE Key API geplant — sie wird parallel zur Token-Verwaltung unter /dashboard/profile/api-keys verlinkt sein. Die API-Dokumentation befindet sich aktuell noch intern in unseren Backend-Quellen; Beta-Teilnehmer, die ihre Integration jetzt schon planen wollen, bekommen auf Anfrage einen Auszug der relevanten Endpoints (Hosting, Orders, Vault-Proxy, Team) per Mail. Die Auth-Mechanismen (JWT, STRYKE Key, Asset-Proxy-Key, Workspace-workspace-spezifischer Schlüssel) sind bereits in Kategorie 10 dieser FAQ beschrieben — wer nur den Auth-Aufbau verstehen will, hat das nötige Modell schon hier.
STRYKE Hub ist nicht „noch ein Hosting-Dashboard" — es kombiniert Hosting-Verwaltung, Credential-Vault und Team-Sharing in einer Konsole. Die folgenden Vergleiche helfen einzuordnen, wo der Hub die richtige Wahl ist und wo ein Spezial-Tool die bessere Antwort wäre. Vergleichsmaßstäbe stammen aus, Google Cloud Console, Hetzner Console — aber im STRYKE Style") und der Praxis von Agenturen, die parallel andere Tools im Einsatz hatten.
Vercel ist ein spezialisiertes Container-/Edge-Hosting-Tool für Next.js und Frontend-Frameworks — extrem stark in seinem Kernsegment, aber nicht für klassisches Managed-Hosting (E-Mail-Postfächer, FTP, MySQL, DNS-Records, WordPress per One-Click) gedacht. STRYKE Hub deckt beide Welten ab: Sliplane übernimmt die Container-Rolle (vergleichbar mit Vercels Build-und-Run-Pipeline, aber Anbieter-agnostisch), parallel bedient ALL-INKL klassische WP-Sites, Postfächer, Domains. Außerdem fehlen Vercel: Credential Vault mit Team-Sharing ohne Passwort-Weitergabe (Vercel teilt Projekt-Zugriffe, nicht Drittanbieter-Geheimnisse), Permission History als Audit-Trail über alle Ressourcen, deutsche Rechnung mit SEPA-Überweisung, und der integrierte Webmailer für die Postfächer, die Du im Hosting-Setup mit angelegt hast. Wer reines Vercel-style-Frontend-Deployment braucht und kein Mail/Domain/Vault-Anliegen hat, ist mit Vercel allein gut bedient — wer beides verwaltet, gewinnt mit STRYKE Hub die zentrale Konsole.
cPanel und Plesk sind klassische Single-Server-Admin-Oberflächen: Du loggst Dich in den Admin-Bereich eines konkreten Servers ein, verwaltest dort Mailboxen, FTP, Datenbanken und DNS dieses einen Servers. Der Hub setzt eine Stufe darüber an: (1) Multi-Account, Multi-Provider — ein Workspace bündelt beliebig viele KAS-Sub-Accounts plus Sliplane-Server, Du wechselst nicht zwischen Backends. (2) Reseller-Pattern für KAS — alle Sub-Account-Operationen laufen über die Reseller-Credentials, Kunden bekommen nie selbst KAS-Logins. (3) AES-256-GCM Vault für die zugrundeliegenden Credentials — cPanel speichert Server-Passwörter im Klartext-Browser-Profil oder im Mitarbeiter-Kopf; STRYKE verschlüsselt sie und entschlüsselt nur server-seitig zur Laufzeit. (4) Team-Sharing ohne Passwort-Weitergabe + (5) Permission History mit Cascade-Revoke beim Mitarbeiter-Austritt. cPanel ist gut für „ich habe einen Server und administriere ihn"; STRYKE Hub ist gebaut für „ich habe 30 Kunden auf 3 Hosting-Welten und ein Team von 5 Leuten".
Die Hetzner Cloud Console ist eine reine IaaS-Oberfläche: VMs starten, IPs vergeben, Volumes anlegen, Firewalls setzen — Infrastruktur, nicht Anwendungen. Wer auf Hetzner läuft, baut sich darüber selbst Anwendungs-Schichten (Coolify, Dokku, Plain Docker, Ansible-Skripte, …). STRYKE Hub abstrahiert eine andere Ebene: nicht „nackte Server", sondern fertige Hosting-Produkte (KAS-Webspace mit WP-One-Click, Sliplane-Container mit Auto-Deploy, Domains über einen deutschen Registrar-Dienst, ALL-INKL-Postfächer mit IMAP/SMTP). Der Hub konkurriert nicht mit Hetzner, sondern ergänzt es: Wer eine Mischlandschaft aus klassischem WP-Hosting + Container + paar Mailboxen + DNS verwaltet, nutzt STRYKE; wer 50 Kubernetes-Worker-Nodes für eine Custom-Anwendung baut, bleibt bei Hetzner direkt. Lehrreich ist die UX-Inspiration in beide Richtungen: Hetzner zeigt, wie schmal eine Provider-Console sein darf — STRYKE Hub übernimmt die Klarheit, ergänzt aber die Multi-Provider-Aggregation, die Hetzner per Definition nicht abdeckt.
Ploi, RunCloud und Laravel Forge sind Server-Setup- und Site-Management-Tools für VPS-Hoster (Hetzner, DigitalOcean, AWS): Du verbindest Deinen eigenen Server, das Tool installiert Nginx/PHP/MySQL und gibt Dir eine Web-UI für WordPress-Installs, Cronjobs, SSL, Deploys. Sehr stark in ihrem Kernsegment — aber: (1) kein Multi-Provider-Broker: KAS und ALL-INKL Managed-Hosting fallen außen vor, weil das keine SSH-VPS sind. (2) kein dedizierter Credential-Vault mit AES-256-GCM und Capability-basiertem Sharing — Server-SSH-Keys werden gespeichert, aber nicht für Team-Mitglieder mit feinkörnigen Rollen rotiert oder per Cascade revoked. (3) kein deutsches Rechnungssystem mit SEPA-Überweisung — Bezahlung läuft über Kreditkarte und US-Zahlungsdienstleister. (4) kein Permission-History-Audit-Trail nach-Vorbild — Aktionen werden geloggt, aber nicht in einer DSGVO-Auskunft-tauglichen Nachweis-Struktur (Subject, Ressource, Verkettung). STRYKE Hub ist die richtige Wahl, wenn Du KAS-Managed-Hosting mit Container-Hosting mischt; Ploi/RunCloud/Forge sind die richtige Wahl, wenn Du ausschließlich auf VPS bist und tiefere Server-Konfiguration brauchst, die wir nicht abbilden.
Kommt darauf an, was Du teilen willst. Für Hosting-Credentials (KAS-Reseller-Login, Sliplane-Bearer, FTP, DB, WordPress-App-Passwords, SMTP) ist der STRYKE Vault gebaut: AES-256-GCM, Workspace-spezifischer workspace-spezifischer Schlüssel, Capability-basiertes Sharing (User/Team/Workspace), Backend-Proxy entschlüsselt nur server-seitig — Client sieht nie Raw-Credentials. Hier ist der Hub die saubere und integrierte Lösung, weil er die Credentials unmittelbar in Hosting-Operationen umsetzt (1Password müsste Du copy-pasten). Für allgemeine Mitarbeiter-Logins jenseits Hosting (Notion, Slack, Adobe, Buchhaltungs-Tools, private Logins) bleibt 1Password / Bitwarden die richtige Wahl — STRYKE Hub ist kein generischer Passwort-Manager für beliebige Logins. Die Praxis: STRYKE Hub fürs Hosting-Geheimnis-Inventar, 1Password parallel für den Rest. Wer beide Tools richtig einsetzt, hat keinen Doppel-Aufwand — die Use-Cases überschneiden sich kaum.
Die Eigenbau-Variante funktioniert kurzfristig erstaunlich gut — und bricht zuverlässig auseinander, sobald Team-Wechsel oder Audit-Anfragen kommen. Konkrete Schwachstellen, die STRYKE Hub adressiert: (1) Geteilte Excel/Notion-Tabelle mit Credentials — keine Verschlüsselung at-rest, keine Capability-Stufen, kein Revoke ohne Rotation aller geteilten Logins. (2) n8n mit hartcodierten API-Tokens — ein einzelner Master-Token ohne Scopes oder IP-Allowlist, dessen Reichweite niemand mehr durchschaut. (3) Postman-Collections mit Environment-Variablen — verschwinden mit dem Mitarbeiter-Laptop, kein zentraler Auditierbarkeit. (4) manuelle Rechnung pro Bestellung — fehleranfällig, zeitaufwändig. STRYKE Hub liefert: AES-256-GCM-Vault statt Tabelle, scoped/revocable STRYKE Keys statt Master-Tokens, Permission History statt Mitarbeiter-Gedächtnis, automatische Rechnungs-Belege über den Bestell-Ablauf. Für ein Solo-Hobby-Setup mit drei Domains kann der Eigenbau weiterhin reichen — sobald ein Kunde, ein Mitarbeiter oder eine Compliance-Frage dazukommt, ist die Hub-Variante keine Komfort-Frage mehr, sondern eine Risiko-Frage.
Beide Provider-Konsolen sind solide für ihren jeweiligen Account — aber sie enden an der Grenze des einen Logins. STRYKE Hub ergänzt: (1) Eine Konsole für beide Welten — KAS-Operationen (Domains, DNS, Mail, FTP, DB, SSL, Cronjobs, WordPress-Install) und Sliplane-Operationen (Server, Services, Deploys, Volumes, Env-Vars, Custom-Domains) ohne Tab-Wechsel. (2) Multi-Account auf einer Ebene — KAS-Sub-Accounts werden über das Reseller-Pattern aggregiert, Sliplane-Bearer-Tokens mehrerer Konten parallel. (3) Team-Sharing ohne Credential-Weitergabe — KAS-Konsole verlangt das Reseller-Login, Sliplane den Bearer-Token; STRYKE proxiert beide, der Mitarbeiter sieht den Inhalt nie. (4) Permission History + Cascade-Revoke — Mitarbeiter raus = ein Klick, alle Hosting-Account-Shares + Vault-Shares + Campaign-Memberships + STRYKE-API-Keys auf einmal entzogen. (5) Integrierter Webmailer für KAS-Mailboxen über IMAP/SMTP — kein Sprung in die ALL-INKL Webmail-Oberfläche. (6) Durchgängiger Bestell-Ablauf mit Rechnungs-Anbindung — Hosting-, Domain- und Mail-Bestellungen lösen automatisch eine deutsche Rechnung per E-Mail aus, statt dass Du in der Provider-Konsole bestellst und parallel die Buchhaltung füttern musst.
Vier ehrliche Konstellationen: (1) Single-Server-Setup ohne Team und ohne Multi-Provider-Bedarf — wenn Du genau einen Hetzner-Root-Server allein administrierst und nie mit jemand teilst, bringt der Hub keine Vorteile, die ein gutes 1Password + ein Coolify nicht auch hätten. (2) Multi-Cloud-IaaS-Provisioning auf AWS/Azure/GCP-Niveau — Terraform/OpenTofu sind dafür gebaut, STRYKE Hub dagegen nicht. (3) Web-3 / On-Chain / Krypto-Wallet-Verwaltung — komplett anderer Tech-Stack und Sicherheits-Modell, hier hilft STRYKE nichts. (4) Use-Cases, die zwingend Kreditkarten-Abrechnung brauchen — bei STRYKE Hub läuft die Bezahlung über die ordentliche deutsche Rechnung per SEPA-Überweisung, das ist eine klare Produktentscheidung. Wer ehrlich in eine dieser Schubladen fällt, sollte einen anderen Weg gehen — der Hub gibt vor, Hosting-Verwaltung für Agenturen und Multi-Brand-Unternehmer zu machen, alles andere wäre unehrlich.