STRYKE HubDokumentation

Cloud-Server

Cloud-Server

Wann ein Cloud-Server passt und wann Managed Webhosting — mit Vor- und Nachteilen beider Seiten.

Manche Projekte passen nicht in ein Webhosting-Paket: eigene Anwendungen, Dienste mit besonderen Anforderungen, alles, was mehr Kontrolle braucht. Dafür gibt es Cloud-Server.

Warum es beides gibt

Managed Webhosting und Cloud-Server sind zwei Arten von Hosting, keine zwei Qualitätsstufen. Cloud ist nicht „das bessere" Hosting und Managed nicht „das kleine" — sie lösen verschiedene Aufgaben, und die meisten Kunden brauchen genau eine davon.

Wir bieten beide an, weil wir sonst einen Teil unserer Kunden zu einer Lösung überreden müssten, die nicht passt: eine Handwerker-Website auf einem leeren Container ist genauso falsch wie eine selbst geschriebene Anwendung, die in ein Webhosting-Paket gezwängt wird. Für Dein Abo macht es keinen Unterschied — beide füllen denselben Platz, siehe Tarife & Slots. Du kannst also frei entscheiden, womit Du einen Platz füllst, und beides nebeneinander führen.

Was beide Arten verbindet, ist der Hub. Er ist die Ebene darüber und macht beide auf dieselbe Weise zugänglich: bestellen, Domain und DNS setzen, Zertifikat einrichten, Postfächer anlegen, dem Team Zugriff geben, Rechnungen nachlesen — für Managed Hosting und Cloud-Server in derselben Oberfläche, mit einem Login. Beim Cloud-Server heißt „leer und frei" deshalb nicht „Du bist allein": Du bringst das Projekt mit, alles darum herum nimmt Dir der Hub ab, ohne dass Du eine Konsole öffnest.

Managed Webhosting

Eine fertig eingerichtete Umgebung: Webspace, Datenbanken, PHP, E-Mail, FTP und Zertifikate sind vorhanden, bevor Du etwas tust.

Dafür spricht:

  • Es ist nichts einzurichten — WordPress und andere Anwendungen installierst Du mit einem Klick.
  • Postfächer sind Bestandteil des Pakets, in großer Zahl.
  • Domains, DNS, Zertifikate und E-Mail liegen im selben Konto.
  • Um Betriebssystem, Plattform-Updates und Wartung kümmern wir uns.

Dagegen spricht:

  • Es läuft, was die Plattform anbietet: Websites und PHP-Anwendungen. Eine eigene Anwendung in einer anderen Sprache oder ein Dienst, der dauerhaft im Hintergrund läuft, gehört nicht hierher.
  • Du teilst die Maschine mit anderen Kunden und arbeitest nicht auf der Systemebene.

Cloud-Server

Das Gegenteil davon: leer, dafür frei. Du bringst Dein Projekt als GitHub-Repository oder als Docker-Image mit, wir hängen Domain, DNS und Zertifikat daran.

Dafür spricht:

  • Es läuft, was Du hineinbringst — jede Sprache, jedes Framework, jeder Dienst, der sich in einen Container packen lässt.
  • Auf Wunsch wird bei jedem Push neu ausgerollt.
  • Die Größe änderst Du später, von der geteilten Maschine bis zu einer für Dich allein.
  • Protokolle, Zustand und Umgebungs-Variablen siehst Du im Hub, ohne Konsole.

Dagegen spricht:

  • Es ist nichts vorinstalliert: kein Klick-Installer, kein FTP-Zugang, kein fertiges WordPress.
  • E-Mail bringt ein Cloud-Server nicht mit. Postfächer laufen dann über ein kleines ALL-INKL-Paket, das nur für E-Mail da ist.
  • Für das, was in Deinem Container läuft — Abhängigkeiten, Updates, Konfiguration — bist Du verantwortlich, nicht wir.

Die kurze Antwort

Eine Website: Managed Webhosting. Eine eigene Anwendung: Cloud-Server. Beides zusammen: beides, nebeneinander — bedient wird es ohnehin an derselben Stelle.

Was Du im Hub tun kannst

Der Cloud-Bereich mit den verbundenen Accounts
Jeder Cloud-Account mit seinem Zustand — und den Sprungzielen zu Servern, Services und Protokollen.
  • Dienste sehen — was läuft, mit Zustand auf einen Blick
  • Starten, stoppen, neu ausrollen
  • Protokolle lesen — live, ohne Umweg über eine Konsole
  • Domains zuordnen — eine Adresse auf einen Dienst legen, samt Verschlüsselung
  • Zustand überwachen — der Hub zeigt an, wenn ein Dienst nicht mehr antwortet

Dein Code kommt über GitHub

Einen API-Schlüssel hinterlegst Du nirgends. Du gibst dem Hub einmal die Erlaubnis für Dein GitHub-Konto — ein Klick, kein Kopieren von Zugangsdaten. Danach holt der Hub Deinen Code selbst und rollt ihn auf Deinen Cloud-Server aus, auf Wunsch bei jedem Push automatisch.

Den Cloud-Server selbst bestellst Du im Hub. Er läuft über Deinen Vertrag bei uns — ein eigenes Konto beim Anbieter brauchst Du nicht.

Protokolle richtig lesen

Wenn ein Dienst nicht startet, steht der Grund fast immer in den letzten Zeilen des Protokolls. Lies von unten nach oben und such nach der ersten Zeile, die einen Fehler meldet — alles darunter ist meist Folgefehler.

Domains auf einen Dienst

Eine Domain auf einen Cloud-Dienst zu legen ist derselbe Vorgang wie beim Hosting: Adresse zuordnen, DNS zeigen lassen, Verschlüsselung abwarten. Details unter Domains, Subdomains, DNS & SSL.

Frage offen geblieben? Support kontaktieren

STRYKE Hub — betrieben von STRYKE Marketing UG (haftungsbeschränkt)