Skip to main content

WP Suite Architecture​

WP Suite is built around one simple idea:

WordPress should stay the editing and control layer, while AWS handles the runtime-heavy parts around it.

That lets teams keep familiar content and admin workflows without forcing WordPress to become the identity provider, API gateway, workflow engine, static delivery platform, or AI runtime all at once.

The platform layers​

1. WordPress remains the workspace​

Editors keep using Gutenberg, Elementor, media workflows, SEO tools, and the normal WordPress admin model.

2. WP Suite products add focused capabilities​

  • Gatey connects WordPress to Amazon Cognito for login, SSO, MFA, and protected API access.
  • Static Publisher turns WordPress into the control plane for a static publishing pipeline that deploys to S3 and CloudFront.
  • AI-Kit brings local-first AI into WordPress and can optionally connect to a customer-owned AWS backend for grounded chat and knowledge-base use cases.
  • Flow adds form runtimes, workflow automation, templates, submissions, and backend-connected process logic.

3. AWS becomes the runtime​

Depending on the product mix, the runtime side can include services such as:

  • CloudFront for public delivery and protected-route enforcement,
  • S3 for static artifacts and shared assets,
  • Cognito for authentication,
  • API Gateway + Lambda for backend APIs,
  • DynamoDB / EventBridge / SES for application data and automation.

How the products fit together​

Gatey + Static Publisher​

Static Publisher handles the delivery pipeline. Gatey handles the browser-facing Cognito login flow. When a project needs protected static routes, add Static Guardian on the AWS side so CloudFront can enforce access before the request reaches the origin.

AI-Kit on static or dynamic sites​

AI-Kit can support editorial AI inside WordPress, but it can also power frontend chatbot or doc-search experiences that sit on top of a statically published site.

Flow beyond the brochure site​

Flow keeps forms and workflows connected to backend services even when the public pages are delivered statically. That lets teams keep the performance profile of static delivery without giving up submissions, automation, or protected workflows.

A practical rollout path​

Most teams do not adopt the full stack at once. A typical path is:

  1. keep the existing WordPress site and editorial workflow,
  2. add the first needed capability such as Cognito login or static publishing,
  3. move the public delivery path to AWS,
  4. add AI, forms, workflows, or protected APIs as the project grows.

Where to go next​