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

The short version

One platform, four responsibility layers

The architecture problem

“All in one” should not mean “everything inside one runtime”

WordPress is very good at the work for which teams choose it: modeling content, editing pages, managing media, assembling layouts, and giving non-developers a practical administration surface. The friction usually starts after the page itself is finished. A client portal needs identity. A knowledge experience needs model access and retrieval. A multi-step form needs durable state and actions after submission. A public site may need static edge delivery, while selected paths still need access control.

There are three common reactions. One is to keep adding responsibility to the WordPress server until it becomes the identity provider, application API, workflow engine, AI proxy, and public delivery origin at the same time. Another is to bolt together unrelated SaaS products and accept several control planes, invoices, and data boundaries. The third is to replatform the whole project even though the team still wants WordPress as its CMS. WP Suite takes a narrower approach: keep WordPress where it is strong, and move only the runtime responsibilities that benefit from a separate AWS boundary.

• Content and editorial responsibility remain in WordPress: posts, pages, media, Gutenberg blocks, SEO metadata, configuration, and the workflows editors already understand.
• Integration responsibility belongs to the WP Suite components: authentication UI, AI tools, forms, browser utilities, API configuration, publishing jobs, and the handoff between WordPress and AWS.
• Runtime and delivery responsibility can move to the customer’s AWS account: Cognito, APIs, Lambda functions, storage, events, model access, CloudFront, protected routes, logs, and optional recovery resources.

That is the useful meaning of an all-in-one platform here. The components share an architectural model and can form one production path, but they remain modular. A site can start with static publishing, Cognito login, a Flow form, or on-device AI. It does not have to deploy every backend or buy every commercial layer before the first feature becomes useful.

The component map

What each WP Suite component supports

Gatey is the identity and access layer. It places sign-in, registration, confirmation, password recovery, MFA, profile, and account experiences into WordPress through Gutenberg blocks, Elementor widgets, or shortcodes. The important architectural detail is that credentials do not need to pass through WordPress PHP. The browser communicates with the configured Amazon Cognito User Pool, while Gatey keeps the presentation and site integration in WordPress. The same browser-based path can continue to work after a static export. When a project needs protected APIs, Gatey can support Cognito JWT authorization or IAM-signed requests through an Identity Pool.

AI-Kit covers two different workloads without pretending they require the same runtime. Its free editor and media workflows can use supported on-device AI in desktop Chrome for generation, rewriting, translation, proofreading, summaries, and image metadata. When a project needs a reliable fallback, broader model access, a frontend chatbot, DocSearch, or knowledge retrieval, Pro can connect the same WordPress experience to a configured backend. WordPress still manages the content and knowledge sources; the customer-owned AWS backend can handle API routes, model invocation, storage, retrieval, and protected admin or frontend operations.

• Flow builds forms and guided processes in WordPress: field and layout blocks, conditional paths, multi-step journeys, modals, galleries, validation, and direct browser submission. Pro adds the path to durable submissions, save and resume, email templates, webhooks, EventBridge-style routing, and backend workflow actions in the customer’s AWS account.
• Static Publisher turns rendered WordPress output into a repeatable deployment. It crawls pages with a browser-aware engine, discovers required assets, rewrites URLs for the selected target, uploads the result to Amazon S3, and invalidates CloudFront. The free workflow supports a full-site crawl and publish; Pro adds capabilities such as incremental delivery, scheduling, and multiple deployment profiles.
• Static Site Guardian protects selected routes in a statically delivered frontend. It combines private S3 delivery, CloudFront behavior, Cognito-compatible identity rules, and signed-cookie or edge enforcement patterns so a site can keep public routes public while blocking delivery of protected content before it reaches an unauthenticated browser.

These components are useful independently, but the combined model is stronger. Gatey can establish identity for a Flow journey or a protected API. AI-Kit can provide knowledge-grounded assistance before a user confirms a form. Static Publisher can move the public site away from the WordPress origin, while Gatey, Flow, and AI-Kit keep selected interactions alive through browser-to-AWS calls. Static Site Guardian can enforce delivery rules for the routes where frontend visibility controls are not enough.

Infrastructure delivery

Deployment Access turns the reference architecture into a repeatable deployment path

A diagram and a collection of CloudFormation templates are not yet a delivery system. Someone still has to collect valid project settings, choose the required modules, establish commercial access, launch the stack in the intended account and Region, capture the resulting identifiers, and connect those outputs back to the WordPress site. The same work has to remain understandable when the infrastructure changes later. Deployment Access is the AWS Marketplace product that covers this path for supported WP Suite backends.

The Deployment Wizard prepares the supported component choices and configuration. AWS Marketplace Quick Launch then opens the CloudFormation review in the buyer’s AWS account. The buyer reviews parameters, IAM capabilities, target account, and Region before explicitly starting the deployment. The root orchestration validates the authorized deployment, stages private runtime packages into a buyer-owned deployment bucket, and creates the selected nested component topology. The public CloudFormation definitions remain reviewable, while paid runtime artifacts are available only through the authorized path.

• The current public bundle covers a Cognito identity foundation, AI-Kit Backend, Flow Backend, Static Site Guardian, and an optional DR Backup component for scheduled protection of supported, deployment-tagged S3 and DynamoDB resources.
• A project selects only the resources it needs. The common wrapper topology may remain visible in CloudFormation, while conditions prevent unselected component resources from being created.
• Supported outputs—such as API URLs, Cognito identifiers, distribution details, and configuration locations—are returned to the matching deployment session so WP Suite can generate the corresponding WordPress Pro site configuration.

Updates follow the same ownership rule. WP Suite can prepare a supported CloudFormation change set, but the buyer reviews and executes that change in AWS. There is no hidden production update channel. The latest public deployment definitions and architecture guide are available at https://github.com/smartcloudsol/wpsuite-deployment-templates, while the commercial entitlement and Quick Launch path are provided through the live Deployment Access listing on AWS Marketplace.

Commercial boundaries

Why Deployment Access and the Agency Subscription are separate Marketplace products

The two AWS Marketplace offerings solve different problems. Deployment Access is tied to infrastructure delivery in one buyer AWS account. The current public contract is USD 500 for 36 months and provides the supported deployment and update path for that account. It does not include the AWS services consumed by the deployed resources, WordPress hosting, custom development, or ongoing managed operations. The buyer owns and pays for the AWS environment and remains responsible for production policy, cost, and approval.

The Agency Subscription is tied to WordPress-side Pro access across managed sites. An agency selects a discounted baseline for 10, 20, 50, or 100 active sites and can exceed that baseline through metered hourly overage. The workspace becomes the commercial and administrative layer for assigning, monitoring, and revoking site access across the plugin suite. It is an efficient option when several client sites need Pro capabilities, but it is not required to purchase Deployment Access.

• For one project, a team can use free plugin capabilities, add a site-based Pro subscription where needed, and purchase Deployment Access only if supported customer-owned AWS backends must be deployed.
• For an agency portfolio, the Agency Subscription can centralize Pro entitlements while each client AWS account that receives WP Suite infrastructure has its own Deployment Access coverage.
• For an existing architecture, teams can install the relevant plugins and connect them to services they already operate. Deployment Access is a supported deployment route, not a rule that every project must replace existing AWS resources.

Keeping these contracts separate also keeps the responsibility map honest. A site licence should not be presented as ownership of the customer’s infrastructure, and an infrastructure deployment entitlement should not silently become a per-site plugin subscription. Both are available through AWS Marketplace, but they measure different units, follow different lifecycles, and can be adopted independently.

Who provides what

A complete solution still has accountable owners

The delivery sequence

The complete WordPress-to-production pipeline

1 — Scope the project. Begin with the visitor and editor journeys, not an AWS service list. Decide which responsibilities belong in WordPress and which need a separate runtime: identity, protected APIs, AI and knowledge retrieval, durable forms and workflows, static delivery, protected routes, or scheduled recovery. Select only those WP Suite components. If the project will use paid features across several client sites, attach the appropriate Agency Subscription workspace; if it needs supported backend deployment in a buyer account, establish Deployment Access for that account.

2 — Provision the runtime. Configure the supported components in the Deployment Wizard, open AWS Marketplace Quick Launch, and let the buyer review the CloudFormation parameters and permissions in AWS. After a successful deployment, capture the outputs and generate the matching WordPress site configuration. Connect Gatey to Cognito, AI-Kit to its selected local or backend mode, Flow to the intended endpoint and authorization mode, and Static Publisher or Static Site Guardian to their deployment targets.

3 — Build and verify in WordPress. Editors and developers create content, authentication screens, forms, knowledge sources, AI surfaces, navigation, and SEO metadata in the normal WordPress environment. Test both editor and visitor paths, including signed-in and signed-out behavior, form validation, API authorization, error handling, mobile layouts, and the behavior expected after static export.

4 — Render and publish. Static Publisher visits the rendered site, captures the HTML and assets actually required by the frontend, rewrites source URLs for the selected staging or production target, uploads the deployment output to S3, and refreshes CloudFront. Pro workflows can narrow later runs to changed output and keep staging and production profiles separate.

5 — Run the production experience. CloudFront serves public pages and, where configured, Static Site Guardian enforces protected delivery. Gatey communicates with Cognito from the browser. Flow sends confirmed submissions to the configured webhook or AWS backend. AI-Kit keeps eligible work on-device and sends backend-enabled requests to the configured API. Public page traffic does not have to return to the WordPress origin.

6 — Change deliberately. Content updates return through the same WordPress-to-publish path. Infrastructure updates return through the Deployment Wizard and CloudFormation change-set path. Site entitlements remain visible in the workspace, while AWS logs, alarms, backup status, cost, security policies, and operational response remain inside the customer’s ownership model. The result is not a magic publish button; it is a repeatable handoff between systems with clear review points and rollback boundaries.