Grundkonzepte

Workspace

Ein Workspace bündelt deine Anwendungen, deine Teammitglieder, deine Integrationen und deine Rechnung. Er hat einen Namen und einen kurzen Namen für URLs – seinen Slug (acme) –, und sein Dashboard liegt unter cloady.com/w/acme.

Ein Workspace gilt für alle Regionen und alle Umgebungen; pro Standort musst du nichts einrichten. Alle, die du einlädst, sehen jede App darin, und ein einziges Abonnement deckt sie alle ab (Kapazität und Preis).

Anwendung

Eine Anwendung – im Dashboard „App“ genannt – ist etwas, das du deployt hast: eine WordPress-Website, eine Node-API, eine Postgres-Datenbank. Sie hat eine URL, Logs, Variablen, Speicher und einen Deploy-Verlauf, und du legst sie auf einem von drei Wegen an:

• Katalog – eine fertige App (WordPress, Postgres, n8n, …): auswählen, benennen, deployen.
• GitHub – eines deiner Repos, von Cloady gebaut und neu deployt, wenn du pushst.
• Upload – ein Ordner oder eine ZIP-Datei von deinem Rechner.

Woraus eine App besteht – ihre Services und ihre Volumes –, steht fest, sobald du sie anlegst. Die Ausnahme: Eine App, die aus einem GitHub-Repository mit Compose-Datei gebaut wird, übernimmt bei jedem Deploy Änderungen an dieser Datei. Ein Upgrade auf eine neuere Katalog-Version gibt es nicht; deploye eine neue App und migriere.

Jede App läuft in einer Region und einer Umgebung, die du beide beim Anlegen wählst, und ihr Name ist innerhalb deines Workspaces und der Umgebung eindeutig – blog in Production und blog in Preview sind also zwei verschiedene Apps, mit eigenen Daten und eigenen URLs.

Benennst du eine App um, ändert sich ihre URL, weil die Adresse dem Namen folgt. Die Änderung wird sofort wirksam, und sonst bewegt sich nichts: Daten, Variablen und eigene Domains bleiben, wo sie sind; du musst nur aktualisieren, was auf die alte Adresse verwiesen hat. (Bei Apps, die aus deinem eigenen Code gebaut werden, kannst du nicht mehr auf Deploys zurückrollen, die vor einer Umbenennung entstanden sind.)

Services und Endpunkte

• Ein Service ist ein Container innerhalb einer App – eine WordPress-App hat zwei: die Website und ihre MariaDB-Datenbank. Jeder erscheint einzeln unter Settings → Services mit einem Terminal-Button, und die Live-Logs der App können jeden Service getrennt anzeigen.
• Ein Endpunkt ist ein Port, auf dem ein Service lauscht, plus sein Protokoll. Ein veröffentlichter Port ist aus dem Internet erreichbar; ein nur intern freigegebener Port ist für die anderen Services der App über den Service-Namen erreichbar. Web-Ports bekommen eine https://-URL; Ports von Datenbanken und Gameservern sind reines TCP oder UDP und bekommen einen Host und eine Portnummer.

Eine App hat einen öffentlichen Hostnamen, auf dem ihr primärer Endpunkt antwortet – der erste HTTP-Endpunkt, den sie deklariert, oder ihr erster TCP-Endpunkt, wenn sie keinen HTTP-Endpunkt deklariert. Andere Services bekommen keinen eigenen Hostnamen; du erreichst sie innerhalb der App über den Service-Namen. Veröffentlicht eine App neben einer Website einen TCP- oder UDP-Port, verbinde dich mit diesem Port über die IPv6-Adresse, die auf der Seite der App angezeigt wird.

Region

Eine Region ist der Ort, an dem eine App läuft – derzeit usw1 (USA West), use1 (USA Ost), eu1 (Deutschland) und sin1 (Singapur). Du wählst sie beim Anlegen der App; später kannst du die App mit Transfer im Bereich „Danger zone“ ihrer Einstellungen verschieben. Eine App mit Volumes ist offline, während ihre Daten in die neue Region kopiert werden. Apps haben kein Failover zwischen Regionen; brauchst du eine App an zwei Orten, deploye sie zweimal.

Vorher musst du nichts freischalten. Ein neuer Workspace kann sofort in jede Region deployen, ob kostenlos oder bezahlt. In dieser Hinsicht stoppt nur ein Fehler einen Deploy:

• payment_required – die App würde den Workspace über sein Gratis-Kontingent bringen, und es ist keine Karte hinterlegt, oder die Karte wurde abgelehnt. Der Inhaber des Workspaces kann unter Account → Billing eine hinterlegen, oder du machst die App kleiner.

Hat eine Region keinen Platz für eine neue App, zeigt der Deploy ein paar Minuten lang Adding capacity…, während ein Server der Region beitritt. Kommt keiner hinzu, schlägt der Deploy fehl; versuch es erneut oder wähle eine andere Region.

Kapazität und Preis

Einen Plan wählst du nie aus. Die Apps eines Workspaces deklarieren, was sie brauchen – die Limits in ihren Compose-Dateien, multipliziert mit der Skalierung, die du wählst –, und die Summe wird anhand von vier Plänen bepreist:

• Die Summe landet im kleinsten Plan, der alle drei Ressourcen abdeckt, und wird zwischen diesem Plan und dem nächstkleineren bepreist. Trifft sie die Limits eines Plans genau, kostet sie genau dessen Preis; alles dazwischen liegt auch preislich dazwischen – die Rechnung springt also an keiner Grenze, und mehr anzufordern kostet nie weniger.
• Die Preise sind in jeder Region gleich, und du zahlst für das, was deine Apps deklarieren, nicht für das, was sie verbrauchen. Die Gratis-Stufe umfasst 200 GB ausgehenden HTTP-Traffic pro Monat; bezahlte Kapazität enthält unbegrenzten Netzwerk-Traffic.
• Ein Workspace, dessen Apps in 0,5 vCPU, 1 GB RAM und 5 GB SSD passen, zahlt nichts. Das ist eine Schwelle, kein Rabatt: Sobald auch nur eine Ressource darüber hinausgeht, wird der gesamte Workspace berechnet.
• Erhöhungen werden sofort für den Rest des Abrechnungszeitraums berechnet, und eine abgelehnte Karte blockiert die Änderung, statt sie zu gewähren. Verringerungen gelten ab deiner nächsten Verlängerung, sodass du behältst, was du schon bezahlt hast.

Umgebung

Jede App befindet sich in einer von drei Umgebungen – production, preview oder development:

• Namen kollidieren nicht über Umgebungen hinweg: blog in Production und blog in Preview sind getrennte Apps.
• Alle zählen zur Nutzung des Workspaces und zu seiner gemeinsamen Rechnung.
• Der Hostname enthält die Umgebung nicht; der eindeutige Code darin hält ein blog in Production und eines in Preview bereits auseinander.
• Apps in development werden bei einem Push nicht neu deployt, es sei denn, du schaltest das ein; Production und Preview tun das standardmäßig.

Region und Umgebung sind Teil der Dashboard-URL (cloady.com/w/acme/usw1/production/a/blog); über den Umschalter oben wechselst du, welche Apps du gerade siehst.

Domain

Eine Domain ist ein Hostname, der auf eine App zeigt; du verwaltest sie unter Settings → Domains:

• Integrierte Domain – der cloady.io-Hostname, den jede App bekommt. HTTPS wird für dich eingerichtet.

• Eigene Domain – ein Hostname, der dir gehört. Füge ihn hinzu und lege dann den DNS-Eintrag an, den der Bereich anzeigt: einen CNAME auf den integrierten Hostnamen für eine Subdomain oder die aufgeführten A- und AAAA-Einträge für eine reine Apex-Domain, die kein CNAME sein kann. Sobald DNS auflöst, holt Cloady ein Zertifikat von Let's Encrypt dafür; der Bereich verfolgt es als queued → pending → issued und zeigt failed mit einem Grund an, wenn der Eintrag nie aufgelöst wurde.

• Bei Cloady registrierte Domain – eine Domain, die du hier kaufst: über das Deploy-Feld (tippe einen Namen wie acme.dev), über das Formular Domains einer App, wenn der eingegebene Name noch frei ist, oder unter Workspace settings → Domains. Sie wird für ein Jahr mit WHOIS-Datenschutz registriert und gehört dem Workspace statt einer einzelnen App; mit Automatic DNS zeigen die Domain und jede Subdomain bereits auf Cloady, sodass du shop.acme.dev ohne DNS-Änderung mit einer beliebigen App verbinden kannst. Cloady verlängert sie einen Monat vor Ablauf und belastet dafür die Karte des Workspaces, es sei denn, du schaltest die automatische Verlängerung ab.

Der Button Open verwendet den integrierten Hostnamen. Markierst du eine Domain als primary (über die API oder Terraform), wird sie nur in der Liste entsprechend gekennzeichnet.

Workspace settings → Domains listet jede Domain im Workspace auf. Eine hier registrierte Domain bekommt einen Editor für DNS-Einträge (MX, TXT, CNAME und die übrigen, mit Vorlagen für gängige Mail-Anbieter); für eine Domain bei einem anderen DNS-Anbieter siehst du die Einträge, die du dort anlegen musst, und ob sie schon auflösen. Auch der eigene cloady.io-Hostname jeder App kann Einträge tragen, auf Namen darunter wie mail oder _verify.

Ressourcen und Skalierung

Die Nutzung eines Workspaces ist die Summe dessen, was seine Apps deklarieren. Es gibt keine Kapazität, die du vorab kaufen musst, und keine Obergrenze, an die du stößt.

Jeder Service läuft mit einem CPU- und einem RAM-Limit – mit dem, was die App deklariert, oder mit 0,5 vCPU und 1 GB, wenn sie nichts deklariert. Unter Settings → Resources skalierst du diese pro App, von 0,5× bis 4× in Viertelschritten, CPU und RAM getrennt; was eine App kostet, ist die Summe der Limits ihrer Services bei der aktuellen Skalierung.

Wenn du eine neue App deployst oder eine App hochskalierst, addiert Cloady ihre Limits zu allem, was schon deployt ist, und bepreist die neue Summe, bevor etwas angelegt wird. Innerhalb des Gratis-Kontingents wird nichts berechnet. Darüber hinaus wird die hinterlegte Karte mit der Differenz belastet; ohne Karte oder bei einer abgelehnten Karte bekommst du payment_required, und nichts ändert sich. Das Skalierungsformular zeigt die monatliche Differenz, bevor du speicherst.

Speicher verhält sich anders als CPU und RAM. Volume-Größen legst du pro Volume unter Settings → Resources fest, der Skalierungsfaktor berührt sie nie, und ein Volume kann wachsen, aber nie schrumpfen – die neue Größe gilt, sobald du speicherst, und lässt sich nicht rückgängig machen. Die Seite der App listet ihre Volumes mit dem Füllstand jedes einzelnen auf, und Browse files öffnet eines.

URLs

Cloady nutzt zwei Domains: cloady.com für das Dashboard, in dem Workspaces Pfade sind (cloady.com/w/acme), und cloady.io für deine deployten Apps.

Der Hostname einer App besteht aus ihrem Namen, einem kurzen eindeutigen Code und dem Namen des Workspaces. Er ist in jeder Region und jeder Umgebung gleich aufgebaut, und jede App bekommt ihren eigenen Code:

my-blog-k7q2v9ze-acme.cloady.io   production · usw1
my-blog-p3x8m1wd-acme.cloady.io   preview    · eu1

Der erste Teil ist der Slug der App, den du unter Settings → General bearbeiten kannst. Er folgt dem Namen der App, bis du ihn selbst festlegst; danach bleibt er, wie er ist, und eine Umbenennung der App ändert die URL nicht mehr.

Umgebungsvariablen

Settings → Environment enthält die Variablen, die die Services deiner App sehen. Als geheim markierte Werte werden nach dem Speichern verborgen und lassen sich einzeln einblenden, und du kannst eine .env-Datei einfügen, um viele auf einmal zu importieren. Eine Änderung wirkt sich beim nächsten Deploy aus – das Speichern einer Variablen startet nichts neu, was bereits läuft; nutze also Redeploy, um sie sofort anzuwenden.

Einige setzt Cloady selbst; in deinen eigenen Werten kannst du sie mit ${...} referenzieren:

Weiter geht es mit dem Dashboard-Leitfaden für die Arbeit in der Oberfläche oder mit dem API-Überblick, um Cloady programmatisch zu steuern.