Webiny runs on AWS serverless infrastructure, inside your own account. Here's why that decision was made, and what it means for you.

Infrastructure Requirements

The only infrastructure requirement for hosting Webiny is an AWS account. Webiny is built to run on AWS serverless services, which provide a scalable and cost-effective way to deploy applications.

Why Serverless, why AWS-only?

Let's address the obvious question first: why not containers?

Containers are a solid choice for general application deployment. But running a self-hosted content platform on containers still means someone needs to manage cluster orchestration (ECS or EKS), define and tune auto-scaling policies, handle node provisioning, patch the underlying infrastructure, monitor for and recover from node failures, and right-size everything to avoid paying for idle capacity. That's not infrastructure you "set and forget." That's a part-time DevOps job — before you've written a single line of application code.

And here's what most teams underestimate: getting that setup right takes months. Not weeks. You need to load test it, find the bottlenecks, tune the scaling thresholds, harden the network perimeter, set up proper IAM boundaries, validate the backup and recovery process, and then document all of it so the next engineer can understand what's running and why. Most teams skip half of those steps. That technical debt eventually comes due.

Webiny made a deliberate architectural decision: build on AWS serverless primitives — Lambda, DynamoDB, S3, CloudFront, SQS, Cognito — so that none of that operational surface falls on you.

What you get instead is a single, battle-tested setup — one that has been proven across the full spectrum of load and organizational complexity.

The same infrastructure configuration runs a solo developer's hobby project and a government institution handling millions of concurrent users during peak demand. It powers a startup's first content API and a global financial institution's regulated content operations. That breadth isn't an accident. It means the edge cases have been encountered, the failure modes have been discovered, and the fixes are already baked in.

There's no cluster to manage. There's no capacity to provision upfront. Scaling is not a configuration knob you tune; it's a property of the platform. The same Lambda function that handles 10 requests a day will handle 10,000 requests a day without touching the infrastructure. If a function fails, it's automatically retried. If a service degrades, traffic reroutes. The platform is self-healing by design — not by your team's on-call rota.

The IaC templates shipped with Webiny reflect years of production hardening. They've been reviewed by AWS solutions architects for best practices, and audited by security teams inside multiple enterprise and government organizations with strict compliance requirements. Multi-AZ deployments, automated backups, VPC isolation, encrypted storage, and tightly scoped IAM permissions come configured out of the box. That's not a checklist you fill in before go-live — it's already done.

The AWS-only choice is intentional, not an oversight.

Supporting multiple cloud providers would mean abstracting away the very primitives that make this architecture work — and building to the lowest common denominator. Every cloud has serverless offerings, but AWS's ecosystem is the most mature, most audited, and most widely accepted for regulated industries. Government agencies, financial institutions, and healthcare organizations that have strict data residency and security requirements have cleared AWS. That clearance doesn't come cheap or fast, and Webiny inherits it.

Everything runs inside your own AWS account. Webiny doesn't touch your data, your keys, or your infrastructure. You own the AWS resources. You control the IAM policies. You control the network perimeter. If Webiny ceased to exist tomorrow, your infrastructure keeps running and you have full access to the source to maintain it.

Why self-hosted?

Self-hosting is not just a deployment preference. For a content platform sitting at the center of your organization's digital operations, it's an architectural decision with long-term consequences across four areas:

Data ownership and control

With a SaaS CMS, your content, assets, and metadata live in someone else's cloud. You get contractual guarantees about how that data is handled — but the architecture itself doesn't enforce those guarantees. You're trusting a policy, not a boundary.

With Webiny, the boundary is architectural. Your content lives in your DynamoDB tables, your assets in your S3 buckets, your encryption managed by your KMS keys — all inside your VPC, inside your AWS account. Nobody outside your organization can access it. No third party can train AI models on your content. No SaaS vendor pricing change, acquisition, or policy update can alter that. If you need to demonstrate data residency compliance, the answer is straightforward: your data never left your AWS region.

Security

The IaC templates give you a hardened baseline — VPC isolation, encrypted storage, tightly scoped IAM roles, and multi-AZ redundancy out of the box. But self-hosting also means you can go further. You can layer your own WAF rules, integrate with your existing SIEM, enforce your organization's specific network policies, connect to your identity provider via SAML/OIDC, and apply whatever additional controls your security team requires. You're not asking a vendor to implement exceptions for you — you're just configuring your own infrastructure.

Extensibility

Webiny's backend is a TypeScript framework, not a black box. You can intercept lifecycle events before and after any content operation, enforce business rules programmatically, call external APIs during the publishing flow, build custom approval chains that reflect how your organization actually works, and add entirely new APIs alongside the ones Webiny ships with. The CMS evolves like the rest of your codebase — versioned, reviewed, deployed through CI/CD — not through a vendor's feature roadmap.

Long-term strategic control

SaaS platforms accumulate dependencies quietly. Pricing changes, features get deprecated, API limits get tightened, and eventually the cost of switching becomes prohibitive. With Webiny, the core is open-source, the infrastructure is yours, and the upgrade path is in your hands. If Webiny released a version tomorrow you didn't want, you could stay on the current one indefinitely — because you control the deployment. That's not a hypothetical; for large organizations, this kind of strategic flexibility is a real requirement.