Serverlose Kontaktformulare: was „serverless" hier eigentlich bedeutet

„Serverless" begann als präziser Begriff: Ihr Code läuft als Funktion, auf der Infrastruktur eines anderen, und Sie müssen selbst nie einen Server bereitstellen, patchen oder skalieren. Auf Kontaktformulare angewendet, ist der Begriff abgedriftet - er wird inzwischen für zwei wirklich unterschiedliche Setups benutzt, und welches Sie wählen, ändert, wie viel Arbeit Sie sich damit einhandeln.

Hier ist die Unterscheidung - und wo ein gehostetes Formular-Backend hineinpasst.

Die zwei Dinge, die „serverloses Kontaktformular" bedeuten kann

Suchen Sie nach diesem Begriff, finden Sie zwei unterschiedliche Antworten vermischt:

• Sie schreiben eine Funktion. Eine AWS Lambda, ein Cloudflare Worker, eine Vercel- oder Netlify-Funktion - ein kleiner Handler, den Sie deployen und der den POST empfängt, über einen Anbieter wie SES oder Resend eine E-Mail sendet und eine Antwort zurückgibt.
• Sie schreiben überhaupt keinen Backend-Code. Ihr Formular sendet den POST direkt an einen gehosteten Dienst, der bereits existiert - keine Funktion zu schreiben, zu deployen oder zu versionieren.

Beides ist im engen Sinne „serverless": Bei keinem der beiden ist eine Maschine im Spiel, in die Sie sich per SSH einloggen und die Sie patchen. Aber sie liegen auf der Aufwandsskala an sehr unterschiedlichen Stellen.

Option A: Ihre eigene Funktion

Ihren eigenen Handler zu schreiben, gibt Ihnen volle Kontrolle über die Payload, die E-Mail-Vorlage und das Speicherziel. Diese Kontrolle bringt echte Verantwortung mit sich:

• Cold Starts. Eine Funktion, die längere Zeit nicht ausgeführt wurde, braucht einen Moment zum Hochfahren - das zeigt sich auf ruhigen Seiten als langsame erste Einsendung.
• E-Mail-Zustellbarkeit liegt bei Ihnen. SPF-, DKIM- und DMARC-Einträge, ein Sende-Ruf, den es zu schützen gilt, und ein Anbieterkonto, das konfiguriert und überwacht werden muss.
• Spam-Filterung liegt bei Ihnen. Nichts hindert einen Bot daran, direkt an die URL Ihrer Funktion zu POSTen, sofern Sie nicht selbst Rate-Limiting, einen Honeypot oder eine CAPTCHA-Challenge einbauen.
• Speicherung liegt bei Ihnen, wenn Sie überhaupt einen Verlauf wollen. Ohne einen Datenbankaufruf innerhalb der Funktion ist eine Einsendung, deren E-Mail-Versand fehlschlägt, einfach weg.

Das ist der richtige Kompromiss, wenn das Formular echte Geschäftslogik auslöst - ein CRM-Eintrag, ein Workflow-Start, alles jenseits von „die Nachricht zu einem Menschen bringen". Für ein reines Kontaktformular ist es eine Menge undifferenzierte Infrastruktur, die man sich aufhalst.

Option B: überhaupt kein Backend-Code

Die andere Lesart von „serverless" lässt die Funktion ganz weg. Ihr <form> sendet einen POST an einen Endpunkt, der bereits existiert, von jemand anderem betrieben wird, und bei dem Empfang, Spam-Filterung, Benachrichtigung und Speicherung bereits gebaut sind und bereits laufen. Sie schreiben null Backend-Code und deployen nichts - es gibt keine eigene Funktion, die Sie Cold-Starts, patchen oder überwachen müssten, weil überhaupt keine eigene Funktion im Spiel ist.

Der Kompromiss ist Kontrolle: Sie bekommen den Spam-Filter des Anbieters, dessen Aufbewahrungsrichtlinie, dessen Benachrichtigungskanäle - keine maßgeschneiderte eigene Logik. Für ein Formular, dessen ganze Aufgabe darin besteht, „die Einsendung zuverlässig zu mir zu bringen", ist das selten ein echter Preis.

Was tatsächlich zu einem Kontaktformular passt

Die meisten Kontaktformulare brauchen keine maßgeschneiderte Workflow-Logik - sie müssen einen Menschen erreichen, ohne verloren zu gehen oder als Spam gefiltert zu werden. Wenn das die ganze Aufgabe ist, löst das Schreiben und Betreiben einer eigenen Funktion ein Problem, das Sie gar nicht haben: Sie verbringen echte Stunden mit SPF-Einträgen und Rate-Limit-Logik, um neu zu erfinden, was ein gehostetes Backend bereits tut. Greifen Sie zu einer eigenen Funktion, wenn das Formular mehr speist als einen Posteingang - einen Datenbankeintrag, einen kostenpflichtigen Workflow, einen mehrstufigen Prozess, den ein generischer Dienst nicht abbilden kann. (Für das breitere Bild dessen, was ein Formular-Backend im Alltag leistet, siehe was ist ein Formular-Backend.)

Formhook: der Endpunkt, der bereits existiert

Formhook ist die zweite Art von serverless. Richten Sie ein Formular auf https://formhook.app/f/{apiKey} aus, und es gibt nichts zu deployen, cold-zu-starten oder zu patchen - nicht einmal eine Funktion. Spam-Filterung (ein Honeypot-Feld, Rate-Limiting und standardmäßig aktiviertes Cloudflare Turnstile), Speicherung, ein durchsuchbares Dashboard und Benachrichtigungen - E-Mail plus Web-Push auf jeder Stufe einschließlich Kostenlos - laufen bereits, bevor Sie eine einzige Codezeile schreiben. Ausgehende Webhooks mit automatischer Discord-, Slack- und Teams-Erkennung decken die Fälle ab, in denen Sie eine Einsendung tatsächlich an ein anderes System weiterreichen wollen - ohne dass Sie auch diese empfangende Funktion schreiben müssten.

Die kostenlose Stufe verarbeitet 250 Einsendungen im Monat, ohne dass eine Karte erforderlich ist. Pro fügt Datei-Uploads bis 10 MB und eine verifizierte Absenderdomain mit Reply-to hinzu; Studio hebt die Obergrenze für Teams auf 25.000 Einsendungen im Monat an. Die Integration selbst finden Sie in der Dokumentation, die vollständige Aufschlüsselung unter Preise.