fastsite installieren

fastsite wird selbst gehostet. Sie betreiben die Engine auf Ihrem eigenen Server, sie erzeugt statische Ausgabe und überträgt diese Ausgabe in ein Git-Repository, das Ihr CDN überwacht. Weder Ihre Inhalte noch Ihre Zugangsdaten verlassen Ihre Infrastruktur.

Was Sie benötigen

• Einen Linux-Host mit Docker und dem Compose-Plugin. Zwei Kerne und 2 GB RAM genügen, um mehrere Sites zu betreiben.
• Eine Domain für die Engine selbst, die auf diesen Host zeigt, mit vorgelagertem TLS.
• Ein Git-Repository pro Site für die erstellte Ausgabe sowie einen Token oder Deploy-Key, der Push-Rechte hat.
• Einen statischen Host, der das Repository überwacht – Cloudflare Pages, Netlify oder alles andere, das bei einem Push baut.

Den Code holen

git clone https://github.com/sitepointsystems/getfastsite_gnu.git
cd getfastsite_gnu
cp .env.example .env

Konfigurieren

Öffnen Sie .env und setzen Sie die wenigen Werte, die die Engine über sich selbst wissen muss. Alles andere hat einen funktionierenden Standardwert.

Variable	Funktion
APP_URL	Die öffentliche URL der Engine. Sie ist der OAuth-Aussteller und die Basis, die MCP-Clients während der Erkennung bekannt gegeben wird, daher muss es die echte externe URL sein. Sie auf dem Localhost-Standard zu belassen, ist der mit Abstand häufigste Grund, warum ein Remote-Agent keine Verbindung herstellen kann.
APP_SECRET	Ein zufälliger Hex-String mit 64 Zeichen. Leitet den Verschlüsselungsschlüssel für jede gespeicherte Anmeldeinformation ab – Webhook-Secrets, GitHub-Tokens, Zwei-Faktor-Seeds. Einmal generieren und aufbewahren: Eine Rotation macht bestehende Secrets unlesbar.
DATA_PATH	Speicherort für Site-Datenbanken, Medien, Builds und site-eigene Git-Klone. Sichern Sie diesen Pfad.
REDIS_URL	Warteschlange, Sitzungen und Ratenbegrenzung. Der Compose-Stack setzt diesen Wert für Sie.
GIT_AUTHOR_NAME · GIT_AUTHOR_EMAIL	Die Identität in Veröffentlichungs-Commits. Beide haben Standardwerte.

Generieren Sie ein Secret mit:

php -r 'echo bin2hex(random_bytes(32)), PHP_EOL;'

Optional und nur bei Bedarf: R2_* für externe Backups zu Cloudflare R2, SHORTPIXEL_API_KEY für zusätzliche Bildkomprimierung vor der Variant-Pipeline und ENDPOINTR_*, wenn Sie Übersetzungen über Ihr eigenes KI-Gateway anstatt einen site-eigenen Schlüssel leiten.

Die Engine starten

docker compose up -d
docker compose logs -f

Migrationen werden bei jedem Start automatisch ausgeführt – für die Engine-Datenbank und jede Site-Datenbank. Der Queue-Worker und der Scheduler starten zusammen mit dem Webserver unter supervisor im Container – es gibt nichts Zusätzliches auszuführen oder am Laufen zu halten.

Prüfen Sie, ob es hochgefahren ist:

curl https://your-host/healthz

Den ersten Admin-Benutzer erstellen

Beim Starten des Containers wird die Datenbank migriert, aber kein Konto erstellt. Tun Sie dies einmalig und explizit:

docker compose exec app php bin/fastsite install \
  --email=you@example.com \
  --password='a-long-passphrase'

Das Passwort benötigt mindestens 12 Zeichen. Der Befehl kann sicher erneut ausgeführt werden – sobald ein Admin existiert, tut er nichts, er kann also nicht dazu verwendet werden, still einen zweiten hinzuzufügen. Jedes weitere Konto wird über das Dashboard erstellt.

Drei Dienste lauschen nun auf Ihrem Host:

Ihre erste Site erstellen

Eine Site wird durch ein unveränderliches Handle identifiziert. Sie erhält eine eigene Datenbank, einen eigenen Medienspeicher, eine eigene Shell und ein eigenes Build-Ausgabeverzeichnis.

docker compose exec app php bin/fastsite site:create blog \
  --name="My blog" \
  --url=https://example.com \
  --locale=en

Verweisen Sie sie anschließend auf das Repository, das Ihr CDN überwacht, und fügen Sie eine GitHub-Anmeldeinformation hinzu, die dort pushen kann. Beides sind Einstellungen der Site – github_repo und eine gespeicherte Anmeldeinformation – bearbeitbar über das Dashboard, die API oder durch einen Agent.

Aus Code ansprechen

Erstellen Sie einen bereichsbegrenzten API-Schlüssel und verwenden Sie ihn als X-API-Key-Header:

docker compose exec app php bin/fastsite key:create you@example.com \
  --name="Deploy pipeline" \
  --scopes=content:write,media:write,publish \
  --sites=blog

Das Secret wird einmalig ausgegeben und im Ruhezustand gehasht gespeichert – kopieren Sie es also, wenn es erscheint. Der vollständige Umfang ist auf der REST-API-Seite beschrieben.

Die Shell gestalten

Eine neue Site wird mit einer Standard-Shell eingerichtet: Twig-Templates, eine CSS-Token-Datei und UI-Strings. Dort lebt das gesamte Design – Inhalte kommen nur als Body-HTML an, sodass das Chrome einmalig gestaltet wird und nie wiederholt werden muss.

Lesen Sie wie es funktioniert, bevor Sie die Shell bearbeiten. Das Build-Audit erzwingt eingebettetes CSS, kein ausgeliefertes JavaScript und vollständige Head-Tags – ein Template, das einen PageSpeed-Punkt kosten würde, wird abgelehnt, anstatt es stillschweigend auszuliefern.

Aktualisieren

git pull
docker compose build --pull
docker compose up -d

Migrationen werden beim Start ausgeführt. Site-Datenbanken werden unabhängig versioniert, sodass ein Update die veröffentlichte Ausgabe nie berührt, bis Sie erneut veröffentlichen.

Backups

Alles Wesentliche befindet sich unter DATA_PATH. Die Engine kann außerdem auf Abruf einen Snapshot einer Site erstellen – vollständig, nur Datenbank, nur Medien oder nur die Shell – und jeden Snapshot über eine laufende Site wiederherstellen.

docker compose exec app php bin/fastsite backup:site blog
docker compose exec app php bin/fastsite backup:list blog

Bei konfiguriertem R2_* gehen diese Snapshots zu Cloudflare R2 und ein nächtlicher Satz läuft automatisch; ohne diese Konfiguration werden sie in das Daten-Volume geschrieben. Das Wiederherstellen einer Site-Datenbank löst stets einen Rebuild und eine Neuveröffentlichung aus, sodass Datenbank und veröffentlichte Ausgabe nie auseinanderlaufen können.