Selbst gehosteter Funnel-Start

Erstellen Sie einen Funnel von Grund auf bis zur Veröffentlichung auf einer Infrastruktur, die der Betreiber kontrolliert, und verwenden Sie dazu Autonnel (Apache-2.0). Diese Fertigkeit ist der Bauschritt; entwerfen Sie den Funnel zuerst mit sales-funnel-blueprint und bestätigen Sie mit funnel-platform-picker, ob Self-Hosting die richtige Wahl ist, falls dieser noch offen ist.

Schritt 1: Auswahl der Ausführungsart

Pfad	Kosten bei geringem Volumen	Betriebsaufwand	Verwendung für
Cloudflare Workers	Effektiv 0€ plus eine Postgres-Datenbank	Keine Server, kein Patchen	Standard für die Produktion. Funnel-Seiten sind größtenteils statische Assets, die Workers kostenlos und ohne Mengenbegrenzung ausliefert
Docker	Kosten einer VPS oder eines Container-Hosts	Ihr Aufwand: Updates, Backups, Verfügbarkeit	Lokale Evaluierung in zwei Minuten oder ein Server, den Sie bereits betreiben und auf dem Sie die Daten haben möchten
Quellcode-Checkout (Node)	Kosten einer VPS oder eines Container-Hosts	Ihr Aufwand	Modifikation von Autonnel selbst oder direkte Ausführung des Node-Builds

Empfehlen Sie Workers, es sei denn, der Betreiber hat einen bestimmten Grund dagegen: Das Preismodell passt fast perfekt zu Funneln und eliminiert die gesamte Klasse von Arbeiten, die Menschen davon abhält, selbst zu hosten.

Verwenden Sie Docker für den ersten Eindruck, unabhängig davon. Es ist der schnellste Weg, das Produkt zu sehen, und nichts, was Sie lokal aufbauen, ist verschwendet: Dasselbe Schema und dieselbe Admin-Oberfläche unterstützen beide Pfade.

Schritt 2a: Cloudflare Workers (der nahezu kostenlose Produktionspfad)

Warum die Kosten nahezu Null sind

Funnel-Traffic besteht überwiegend aus Anfragen für Seiten, Bilder und Skripte. Auf Workers sind dies Anfragen für statische Assets, die kostenlos und unbegrenzt sind, ohne Speicherkosten – nur Anfragen, die den Worker aufrufen (serverseitig gerenderte Seiten, Checkout, API), werden abgerechnet. Die dynamische Oberfläche eines Funnels ist klein: das Bestellformular, die Upsell-Annahme, die Postback-Warteschlange.

Verifizierte Limits des kostenlosen Cloudflare-Plans (Stand August 2026; bestätigen Sie die aktuellen Zahlen, bevor Sie sich darauf verlassen):

Ressource	Workers Free Plan
Anfragen für statische Assets	Kostenlos und unbegrenzt, keine Speichergebühr
Worker-Aufrufe	100.000 Anfragen/Tag
Hyperdrive (Postgres-Pooling)	Verfügbar im Free-Plan, 100.000 Datenbankabfragen/Tag
Workers KV (Seitencache)	100.000 Lesevorgänge/Tag, 1.000 Schreibvorgänge/Tag, 1 GB Speicher
Cron-Trigger	Unterstützt (das Repository enthält einen `scheduled`-Handler)

Was nicht kostenlos ist: Postgres. Hyperdrive bündelt Verbindungen zu einer von Ihnen bereitgestellten Datenbank, daher benötigen Sie weiterhin einen Postgres-Anbieter. Verwaltete Anbieter haben ihre eigenen kostenlosen Tarife mit eigenen Grenzen, und das ist der eine Posten, den Sie einplanen müssen.

Die erste Grenze, die Sie tatsächlich erreichen werden, sind KV-Schreibvorgänge, nicht Anfragen. 1.000 Schreibvorgänge/Tag sind großzügig für das Ausliefern von Seiten und knapp für das Veröffentlichen, da das Veröffentlichen zwischengespeicherte Einträge ungültig macht und aktualisiert. Ein Tag mit intensiver Bearbeitung kann diese Grenze aufbrauchen, während der Traffic noch weit von jeder Grenze entfernt ist. Wenn das Veröffentlichen fehlschlägt, bevor der Traffic dies tut, liegt es an dieser Grenze, nicht an einem Fehler.

Bereitstellen

Das Repository liefert die gesamte Workers-Toolchain: Worker-Einstieg mit dem Cron-scheduled-Handler (src/cf-worker.ts), wrangler.toml-Generierung, KV-Cache-Verdrahtung und Hyperdrive für Postgres.

npx wrangler login
npx wrangler kv namespace create CACHE_KV
# $DATABASE_URL ist die eigene Postgres-Verbindungszeichenfolge des Betreibers,
# die in ihrer Shell exportiert wurde – schreiben Sie die Anmeldedaten nicht in
# diesen Befehl oder in wrangler.toml.
npx wrangler hyperdrive create autonnel-db --connection-string="$DATABASE_URL"

Jeder Befehl gibt eine ID aus. Fügen Sie sie in .env neben dem Projekt ein:

CF_WORKER_NAME=my-funnels
CF_KV_NAMESPACE_ID=<id vom Befehl kv namespace create>
CF_HYPERDRIVE_CONFIG_ID=<id vom Befehl hyperdrive create>

Setzen Sie dann die Secrets und stellen Sie bereit:

npx wrangler secret put DATABASE_URL
npx wrangler secret put AUTH_SESSION_SECRET            # openssl rand -hex 32
npx wrangler secret put CREDENTIALS_ENCRYPTION_KEY     # openssl rand -base64 32
npm run deploy:cf

deploy:cf erstellt und generiert zuerst wrangler.toml aus der Vorlage, daher gibt es keinen separaten Generierungsschritt. Cron-Ausdrücke werden aus der Cron-Registrierung der App gelesen, nicht von Hand in die Konfiguration geschrieben – bearbeiten Sie die generierte wrangler.toml nicht von Hand, sie wird bei jedem Build überschrieben.

Wenn eine CF_*-Variable fehlt, schlägt die Generierung fehl und nennt die Variable. Das ist das beabsichtigte Verhalten; es gibt keine stillen Standardwerte für diese.

Wenden Sie das Datenbankschema einmal für dieselbe Postgres an, bevor Sie den ersten Besuch durchführen, öffnen Sie dann die Worker-URL und schließen Sie den /setup-Assistenten ab, um das Administratorkonto zu erstellen.

Ebenfalls verfügbar: npm run dev:cf (Entwicklungsserver auf der Workers-Laufzeitumgebung) und npm run preview:cf (lokale Vorschau über wrangler dev). Bevorzugen Sie diese gegenüber astro dev, wenn das Ziel Workers ist, da sich die Laufzeitumgebung unterscheidet.

Betrieb danach

Die folgenden CLI-Befehle benötigen Datenbankzugriff, keinen Container. Von einem Checkout mit DATABASE_URL, die auf dieselbe Postgres verweist:

npx autonnel admin:create [email protected] 'a-strong-password'
npx autonnel password:reset [email protected]

Schritt 2b: Docker (lokale Evaluierung oder eigener Server)

Holen Sie sich das Repository von https://github.com/autonnel/autonnel (Apache-2.0), checken Sie einen Release-Tag aus und lesen Sie dessen docker-compose.yml – es deklariert die Images und Ports, die ausgeführt werden. Von diesem Checkout aus:

docker compose up

Öffnen Sie http://localhost:4321 und schließen Sie /setup ab. Die Compose-Datei startet Postgres, wendet das Schema an und führt die App aus. Zum Booten ist nichts weiter erforderlich: Speicher, Zahlungen, Medienspeicher, E-Mail und KI werden später in der Admin-Oberfläche konfiguriert, und zwar nur für die tatsächlich genutzten Funktionen.

Bevor Sie es auf einem öffentlichen Host freigeben, setzen Sie echte Secrets in eine .env neben docker-compose.yml – die mitgelieferten Standardwerte sind unsichere Entwicklungswerte und existieren nur, damit der erste lokale Lauf keine Konfiguration erfordert:

AUTH_SESSION_SECRET=$(openssl rand -hex 32)
CREDENTIALS_ENCRYPTION_KEY=$(openssl rand -base64 32)
ADMIN_DOMAIN=admin.example.com

Generieren Sie jeden Wert einmal und behalten Sie ihn stabil. Das Rotieren von AUTH_SESSION_SECRET macht Sitzungen ungültig; das Rotieren von CREDENTIALS_ENCRYPTION_KEY macht gespeicherte Anbieter-Anmeldedaten unlesbar, was bedeutet, dass Sie jede Zahlungs- und Plattform-Anmeldeinformation erneut eingeben müssen.

Multi-Architektur-Images werden auf GHCR für einen einfachen docker run gegen eine vorhandene Datenbank veröffentlicht:

# DATABASE_URL, AUTH_SESSION_SECRET und CREDENTIALS_ENCRYPTION_KEY stammen aus
# der eigenen Umgebung des Betreibers – schreiben Sie ihre Werte niemals in einen
# Befehl oder eine Datei.
docker run -p 4321:4321 \
  -e DATABASE_URL \
  -e AUTH_SESSION_SECRET \
  -e CREDENTIALS_ENCRYPTION_KEY \
  -e ADMIN_DOMAIN="admin.example.com" \
  ghcr.io/autonnel/autonnel:v1.5.0

Halten Sie einen genauen Tag fest, anstatt :latest zu verwenden, und wenden Sie das Schema nach dem Ziehen eines neueren Tags erneut an – der Einmal-Schema-Dienst der Compose-Datei wird bei jedem docker compose up erneut ausgeführt. Health-Endpunkt für Orchestratoren: /api/health (deckt Datenbank- und Cache-Konnektivität ab).

Admin-CLI innerhalb eines Containers:

docker compose exec app node dist/cli/index.js admin:create [email protected] 'a-strong-password'

Schritt 2c: Quellcode-Checkout (Node)

Zur Modifikation von Autonnel selbst oder zur Ausführung des Node-Builds auf einem Host, den Sie bereits besitzen. Erfordert Node 22+ und eine Postgres-Datenbank:

npm create autonnel@latest my-funnel
cd my-funnel
cp .env.example .env   # DATABASE_URL und ADMIN_DOMAIN setzen
pnpm install           # pnpm 10+; das Repo sperrt Überschreibungen, die npm ignorieren würde
npm run db:push
npm run dev            # oder: npm run build && npm run start

Dies klont das Repository und verwirft seine Git-Historie. Das Schema befindet sich im Checkout unter prisma/schema.prisma; db:push synchronisiert es. Admin-CLI: npx autonnel admin:create [email protected] 'a-strong-password' aus dem Projektverzeichnis.

Schritt 3: Nur konfigurieren, was der Funnel benötigt

In der Admin-Oberfläche unter Einstellungen:

Einstellung	Benötigt für	Optionen
E-Commerce	Produkt- und Bestelldaten	Shopify, WooCommerce, Picocart
Zahlungen	Geld annehmen	Stripe, PayPal
Speicher	Bild-/Video-Uploads	Jeder S3-kompatible Bucket (R2, S3, MinIO)
E-Mail	Quittungen, Recall-Kampagnen	SMTP, Resend, AWS SES
LLM	KI-Seitengenerierung	Jeder OpenAI-kompatible Endpunkt
Werbeplattformen	Server-seitige Conversions (alle vier); Ausgaben-/Klick-Reporting auf Anzeigenebene (nur Facebook, Google Ads, TikTok)	Facebook, TikTok, Google Ads, Bing

Reihenfolge der Vorgänge, um Nacharbeiten zu vermeiden: zuerst der Katalog (er bestimmt, was der Checkout verkaufen kann), dann Zahlungen, dann Speicher, dann E-Mail und zuletzt die Werbeplattformen – das Tracking wird anhand echter Bestellungen verifiziert, daher muss der Rest zuerst funktionieren. Die Verbindung einer Werbeplattform für das Ausgaben-Reporting ist ein separater Schritt von der Bindung an einen Funnel für das Postback (siehe server-side-conversion-tracking); führen Sie beide durch, wenn Sie beide wünschen.

Auf Workers ist R2 die offensichtliche Speicherwahl: Es ist S3-kompatibel und hält den Medien-Ausgang innerhalb von Cloudflare.

Schritt 4: Die Seiten erstellen

Funnel-Rollen werden direkt auf die Funnel-Spezifikation abgebildet:

Rolle im Funnel	Zweck	Mehrere pro Funnel?
`LANDING`	Einstiegsseite(n), eine pro Traffic-Winkel	Ja
`CHECKOUT`	Bestellformular	Nein – eine pro Funnel
`UPSELL`	Angebote nach dem Kauf, geordnet in einer Kette	Ja
`THANKYOU`	Bestätigung	Nein
`ERROR`	Zahlungsfehler / Fallback	Nein

Dies sind die Rollen, die eine Seite innerhalb eines Funnels einnimmt. Über die API ist der eigene Typ einer Seite CHECKOUT | THANKYOU | ERROR | UPSELL | CUSTOM – Landing Pages werden als CUSTOM erstellt und werden zu Landing Pages, indem sie als LANDING in einen Funnel gebunden werden.

Es gibt zwei Editoren: einen komponentenbasierten visuellen Editor, dessen Ausgabe diffbares JSON ist, und rohes HTML für importierte Seiten. Bevorzugen Sie den Komponenten-Editor für alles, was später A/B-getestet oder von einem Agenten bearbeitet werden soll – JSON-Diffs lassen sich sauber überprüfen, HTML-Blobs nicht.

Erstellen Sie den Checkout vor der Landing Page. Der Checkout bestimmt, was tatsächlich verkauft werden kann und zu welchem Preis, und eine zuerst geschriebene Landing Page verspricht etwas, das der Checkout nicht einhalten kann.

Schritt 5: Den Funnel verdrahten

Erstellen Sie den Funnel, hängen Sie dann die Seiten mit ihrer Rolle und Reihenfolge an.
Dieselbe Seite kann von mehreren Funneln referenziert werden. Die einzige Eindeutigkeitsregel, die die Domäne durchsetzt, ist, dass ein stepSlug innerhalb eines einzelnen Funnels eindeutig ist (und eine Seite erscheint höchstens einmal pro Funnel) – es gibt keine domänenübergreifende Zurückweisung, um die herum Sie entwerfen müssen. Klonen Sie eine Landing Page nur, wenn die beiden Funnel auseinandergehen sollen, da eine Bearbeitung einer gemeinsam genutzten Seite auf jedem Funnel landet, der sie referenziert.
THANKYOU und ERROR werden bei der Erstellung automatisch aus vorhandenen Seiten gebunden, falls welche existieren; wenn der Mandant keine hat, erstellen Sie sie vor dem Livegang. Ein Funnel ohne Fehlerseite schlägt bei abgelehnten Zahlungen stillschweigend fehl.
Die URL, die in Werbekampagnen geht, ist der eigene Slug der Landing Page auf einem Storefront-Host – https://shop.example.com/{page.slug} – niemals eine /n/-Schritt-URL. /n/{funnelId}/{stepSlug} leitet weiter zum nächsten Schritt, gehört also in den CTA-Link einer Seite, nicht in eine Anzeige. Wenn Sie den CTA auf diese Weise schreiben, bleibt der Pfad des Käufers stabil, wenn ein Schritt gegen eine andere Seite ausgetauscht wird.
Das Veröffentlichen ist explizit und versioniert pro Seite und pro Funnel – das Veröffentlichen einer Seite veröffentlicht nicht die Funnel-Bindung.

Schritt 6: Vor dem Senden von Traffic instrumentieren

Nicht verhandelbare Checks vor dem Start:

Ein echter End-to-End-Kauf, auf einem echten Zahlungsanbieter, einschließlich: Basisbestellung, ein akzeptierter Upsell, ein abgelehnter Upsell, die Dankesseite, die Quittungs-E-Mail und die Bestellung, die im verbundenen Shop erscheint.
Eine Rückerstattung für diese Bestellung, um zu bestätigen, dass der Rückerstattungspfad pro Belastung funktioniert.
Click-ID-Abdeckung – bestätigen Sie, dass fbclid / ttclid / gclid / msclkid den Bestelldatensatz erreichen. Siehe server-side-conversion-tracking.
Server-seitige Conversion, die ankommt im Event-Debugger jeder Werbeplattform, mit der angehängten Click-ID und keinem Duplikat gegen das Browser-Event.
Fehlerseite erreichbar, indem Sie eine abgelehnte Karte erzwingen.

Fügen Sie auf Workers einen weiteren hinzu: Bestätigen Sie, dass der Cron-scheduled-Handler ausgelöst wird (in der Warteschlange befindliche Postbacks und Recall-Kampagnen hängen davon ab). Ein Deployment, das stillschweigend seine Cron-Trigger verloren hat, sieht gesund aus, während die Hintergrundarbeit stillschweigend stoppt.

Erst dann die Ausgaben erhöhen. Ein Funnel, der noch keine echte Transaktion durchlaufen hat, hat eine unbekannte, nicht eine niedrige, Fehlerrate.

Schritt 7: Von einem Agenten über MCP betreiben

Die Instanz macht ihre Admin-API als MCP-Tools unter /api/mcp verfügbar, sodass ein Agent Funnel ohne die Benutzeroberfläche erstellen und ändern kann.

{
  "mcpServers": {
    "autonnel": {
      "transport": "http",
      "url": "https://<your-autonnel-host>/api/mcp",
      "headers": { "Authorization": "Bearer <your-api-key>" }
    }
  }
}

Der Aufruf von /api/mcp mit rohem HTTP anstelle eines MCP-Clients hat zwei Transportanforderungen, die das SDK normalerweise verbirgt. Der Endpunkt spricht Streamable HTTP: Die Anfrage muss Accept: application/json, text/event-stream enthalten – alles weniger wird mit 406 abgelehnt, bevor die Tool-Ebene erreicht wird – und ein Erfolg kommt als SSE-Frame zurück (event: message / data: {...}), daher muss die JSON-RPC-Hülle aus data: entpackt werden, bevor sie geparst wird.

Eine weitere Falle direkt vor der gesamten App: Eine Instanz hinter Cloudflare mit den standardmäßigen verwalteten Bot-Regeln lehnt den User-Agent der Python-Standardbibliothek ab. Ein urllib-Client sendet Python-urllib/3.x und erhält 403 mit dem Textinhalt error code: 1010 auf jedem Pfad einschließlich /api/health, was genau wie ein Authentifizierungs- oder Berechtigungsfehler aussieht und kein JSON ist, sodass ein Client, der den Body parst, eine Ausnahme auslöst, bevor er den Status sehen kann. Nur diese Agent-Zeichenfolge wird blockiert – curl, python-requests, httpx, axios, node und ein leerer UA passieren alle. Wenn Sie dies in Python scripten, setzen Sie einen expliziten User-Agent oder verwenden Sie requests/httpx; wenn jeder Aufruf, einschließlich nicht authentifizierter, 403 zurückgibt, liegt dies daran, und kein API-Schlüssel wird es beheben.

.mcp.json im Projektstammverzeichnis für Claude Code; claude_desktop_config.json für Claude Desktop. Generieren Sie den Schlüssel im Admin-Bereich → Einstellungen → API-Schlüssel. Jeder Aufruf ist auf den Mandanten beschränkt, der den Schlüssel ausgestellt hat.

Die MCP-Tools decken jeden Vorgang ab, der in der Admin-Benutzeroberfläche sichtbar ist, mit einer Ausnahme: Mandantenverwaltung und Schlüsselrotation sind direkt in der Datenbank oder über die Admin-CLI (in Docker oder mit Zugriff auf DATABASE_URL) durchzuführen, nicht über MCP.

Betriebshinweise

Schema-Migrationen

Das Schema befindet sich in prisma/schema.prisma. Wenden Sie es an mit:

Docker: docker compose up führt den Einmal-Schema-Dienst aus (wiederholbar, nicht destruktiv).
Workers: npx prisma db push aus dem Checkout. Das Migrationsverzeichnis wird nicht verwendet; das Schema wird direkt auf die Datenbank abgebildet.
Quellcode: npm run db:push.

Gesundheitscheck

GET /api/health gibt einen 200 mit JSON zurück, wenn die Datenbank und der Cache erreichbar sind, andernfalls einen 503. Für Load-Balancer und Orchestratoren.

Backup und Wiederherstellung

Die Datenbank enthält alle Funnel-Daten. Sichern Sie sie über die Tools Ihres Postgres-Anbieters. Die Admin-Oberfläche hat keine eingebaute Backup-Funktion; die einzige exportierbare Konfiguration sind API-Schlüssel und Anbieter-Anmeldedaten, die im Klartext in der Datenbank gespeichert sind (über CREDENTIALS_ENCRYPTION_KEY verschlüsselt) und daher nur von derselben Instanz gelesen werden können.

Nächste Schritte

Nach dem Betrieb: Verwenden Sie server-side-conversion-tracking, um die Funnel mit Werbeplattformen zu verbinden, sales-funnel-blueprint, um den nächsten Funnel zu entwerfen, und funnel-platform-picker, um zu entscheiden, ob Self-Hosting für diesen bestimmten Fall die richtige Wahl bleibt.

autonnel/autonnel-skills

Was ist autonnel-skills?

In Ihrer bevorzugten KI fragen

Dokumentation