Technisch

Öffne zuerst die Statusseite des Builds — jede Stufe hat einen Logs-Button, der genau zeigt, wo es scheiterte. Die meisten Fehler fallen in drei Kategorien: ein vorübergehender Infrastrukturhänger (Retry klicken), ein Codefehler, den die KI selbst beheben kann (Chat starten mit "der Build ist gescheitert, die Fehlermeldung ist: …" und die relevante Logzeile einfügen), oder ein Problem mit einem verbundenen Dienst (Stripe, GitHub, dein Domainanbieter). Trifft nichts davon zu, schreib Support mit der Projekt-ID — wir können die Pipeline manuell neu starten.

Drei häufige Ursachen. (1) DNS ist noch nicht vollständig propagiert — warte 5–15 Minuten und mach ein Hard Refresh. (2) Dein Browser hat ein älteres Asset gecached — öffne in einem Inkognito-Fenster. (3) Der Output des ersten Builds war syntaktisch gültig, aber logisch falsch — starte einen Chat mit "die Startseite ist leer, wenn ich sie öffne" und die KI behebt es beim nächsten Refinement. Die Browser-Konsole (F12 → Console) zeigt meist den eigentlichen Fehler.

Builds laufen in einer gemeinsamen Warteschlange. Free- und Starter-Pläne haben Standardpriorität und können in Stoßzeiten ein paar Minuten warten; Pro und Business haben Prioritätsslots und stehen fast nie an. Hängt dein Build länger als 10 Minuten in der Queue, ist das ungewöhnlich — lade die Seite neu (der Status läuft über Websocket, manchmal bricht die Verbindung ab), und falls er dann immer noch nicht startet, schreib Support mit der Projekt-ID.

Ja. Öffne das Projekt, klicke auf das Drei-Punkte-Menü und wähle "Redeploy". Dein Code bleibt exakt gleich — aber neue Environment Variables werden gezogen, abgelaufene Build-Artefakte werden neu gebaut, und Plattform-Verbesserungen (z. B. Security-Patches in der Runtime) werden angewendet. Ein Redeploy ohne Änderungen kostet 1 Credit und ist in unter einer Minute fertig.

Auf AWS, standardmäßig in der Region us-east-1. Statische Assets werden über das globale Edge-Netz von CloudFront ausgeliefert, sodass deine Besucher unabhängig vom Origin-Standort einen nahegelegenen PoP treffen. Server-seitiges Rendering läuft auf AWS Lambda, deine Projektdatenbank auf Amazon RDS Postgres, hochgeladene Dateien in S3. EU-Data-Residency steht auf der Roadmap, ist aber noch nicht verfügbar — lass den Support wissen, falls es für dich eine harte Anforderung ist.

Ja — der Code deines Projekts liegt in einem GitHub-Repo, das wir in deinem Namen angelegt haben. Öffne Einstellungen → Repository für die URL und um deinem Account Schreibrechte zu geben. Klonen, forken oder in eine andere GitHub-Org verschieben — alles wie bei jedem anderen Repo. Dasselbe gilt für deine Datenbank (wir zeigen unter Einstellungen → Datenbank → Export einen Postgres-Connection-String). Du behältst die Eigentümerschaft an Code und Daten; FloopFloop ist eine Deployment- und KI-Schicht obendrauf.

Ab Pro: Projekt öffnen, Einstellungen → Domains, „Domain hinzufügen" klicken und deine Domain eintragen (Root oder Subdomain). FloopFloop zeigt zwei DNS-Einträge an, die du beim Registrar setzen musst — einen CNAME (oder A/ALIAS für eine Apex-Domain) und einen TXT-Eintrag zur Verifikation. Sobald beide erkannt sind, wird SSL automatisch bereitgestellt und die Domain geht live, meist innerhalb von 5–30 Minuten. Free und Starter unterstützen keine eigenen Domains; dafür musst du upgraden.

Die meisten Probleme liegen am DNS. Prüfe, dass der CNAME- (oder A/ALIAS-)Eintrag existiert, auf den von FloopFloop angezeigten Wert zeigt und nicht hinter einem Proxy liegt, der unsere Verifikation blockiert (Cloudflares „orange Wolke" muss aus sein, bis die Verifikation fertig ist — danach kannst du sie wieder einschalten). Nutze `dig deine-domain.de +short` aus dem Terminal, um zu sehen, was die Welt sieht. Die Verifikation dauert meist unter 15 Minuten; bleibt sie nach einer Stunde auf „Pending", schreib Support mit der Domain.

Alle Secrets sind im AWS Secrets Manager mit AES-256 ruhend verschlüsselt und werden erst zur Laufzeit in der Runtime deines Projekts entschlüsselt — sie werden weder auf Disk noch in Build-Logs geschrieben. Sobald du ein Secret speicherst, ist der Wert write-only: Du kannst ihn aktualisieren oder löschen, aber nicht mehr aus dem Dashboard lesen. FloopFloop-Mitarbeiter haben keinen Zugriff auf Klartextwerte; wir sehen nur den Namen des Keys und Audit-Metadaten.

Ja. Öffne Einstellungen → Secrets, suche den Eintrag, klicke auf „Rotieren" und füge den neuen Wert ein. Innerhalb von ca. 30 Sekunden liest die laufende Runtime den neuen Wert (wir hot-reloaden Secrets und starten die Funktion nicht neu). Gehört das Secret zu einem Build-Time-Config (selten), siehst du ein Banner mit der Bitte um Redeploy — das dauert etwa eine Minute und kostet 1 Credit.

Sag der KI im Chat: „Füg einen Cron-Job hinzu, der täglich um 9 Uhr läuft und mir eine Zusammenfassung der Neuanmeldungen mailt." Die KI erzeugt eine `/api/cron/<name>`-Route in deinem Code, registriert den Plan (Cron-Ausdruck oder Intervall) und unser Scheduler hält die Registrierung bei jedem Redeploy synchron. Jeder Aufruf kommt mit einem projekt-scoped Bearer-Token, sodass nur unser Scheduler ihn auslösen kann. Läufe und Logs siehst du unter Einstellungen → Zeitpläne.

Auf macOS und Linux: `curl -fsSL https://floop.tech/install.sh | sh`. Auf Windows: lade den neuesten Installer von der GitHub-Releases-Seite des floop-cli-Repos herunter oder nutze `winget install FloopFloopAI.floop`. Nach der Installation `floop login` ausführen — das öffnet einen Browser, um dieses Gerät zu autorisieren. Danach funktionieren `floop new`, `floop refine`, `floop deploy` und der Rest der Befehle ohne weitere Einrichtung.

Ein CLI-Token ist die Credential, die `floop login` in deine lokale Config schreibt — sie identifiziert den menschlichen Nutzer auf einem konkreten Gerät, und du kannst sie unter /account/devices widerrufen, wenn du ein Laptop nicht mehr nutzt. Ein API-Key ist für unbeaufsichtigten Zugriff aus Skripten, CI oder Drittanwendungen — du legst sie unter /account/api-keys an, kannst sie auf Wunsch projektbezogen scoppen und jederzeit rotieren. Beide sprechen dieselbe `/api/v1/*`-Oberfläche an, aber nur API-Keys gehören in Automatisierungen.

Ja — die acht First-Party-SDKs (Node, Python, Go, Rust, Ruby, PHP, Swift, Kotlin) wrappen alle dieselbe `/api/v1/*`-Oberfläche und haben passende Methodennamen. Wenn wir einen Endpoint hinzufügen, spiegeln wir ihn in derselben Release über alle SDKs. Der MCP-Server (`@floopfloop/mcp`) macht das Node SDK für LLM-Agents verfügbar und erhält die neue Methode automatisch. Wenn dir doch eine Lücke auffällt, ist das ein Bug — öffne ein Issue im betreffenden SDK-Repo.