Onboarding Schritt 5: Erste Website verbinden

Der fünfte Schritt ist der wichtigste: Am Ende ist deine erste Kundenwebsite live. Die Seite läuft zuerst auf einer technischen Pagoras-Adresse, damit du sofort alles ausprobieren kannst. Die eigene Domain oder eigenes Hosting verbindest du danach in der Kundenansicht, das gehört bewusst nicht ins Onboarding.

Zwei Wege

• GitHub-Repo verbinden: Deine Website liegt schon als Code in einem Repository. Pagora deployt sie direkt daraus.
• ZIP hochladen: Du hast die Website-Dateien nur lokal. Pagora legt daraus automatisch ein Repository und das Hosting an.

Dazu in beiden Fällen: der Kunde/Projektname (Pflichtfeld). Damit wird dein erster Kunde im Cockpit angelegt, an dem die Website hängt.

Weg A: GitHub-Repo

Zuerst wählst du, wo das Repo liegt:

Privates Repo (empfohlen: GitHub-App). Der übliche Fall. Du klickst auf „Mit GitHub verbinden" und installierst die Pagoras-App auf eurem GitHub-Account — genau so, wie du es von anderen Diensten kennst. Bei der Installation wählst du unter „Only select repositories" aus, welche Repos Pagora sehen darf. Mehr ist nicht zu tun: Sobald die Installation abgeschlossen ist, springt der Assistent von selbst weiter und zeigt die freigegebenen Repos zur Auswahl. Ist genau ein Repo freigegeben, ist es schon vorausgewählt.

Fehlt ein Repo in der Liste? Auf GitHub unter Settings → Installed Apps → Pagoras die Freigabe um das Repo erweitern und im Assistenten auf „Aktualisieren" klicken. Dort kannst du die Verbindung auch jederzeit einsehen oder wieder entziehen — du behältst die volle Kontrolle.

Der Vorteil gegenüber einem Token: Es liegt kein dauerhaftes Geheimnis bei Pagora. Die App holt sich für jede Aktion einen kurzlebigen Zugriffsschlüssel (eine Stunde gültig), und es gibt kein Ablaufdatum, an das du denken musst.

Alternativ: mit Personal Access Token

Wenn du lieber einen Token nutzt (z. B. weil deine Organisation keine Apps erlaubt), geht das weiterhin:

1. Auf GitHub einen Fine-grained token erstellen (der Knopf im Assistenten führt direkt zur richtigen Seite; manuell: Settings → Developer settings → Personal access tokens → Fine-grained tokens).
2. Namen vergeben (z. B. „Pagoras") und Gültigkeit wählen, etwa 1 Jahr. Liegt das Repo in einer Organisation, diese als „Resource owner" auswählen.
3. Bei „Repository access" → „Only select repositories" nur das Kunden-Repo freigeben.
4. Unter „Permissions" → „Repository permissions" einzig „Contents" auf „Read and write" stellen. Mehr braucht Pagora nicht („Metadata" setzt GitHub automatisch dazu).
5. „Generate token" klicken und den Token (beginnt mit github_pat_…) kopieren. GitHub zeigt ihn nur dieses eine Mal an.

Sobald du den Token einfügst, prüft ihn der Assistent live und listet die Repos auf, die er sehen darf. Beachte: Fine-grained Tokens laufen ab — die GitHub-App-Verbindung nicht.

Öffentliches Repo (per URL). Du fügst einfach die Repo-URL ein (https://github.com/…). Der Assistent prüft automatisch, ob das Repo wirklich öffentlich ist, und sagt dir, wenn es privat ist oder die URL einen Tippfehler hat. Zum Deployen ist dann keine Verbindung nötig. Beachte aber: Damit der KI-Assistent später Änderungen machen kann, braucht er Schreibzugriff — die GitHub-Verbindung kannst du auch später im Cockpit unter „Einstellungen" herstellen.

Umgebungsvariablen (wenn das Repo welche braucht)

Sobald ein Repo gewählt ist, schaut Pagora hinein, ob eine .env-Vorlage existiert (.env.example und ähnliche Namen). Wenn ja, erscheint für jeden gefundenen Schlüssel ein Eingabefeld, Kommentare aus der Vorlage werden als Hinweis angezeigt. Die Werte (etwa API-Schlüssel) werden sicher beim Hosting hinterlegt, nicht im Code und nicht öffentlich, und sind schon beim ersten Deploy gesetzt.

Felder, die du leer lässt, werden einfach nicht gesetzt. Nachtragen und Ändern geht jederzeit in der Kundenansicht unter „Domain & Hosting", siehe Umgebungsvariablen.

Weg B: ZIP-Upload

Du wählst eine ZIP-Datei mit den Website-Dateien aus (oder ziehst sie ins Feld). Pagora entpackt sie, legt daraus ein Repository und das Hosting an und deployt. Ab dann ist auch diese Website versioniert wie jede andere.

Der Deploy: was du siehst

Nach „Verbinden & deployen" zeigt der Assistent den Fortschritt in drei Etappen: Kunde und Website angelegt, Hosting angelegt und Deploy gestartet, Website wird gebaut und veröffentlicht. Ein Live-Ticker zeigt, was gerade passiert (Repo auschecken, Abhängigkeiten installieren, bauen, Container starten). Ein Build dauert typischerweise zwei bis vier Minuten.

Drei mögliche Ausgänge:

• Live: Du siehst eine Vorschau deiner Website direkt im Assistenten und kannst sie über „Website ansehen" öffnen. (Lädt die Vorschau nicht, verbietet die Seite vermutlich die Einbettung, der Link funktioniert trotzdem.)
• Dauert länger: Nach ein paar Minuten macht der Assistent auch ohne fertigen Build weiter, der Deploy läuft im Hintergrund. Den Status findest du danach im Cockpit beim Kunden. Das Onboarding blockiert dich hier bewusst nicht.
• Fehler: Es gibt einen „Nochmal versuchen"-Knopf. Wenn es wiederholt hakt, prüfe, ob das Repo aus eigener Kraft baut (lokal npm run build bzw. der Build-Befehl deines Projekts) und ob alle nötigen Umgebungsvariablen gesetzt sind. Und sonst: tom@pagoras.de.