From WordPress to production on AWS: how the complete WP Suite platform fits together

The short version

One platform, three responsibility boundaries

01 · Architecture

Do not force every website responsibility into the WordPress request path

WordPress is strong as a CMS, editor and administration surface. Problems appear when the same PHP and database runtime is also expected to become the public delivery origin, application identity provider, AI proxy and workflow engine for every request.

WP Suite separates those jobs. Static Publisher can move cacheable page delivery to S3 and CloudFront. Gatey can use Cognito for browser identity. Flow can keep process state behind an API. AI-Kit can use supported local execution or a configured backend.

• Use Keep WordPress for Editing Without Exposing WordPress Publicly when WordPress should remain the private editing origin.
• Use Make WordPress Static Without Losing Dynamic Features when static delivery must keep selected live features.
• Use Handle WordPress Traffic Spikes Without Scaling PHP and MySQL when public traffic should stop scaling the PHP/MySQL page path.

The result is not one mandatory stack. It is a set of explicit boundaries that can be adopted only where the project needs them.

02 · Identity, AI and workflow

Each dynamic responsibility gets its own operating model

Gatey places Cognito-backed login, registration, MFA, profiles and supported federation into WordPress while authentication remains browser-to-Cognito. AI-Kit separates supported on-device tasks from optional configured backend processing and retrieval. Flow separates the form experience from durable drafts, submissions, discussion, review state and workflow actions.

These components can work on a dynamic site or alongside static delivery because their runtime does not have to be the same system that renders every public page.

• Identity: Use Amazon Cognito Instead of WordPress as the Application Identity Layer and Add Login to Static WordPress Without Bringing PHP Sessions Back.
• AI: Use AI in WordPress Without Sending Every Draft Through an AI SaaS and Give Visitors Answers from Your WordPress Content — With Sources.
• Workflow: Replace Email and Spreadsheet Approvals with a WordPress Workflow and Build a WordPress Review Workflow with Forms, Discussion and Ratings.

Start from the buyer problem first. The product and AWS layer should follow from that requirement rather than define it.

03 · Governed editing

AI-assisted change and production release remain different decisions

Agent Composer adds a governed execution boundary after a site already has a design system and content model. A compatible agent works through approved page types, patterns, fields and abilities instead of receiving unrestricted WordPress administration.

The output remains native WordPress content and the agent workflow stops at reviewable drafts. Human publication and any later static production release are separate steps.

• Use Create New WordPress Content with AI and Keep It Native and Editable when native editable output is the priority.
• Use Let Clients Create New WordPress Pages with AI Without Breaking the Design System when clients must stay inside the design system.
• Use Let AI Edit WordPress Without Giving It Unrestricted Administrator Access and Give Clients AI After Website Handoff Without Losing Agency Design Control for permission and handoff boundaries.

This keeps the system of record, design rules and production decision inside WordPress even when AI helps create the next content item.

04 · Deployment

Customer-owned infrastructure should remain a visible responsibility boundary

Deployment Access is the supported AWS Marketplace deployment path for selected WP Suite backend families. Quick Launch is the guided deployment flow, not a separate product. The buyer reviews the AWS account, Region, parameters and IAM capabilities before CloudFormation creates the selected resources.

This is intentionally separate from plugin or agency access. Owning the backend means the customer or delivery team also owns AWS service costs, operational policies, monitoring and production approvals.

• Use the customer-owned model only when that infrastructure boundary provides real value.
• Keep site subscriptions and AWS deployment entitlements conceptually separate.
• Document what WordPress owns, what the WP Suite component owns and what the buyer AWS account owns.

For the deeper system map, see WP Suite Platform and WordPress + AWS Reference Architecture.