Die WebBase‑Doku. Ein Link, dreißig Werkzeuge.

Schnellstart. In drei Schritten online.

Du brauchst ein kostenloses Konto und einen KI-Assistenten, der MCP kann. MCP (Model Context Protocol) ist der offene Standard, über den KI-Assistenten Werkzeuge bedienen. Damit schreibt deine KI nicht nur Code, sie veröffentlicht ihn auch.

1. Kostenlos registrieren

   Leg auf app.webbase.dev ein Konto an. Der Free-Plan kostet nichts und reicht für drei statische Websites.

   Kostenlos starten

2. Deinen persönlichen Link holen

   Im Dashboard findest du deinen persönlichen MCP-Link. Er enthält deinen API-Schlüssel wdp_… und sieht so aus:

   https://mcp.webbase.dev/mcp?token=wdp_••••••••••••

   Behandle den Link wie ein Passwort: Wer ihn hat, kann in deinem Namen Projekte anlegen und löschen. Im Dashboard kannst du Schlüssel widerrufen und neue anlegen.

3. Den Link deiner KI geben

   Trag den Link in deinem KI-Assistenten als MCP-Server ein, wie im nächsten Abschnitt beschrieben. Dann sag einfach, was du willst: „Bau mir eine Portfolio-Seite und stell sie online.“

Authorization: Bearer wdp_••••••••••••

Der erste Deploy. Ein Satz, drei Aufrufe.

Deploy heißt veröffentlichen: die Dateien bauen und unter einer Adresse ins Netz stellen. Du schreibst einen Satz, deine KI ruft die Werkzeuge auf. So sieht das aus:

Das Register. Dreißig Werkzeuge, acht Gruppen.

Alles, was deine KI bei WebBase tun kann. Zu jedem Werkzeug: wofür es da ist, ein Satz, mit dem du es auslöst, und die Parameter genau so, wie der Server sie prüft. Auswendig lernen musst du nichts. Deine KI bekommt dieselbe Liste beim Verbinden.

Projekttypen und Limits. Was in welchem Plan geht.

Jedes Projekt hat eine von drei Bauarten. Deine KI wählt sie beim Anlegen mit create_project, passend zu dem, was du bauen willst.

Datenbank. Postgres, von deiner KI eingerichtet.

Ab Basic bekommst du eigene Postgres-Datenbanken mit eigenen Zugangsdaten. Deine KI legt sie an, baut die Tabellen und verbindet sie mit deiner Seite. Fünf Schritte, alle per Werkzeug:

1. db_create_databaseLegt die Datenbank an.
2. db_queryLegt Tabellen an und liest oder schreibt Daten, in SQL.
3. db_get_connection_infoLiefert die Zugangsdaten und die fertige DATABASE_URL.
4. set_envHängt die DATABASE_URL verschlüsselt ins Projekt.
5. deployStartet das Projekt neu. Dein Code liest process.env.DATABASE_URL.

Eigene Domains. Deine Adresse, automatisch mit TLS.

In den bezahlten Plänen läuft dein Projekt auch unter deiner eigenen Domain. Das Zertifikat für HTTPS (TLS) kommt automatisch. Du setzt nur zwei DNS-Einträge bei deinem Domain-Anbieter, den Rest erledigt deine KI.

1. add_custom_domain meldet die Domain am Projekt an und liefert einen Prüfwert.
2. Du setzt einen TXT-Eintrag: Name _webbase-verify.deine-domain.example, Wert ist der Prüfwert. Er beweist, dass die Domain dir gehört.
3. verify_domain prüft den TXT-Eintrag.
4. Du setzt die Weiterleitung: einen CNAME von deiner Domain auf name.webbase.dev oder einen A-Eintrag auf die IP-Adresse, die das Werkzeug nennt.
5. verify_domain prüft die Weiterleitung und schaltet die Domain scharf. Ab dann antwortet dein Projekt unter https://deine-domain.example.

Wie viele Domains je Projekt gehen, hängt vom Plan ab. Eine Domain kann nur an einem Projekt hängen. DNS-Änderungen brauchen manchmal eine Weile, bis sie überall sichtbar sind; dann verify_domain einfach später noch einmal aufrufen. Wieder abmelden: remove_custom_domain.

Git. Für alle, die lieber pushen.

Jedes Projekt hat ein privates Git-Repository auf git.webbase.dev. Alles, was deine KI mit write_files schreibt, landet dort. Du kannst jederzeit selbst klonen und weiterarbeiten.

1. get_git_credentials liefert die Klon-Adresse mit eingebettetem Zugangsschlüssel. Gib sie nicht weiter.
2. Klonen, ändern, committen, pushen, wie gewohnt:

   git clone <clone-url>
   cd portfolio
   git add . && git commit -m "New start page"
   git push

3. Ein Push auf main oder master startet den Deploy automatisch.

Beides lässt sich mischen: Dateien per Werkzeug schreiben und per Git pushen. Hol vor dem Push mit git pull den neuesten Stand, damit nichts kollidiert.

Umgebungsvariablen. Geheimnisse getrennt vom Code.

Umgebungsvariablen sind Einstellungen, die dein Code beim Start liest, etwa ein API-Schlüssel oder die Adresse der Datenbank. Sie gehören nicht in die Dateien, sondern zu set_env.

Wo

In Next.js-Projekten, statischer Export und SSR. Statische HTML-Projekte haben keine Umgebungsvariablen.

Namen

Großbuchstaben, Ziffern und Unterstrich, beginnend mit einem Buchstaben: ^[A-Z][A-Z0-9_]*$. Höchstens 50 Variablen pro Aufruf.

Reserviert

PORT, NODE_ENV, HOME, PATH und HOSTNAME setzt die Plattform selbst.

Speicherung

AES-256-GCM-verschlüsselt.

Wirksam

Nach dem nächsten deploy.

Lesen

get_env nennt die Namen. Die Werte nur mit includeValues: true.

Team. Mitarbeit per Einladung.

Du kannst andere Menschen zu einem Projekt einladen. Sie bekommen eine E-Mail mit Link, auf Deutsch oder Englisch, und nehmen die Einladung selbst an. Wer noch kein Konto hat, registriert sich über den Link. Geteilte Projekte erscheinen bei ihnen in list_projects.

Mitglieder dürfen

Dateien lesen und schreiben, git push, deployen, Logs und Besucherstatistik lesen.

Mitglieder dürfen nicht

Umgebungsvariablen sehen oder setzen, Domains verwalten, das Projekt löschen.

Nur für Eigentümer

Einladen (invite_member), auflisten (list_members) und entfernen (remove_member). Beim Entfernen endet auch der Git-Zugang sofort.

Häufige Fragen. Kurz beantwortet.