Webiny: a self-hosted headless CMS that deploys into your own AWS account

The problem Webiny solves: content infrastructure you own

Most headless CMS products give you an API and a dashboard, then ask you to trust their hosting and their data model. Webiny takes the opposite position. The README describes it as an "Open-source content platform. Self-hosted on AWS serverless" and as "a TypeScript framework you extend with code, not a closed product you configure through a UI." Everything runs inside your own AWS account: Lambda for API and business logic, DynamoDB for content storage, S3 for assets, CloudFront for delivery, with OpenSearch optional for full-text search at scale.

The audience is narrow and stated plainly: "Built for developers at large organizations." The README claims production use by teams "managing hundreds of millions of content records, petabytes of assets, and thousands of editors." Those are the vendor's numbers, not independently verified here, but they describe the intended scale. If you are a solo developer building a blog, the machinery is disproportionate. If you are a platform team that must keep content inside a compliance boundary, white-label an editor for your own customers, or isolate tenants without running a deployment per customer, that is the case Webiny is built for.

How the serverless architecture is wired

The README's architecture diagram shows one AWS account containing four core services: Lambda (API and business logic), DynamoDB (content storage), S3 (assets) and CloudFront (CDN). OpenSearch and VPC deployment are listed as optional. All of it is provisioned through Pulumi infrastructure-as-code in a single deploy command.

The programmable layer is the Webiny Framework, a TypeScript framework with lifecycle hooks, dependency injection, GraphQL schema extensions, admin UI extension points and infrastructure extensions. Customization lives in an extensions/ folder and is registered in webiny.config.tsx. The README names four extension types, starting with API extensions for custom GraphQL schemas, resolvers, lifecycle hooks and business logic.

Multi-tenancy is the design decision worth pausing on. Tenants are isolated across data, users, assets and permissions from a single deployment, and the README states one instance can host thousands of tenants, created and managed programmatically through the GraphQL API. Tenant structures can be hierarchical, for example Root to Brand to Market. Compare that with the common pattern of one database or one deployment per customer: Webiny pushes isolation into the application layer, which removes per-tenant infrastructure sprawl but makes the tenant boundary a property of your code and configuration rather than of separate infrastructure. The README does not describe how that isolation is enforced internally, so treat it as something to inspect in the source before you rely on it for regulated data.

Installing Webiny and running a first deployment

The README lists prerequisites explicitly: Node.js 22+, Yarn, and an AWS account with programmatic access. The scaffold command creates the project, and the deploy command provisions the AWS stack.

npx create-webiny-project my-project
cd my-project
yarn webiny deploy

The README states the first deploy takes 5 to 15 minutes because AWS is provisioning resources. When it finishes you get an admin panel URL, where you create your first admin account. That URL is the entry point for the headless CMS, the website builder and the file manager.

For day-to-day work the README gives two watch commands. The first starts the admin React dev server, the second runs a local Lambda execution environment:

yarn webiny watch admin  # React dev server on localhost:3001
yarn webiny watch api    # Local Lambda execution environment

Onboarding a second developer is deliberately boring. The README's "New team member onboarding" section is a clone, an install, and nothing else:

git clone <your-repo>
yarn
# Ready to develop

That works because the infrastructure definition and the extensions live in the repository. The cost is that the repository now carries your cloud topology, so a bad merge can change production infrastructure. There is no staging environment mentioned in the README; the deploy command is described as provisioning into your AWS account without a named environment flag, so plan your account separation yourself.

The MCP server and what AI-assisted development actually changes

Webiny ships an MCP server and what the README calls AI skills, which give coding agents such as Claude Code, Cursor and Kiro context about the platform's architecture, extension points and patterns. The repository supports this claim structurally: there are .mcp.json, .claude/, CLAUDE.md, AGENTS.md, ai-context/ and skills/ entries at the top level, plus a scripts/generateSkills workspace in package.json.

The README's argument for why this works better here than on most platforms is worth quoting in part: the framework is "strongly typed with explicit extension points," so generated code "either fits the type system or it doesn't compile." That is a fair point about TypeScript, but it is a claim about compile-time correctness, not about design quality. An agent can produce a lifecycle hook that type-checks and still wires the wrong event. The MCP server narrows the search space; it does not remove review.

The setup instructions in the README are thin. It says the MCP server "runs locally inside your Webiny project" and points to the AI-Assisted Development guide for tool-specific setup, without printing the configuration. If you want to evaluate this feature before adopting the platform, the README alone will not get you there.

Where Webiny is the wrong tool

The AWS dependency is the first hard boundary. There is no documented path in the README to run Webiny on another cloud or on a plain VPS. If your organization is standardized on GCP or Azure, or if you want a single Docker container on a small server, this is not the project for you, and the README does not pretend otherwise.

Operational ownership is the second. The README frames serverless as removing servers, patching, scaling and capacity planning. That is true at the instance level and misleading at the stack level. You still own IAM, account limits, Lambda concurrency, DynamoDB capacity behaviour, CloudFront configuration and the Pulumi state. The README says you control everything and that the IaC templates are open-source, which is the same statement as: nothing is managed for you.

Third, the documentation has gaps that matter at evaluation time. The README does not document rollback, does not describe how tenant isolation is enforced internally, and does not show the MCP server configuration. The release history shows frequent patch releases (v6.4.8 on 2026-08-11, v6.4.9 on 2026-08-27, v6.4.10 on 2026-09-08), which suggests active maintenance but also means you should expect to upgrade regularly rather than pin and forget.

Finally, the licence metadata is a real ambiguity. The README badge says MIT, the repository metadata reports NOASSERTION, and the LICENSE file is the only authority. Resolve that before a legal review, not after.

How Webiny differs from Strapi and Payload

Strapi and Payload are the two headless CMS projects people most often compare against, and the difference is where the content lives. Strapi is typically deployed as a Node.js application with a database you choose, on a host you choose. Payload is a TypeScript CMS that commonly runs inside a Next.js application. Both let you run the CMS and the database on a single machine, and both offer managed hosting.

Webiny refuses that shape. It is not a Node process you start; it is a set of AWS resources you provision. The trade is explicit. You lose the ability to run the whole CMS on a laptop or a five-dollar VPS, and you gain per-request scaling, S3-backed asset delivery through CloudFront, and tenant isolation that does not require a database per customer. For a team already inside AWS, that is a smaller leap than it sounds. For a team that is not, the leap is the product.

The second difference is the extension model. Strapi and Payload both support plugins, but Webiny's README positions the framework itself, with lifecycle hooks and dependency injection, as the primary interface, and the admin UI as one consumer of it. Whether that is better depends on whether you want to write TypeScript against a framework or configure a product. Webiny assumes the former.

Maintenance, upgrades and licence questions to settle

The repository is not archived, and the last push was on 2026-09-10, with v6.4.10 released on 2026-09-08. That is a recent cadence, and the release list shows patch versions roughly every two to three weeks. The practical implication is that upgrades are a recurring task, not an annual project. The README does not document a rollback procedure, so the safe assumption is that recovery means re-deploying a previous commit of the Pulumi stack, which you should test before you need it.

Upgrade cost also scales with how far you have moved from the defaults. Every extension in extensions/, every GraphQL schema change, and every infrastructure modification is code you maintain against a moving framework. The README's own framing, "it's your infrastructure," is accurate and also the bill.

On licensing, the README badge points to an MIT licence and the repository metadata reports NOASSERTION. Do not treat the badge as the answer. Read the LICENSE file at the root of the repository, and if you plan to white-label Webiny inside a commercial product, which the README explicitly lists as a use case, have counsel read it too. Nothing here is legal advice; the point is that the two signals disagree and only one of them is a file.

Editorial conclusion

Adopt Webiny if you already run workloads in AWS, need tenant isolation inside one deployment, and have engineers who will maintain the Pulumi stack and the extensions/ folder. Do not adopt it if you want a vendor to host the CMS, if your team has no AWS account with programmatic access, or if a marketing team alone must own the stack. Before committing, verify three things: that the LICENSE file in the repository matches the MIT badge the README shows, since the repository metadata reports NOASSERTION; that Node.js 22 and Yarn are available on every developer machine; and that a first yarn webiny deploy into a sandbox account completes and can be torn down cleanly.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. webiny/webiny-js on GitHub