Managed Backend

Viele Apps brauchen mehr als eine statische Seite: Daten speichern, Formulare entgegennehmen, Nutzer anmelden. Dafür gibt es das Backend.

Verwaltetes Backend aktivieren

Erkennt Agentful beim Planen oder Bauen, dass deine App ein Backend braucht, schlägt es dir im Chat die Aktivierung vor — du bestätigst mit einem Klick, nichts wird still im Hintergrund eingeschaltet. Danach kümmert sich Agentful um Datenbank und Anbindung; deine App kann sofort Daten lesen und schreiben.

Die Konfiguration siehst du im Tab Backend deines Projekts.

Server-Actions

Deine App wird als statische Seite ausgeliefert und hat keinen eigenen Server-Prozess. Serverseitige Logik läuft als Server-Actions — kurze Funktionen, die Agentful für dich ausführt — oder auf einer eigenen API, die du verbindest (siehe unten).

Eine Server-Action ist eine Datei: .server/actions/<name>.js antwortet unter /api/p/{projectId}/actions/<name>. Deine App schickt JSON und bekommt JSON zurück. Hierhin gehören API-Keys und Logik, die nicht im Browser laufen darf — eine Zahlung anlegen, Mails versenden, einen Dienst aufrufen, der einen geheimen Schlüssel braucht. Die Schlüssel hinterlegst du im Backend-Tab unter Secrets; sie erreichen den Browser nie.

Grenzen. Plane mit 5 Sekunden je Action. Das ist ein Budget, kein garantierter Abbruch: Eine Action, die zu diesem Zeitpunkt noch auf einen Netzwerkaufruf wartet, wird mit einem Timeout beantwortet — bereits begonnene Aufrufe können trotzdem noch durchgehen. Die harte Grenze liegt bei 10 Sekunden. Speicher 256 MB, Request-Body bis 1 MB, 256 KB Quelltext je Action, 10 gleichzeitige Aufrufe je Projekt.

Der Schalter. Server-Actions laufen nur, solange der verwaltete Server im Backend-Tab eingeschaltet ist (Server → Verwaltet). Einschalten wirkt sofort, Ausschalten nach höchstens 60 Sekunden. Solange er aus ist, antwortet jede Action mit 404 (server_not_enabled) — auch Actions, die du mit der CLI gepusht hast: Ein Push legt die Dateien ab, er schaltet den Server nicht ein.

Kein Staging. Actions laufen aus dem Quellstand deines Projekts, nicht aus dem veröffentlichten Snapshot. Speicherst du eine Action im Workspace oder pushst sie mit der CLI, kann das sofort ändern, was deine veröffentlichte App tut; bereits warme Instanzen liefern bis zu fünf Minuten lang noch den vorherigen Code aus. Vorschau und veröffentlichte App teilen sich dieselben Actions und dieselben Daten.

Webhooks. Eine Action kann Webhooks empfangen und von der Plattform prüfen lassen, wer sie geschickt hat. Signiert der Absender seine Zustellungen, ist der erste Schritt der Action die Signaturprüfung der Plattform — ctx.webhooks.verifyStripe(…), ctx.webhooks.verifyGitHub(…) oder ctx.verifyHmac(…) für weitere HMAC-Verfahren wie Shopify oder Paddle. Das Signatur-Secret des Webhooks hinterlegst du im Backend-Tab unter Secrets; die Prüfung läuft auf der Plattform, das Secret erreicht den Code deiner Action nie, und eine Zustellung mit falscher, fehlender oder veralteter Signatur wird abgewiesen, bevor irgendetwas geschrieben wird. Der Request-Body steht genau so zur Verfügung, wie er ankam (ctx.rawBody), auch form-kodiert. Zwei Dinge bleiben Aufgabe der Action: zu prüfen, ob das Ereignis zur richtigen Bestellung gehört (ID, Betrag, Währung), und es zu vertragen, wenn dasselbe Ereignis zweimal ankommt.

Wenn du etwas brauchst, das Server-Actions nicht bieten

• Etwas nach Zeitplan (eine tägliche Zusammenfassung, ein nächtliches Aufräumen): wird nicht angeboten. Der Ausweg ist ein Scheduler außerhalb von Agentful — GitHub Actions, cron-job.org oder der Zeitplan eines Anbieters, den du ohnehin nutzt —, der eine deiner Actions aufruft und ein geheimes Token in einem Request-Header mitschickt. Diesen Scheduler richtest du selbst ein und betreibst ihn.
• Webhooks, die die Signaturprüfung der Plattform nicht abdeckt: Absender, die gar nicht signieren (etwa der Zahlungs-Webhook von Mollie), oder die mit etwas anderem signieren als einem HMAC über dein hinterlegtes Secret (asymmetrische Signaturen wie bei Discord; Secrets nach Svix-Art wie bei Resend oder Clerk).
  1. Das Ereignis nachschlagen. Die Action nimmt aus der eingehenden Anfrage nur die ID des Ereignisses, lädt das Ereignis mit deinem geheimen Schlüssel beim Anbieter nach und arbeitet ausschließlich mit den nachgeladenen Daten. Das belegt, dass das Ereignis echt ist — nicht, dass die Anfrage vom Anbieter kam. Deshalb prüft die Action zusätzlich, ob das Ereignis zur richtigen Bestellung gehört (ID, Betrag, Währung), und verträgt es, wenn dasselbe Ereignis zweimal ankommt.
  2. Ein vorgeschalteter Empfänger, der prüft — ein kleiner eigener Dienst, Hookdeck, Pipedream —, der danach deine Action mit einem geheimen Token aufruft. Das ist auch der Weg, wenn der Absender eine Antwort in seinem eigenen Format erwartet (etwa die URL-Verifizierung von Slack): Eine Action antwortet immer im JSON-Umschlag von Agentful.
  3. Ein Token in der Webhook-URL ist kein Ersatz: URLs landen in Logs und Dashboards.
• PDFs und Ähnliches: im Browser erzeugen oder aus einer Action eine externe API aufrufen. In einer Action lassen sich keine Bibliotheken installieren.

Eigenen Service anbinden (BYO)

Du hast schon eine Datenbank oder einen Server? Im Backend-Tab stellst du den Modus auf Eigener Service und hinterlegst deine Verbindung — Agentful baut die App dann gegen dein Backend.

Für den Server heißt das eigene API: Agentful leitet /api/* auf der Domain deiner App unverändert an deinen HTTPS-Endpunkt weiter. Die Plattform fügt nie ein Geheimnis hinzu und prüft nicht, wer aufruft — das ist Aufgabe deines Endpunkts. Was dein Endpunkt selbst kann — Zeitpläne, Bibliotheken, eigene Kryptografie —, funktioniert dort.

Nutzer-Logins

Apps mit verwaltetem Backend können eigene End-Nutzer-Konten haben (Registrierung, Login, Rollen). Mehr dazu

Wo liegen die Daten?

Verwaltete Backends laufen in der EU (Frankfurt) — wie alles bei Agentful. Mehr zum Datenschutz