Solution · Serverless backend
Serverless WordPress Backend
A practical model for using WordPress as the content layer while API Gateway, Lambda, Cognito, Bedrock and event workflows handle runtime behavior.
Short answer: A serverless WordPress backend moves runtime features such as authentication, forms, AI, protected APIs, KB/RAG ingest and workflow automation out of PHP and into focused AWS services. WP Suite makes those services more repeatable with deployment templates and a wizard flow that can generate prefilled CloudFormation Create stack links.
Why this matters
Dynamic WordPress is convenient until unrelated runtime concerns accumulate inside the same PHP/MySQL application: logins, forms, AI, file processing, API integrations and automation.
Scaling that monolith often means designing for peak load and paying for idle headroom. Serverless patterns let each runtime capability scale and fail independently.
The goal is not to make every WordPress site serverless. The goal is to move the parts that do not belong in PHP request handling into services that are better suited to the job.
Architecture and data flow
WordPress CMS / Gutenberg
↓ publishes UI and configuration
Browser-side WP Suite components
↓
API Gateway / Cognito / configured endpoints
↓
Lambda / Bedrock / DynamoDB / EventBridge / workflow services
↓
Responses back to the visitor or editor UI
Capability map
Guided deployment wizard
A wizard-driven deployment path can generate prefilled CloudFormation Create stack URLs for the major WP Suite backends, so the team chooses the pattern and then reviews/creates the stack in AWS.
Gatey Cognito infrastructure
Identity and token infrastructure can be deployed as a reusable CloudFormation/SAR stack, including Cognito email options and custom resource logic.
AI-Kit backend
Provides the deployment-facing backend contract for AI requests, chatbot/DocSearch, knowledge-base sync and Bedrock/RAG style workflows. The WordPress plugin points to the configured endpoint rather than hiding everything behind WordPress PHP.
Flow backend
Provides the deployment-facing contract for forms, submissions, workflow dispatching, webhook dispatching and event-driven operations.
Site Guardian
Adds a static-site protection stack when the same project needs S3/CloudFront delivery plus private paths, signed cookies and JWT-verified cookie issuance.
Static Publisher
Removes public page traffic from WordPress by publishing rendered pages to S3/CloudFront, while the remaining runtime behavior becomes explicit API-backed functionality.
Deployment units
A serverless WordPress backend is easier to reason about when each runtime concern has a clear deployment unit. The new deployment-wizard direction makes those units more repeatable: choose the stack, fill the meaningful parameters, review the generated CloudFormation link, then paste the resulting endpoint back into WordPress settings.
Cognito identity unit
User pool, app clients, token hooks and email delivery choices for Gatey and authenticated API scenarios.
AI-Kit AI unit
AI endpoint, chatbot/DocSearch, knowledge-base publishing, prompt templates and backend integrations.
Flow workflow unit
Forms API, submissions, workflow/webhook dispatching and event-driven automation.
Site Guardian edge unit
S3/CloudFront static delivery, protected paths, signed cookies and edge authorization.
Decision table
| Mode / dimension | Best for | Data path / approach | Trade-off |
|---|---|---|---|
| PHP runtime | Classic WordPress request handling | Browser → WordPress PHP/MySQL | Fast to start, harder to isolate and scale |
| Hybrid runtime | Only selected features move to AWS | Browser → WP + selected APIs | Good migration path |
| Static + serverless | Public pages static, features API-backed | CloudFront/S3 + APIs | Strong security/performance, more setup |
| Event-driven backend | Forms, emails and AI steps trigger workflows | Event → workflow → action | Requires event design and observability |
How this differs from the usual approach
All-in-WordPress plugin stack
Simpler hosting model, but every feature shares the same runtime and operational surface.
Separate custom app
Very flexible, but may replace WordPress editing and increase build complexity.
WP Suite serverless backend model
Keeps WordPress editing while moving selected runtime behavior to AWS services.
When this is a good fit
- WordPress sites with significant runtime features beyond content publishing.
- Static WordPress projects that still need forms, AI, authentication or protected APIs.
- Agencies standardizing deployments across clients.
- Teams that want client-owned AWS infrastructure for runtime behavior.
When not to use this
- A simple site with no backend needs.
- A team that cannot operate AWS or configure APIs.
- Use cases that require every request to be server-rendered by WordPress.
Implementation path
- List the runtime features currently handled by WordPress/PHP: auth, forms, AI, KB search, protected content, webhooks and automation.
- Decide which features stay in WordPress and which become AWS-backed APIs.
- Configure identity first when APIs or protected static paths must be tied to a user.
- Use guided CloudFormation/SAR deployment for Cognito, AI-Kit backend, Flow backend or Site Guardian as required.
- Copy resulting API base URLs, REST API names and stack outputs into the relevant WP Suite settings.
- For AI/RAG, prepare KB sources, metadata, markdown conversion and backend ingest before enabling visitor-facing chatbot or DocSearch.
- For forms/workflows, define submission storage, dispatch rules, retry behavior and webhook security.
- Add observability, CloudWatch retention, rollback paths and ownership documentation before production.
Related resources
Platform
overview of WordPress as CMS and AWS as runtime
WordPress for Agencies on AWS
agency standardization and client-owned infrastructure
Pricing
Free and Pro plan overview
Docs
implementation details
Flow
forms, workflow automation and frontend/backend submission patterns
Static Publisher
static delivery layer for WordPress pages
Gatey
authenticated API calls and Cognito identity
AI-Kit
AI agent and content intelligence layer
FAQ
Which backend stacks are relevant?
The main reusable units are Cognito/Gatey infrastructure, AI-Kit backend, Flow backend and Site Guardian for protected static delivery.
What is copied back into WordPress after deployment?
Typically stack outputs such as an API base URL, REST API name, site key, distribution details or other settings are copied back into the matching WP Suite admin screen.
What is Serverless WordPress backend?
A serverless WordPress backend keeps WordPress as the CMS while moving selected runtime features to cloud services such as API Gateway, Lambda, Cognito, Bedrock or event workflows. The goal is not to replace WordPress, but to avoid forcing every dynamic feature through PHP and MySQL.
Does this replace WordPress?
No. The recommended model keeps WordPress as the editorial and management layer. WP Suite adds cloud-native runtime capabilities around it rather than forcing a CMS migration.
Can this work with static WordPress?
Yes, when the required browser-side and API endpoints are reachable after export. Static publishing changes where the public HTML is served from; it does not prevent JavaScript components from calling configured APIs.
Is this only for large enterprise projects?
No, but it is most valuable when identity, security, AI, forms, workflows, protected APIs or repeatable AWS deployment patterns matter. For a simple brochure site, it may be unnecessary.
Does serverless WordPress mean WordPress disappears?
No. WordPress remains the CMS. Serverless applies to runtime features that are better handled by AWS services.
Is this cheaper?
It can be for variable traffic because runtime services scale on demand, but cost depends on usage, architecture and AWS configuration.
Can forms work without WordPress PHP?
Yes, Flow can submit directly from the browser to configured endpoints or to an optional backend.
Can AI workflows use the same backend model?
Yes, AI-Kit and Flow can connect to backend AI and workflow services where configured.
Move runtime-heavy WordPress features to AWS services
Move runtime-heavy WordPress features to AWS serverless services while keeping WordPress as the CMS and editor.