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

The short version

Three parts with distinct responsibilities

01 · Architecture

Do not force every website responsibility into the WordPress request path

WordPress manages content, editing and administration. Authentication, AI processing, workflow state and public delivery can have different scaling and access requirements. They can run in separate services while WordPress remains the place where the site is maintained.

Static Publisher can publish the site to S3 and CloudFront. It supports full and incremental publishing; after delivery, scheduled content-sync jobs can publish later content changes much faster than exporting the whole site again. Gatey connects the browser to Cognito, Flow calls the configured workflow backend, and AI-Kit uses supported local processing or a configured AI 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 they connect to their configured services from the browser. AI-Kit Pro can also synchronize selected approved public WordPress content to a compatible knowledge base. Search and cited chatbot answers use the changes after indexing; unpublished drafts and update proposals are excluded.

• 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 defines which page types, named content sections, fields and operations editors and compatible AI tools may use. The configured structural rules protect supported human editing as well as AI changes. Agent Canvas can provide the theme and reusable layouts; another compatible theme can also be used.

AI tools prepare native WordPress drafts for new content and separate update proposals for published pages. An editor can request revisions, reject a proposal or approve it for merging. Compatible shared structure changes can preserve each page’s own content; larger changes follow a reviewed migration. Publication and any later static release remain separate decisions.

• 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 WP Suite subscription purchased through AWS Marketplace that grants access to our published CloudFormation stack. Quick Launch opens the WP Suite Deployment Wizard, which guides the buyer through configuration and deployment into their own AWS account. Before deployment, the buyer reviews the account, Region, parameters and required IAM capabilities; CloudFormation provisions the resources defined in the template.

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.