Webiny JS

Webiny is an open-source, enterprise-grade content platform that runs entirely on your own AWS account using Lambda, DynamoDB, S3, and CloudFront — with all infrastructure provisioned automatically via Pulumi IaC. Unlike traditional CMS tools where extension means installing plugins, Webiny is a TypeScript framework with explicit, typed extension points: lifecycle hooks, DI-registered features, GraphQL schema extensions, admin UI slots, and Pulumi-based infrastructure customization.

The platform ships four primary applications — a Headless CMS with multi-localization and versioning, a visual Website Builder with a Next.js SDK for custom rendering, a File Manager with CDN delivery and hierarchical organization, and multi-step Publishing Workflows with audit trails. All four are built on a shared framework layer that enforces consistent patterns and enables each component to be extended or replaced independently.

Webiny is used in production by Amazon, Emirates, Fortune 500 companies, and government agencies handling hundreds of millions of content records, petabytes of assets, and thousands of simultaneous editors. Its native multi-tenancy model — where a single deployment can isolate data, users, permissions, and assets across thousands of tenants in hierarchical structures — makes it the CMS of choice for SaaS vendors who want to embed a content platform into their own product under a white label.

Since v6, Webiny ships an MCP server and AI skill files that give AI coding agents (Claude Code, Cursor, Kiro) deep context about the platform’s architecture and extension APIs. Because the framework is strictly typed with explicit extension contracts, AI-generated code either compiles against the type system or it doesn’t — removing the guesswork that plagues AI-assisted development on loosely-defined platforms.

What You Get

• Headless CMS — Define content models via the admin UI or TypeScript code, with a generated GraphQL API, field-level permissions, multi-localization, versioning, and webhook support built in.
• Website Builder — Drag-and-drop visual page editor with a Next.js SDK so pages render on your own frontend (Vercel, CloudFront, or self-hosted) using custom React page elements you write.
• File Manager — Digital asset management with CDN delivery via CloudFront, hierarchical folder structures, tagging, full-text search, and deep integration into the CMS and Website Builder.
• Publishing Workflows — Multi-step content approval pipelines with draft states, reviewer assignments, scheduled publishing dates, and immutable audit trails for compliance.
• Native Multi-Tenancy — Hard tenant isolation for data, users, assets, and permissions from one deployment. Supports hierarchical tenant trees (Root → Brand → Market, Root → Client → Site) and programmatic tenant provisioning via GraphQL.
• Webiny Framework — TypeScript DI container with typed features, lifecycle hooks, GraphQL schema extension API, React-based admin UI extension slots, and Pulumi infrastructure extension points.
• MCP Server + AI Skills — An MCP server bundled in the repo gives AI coding agents real knowledge of Webiny’s extension APIs and patterns so generated code compiles and follows platform conventions.
• CLI + IaC Deployment — A single yarn webiny deploy command provisions all AWS resources via Pulumi. CLI extensions let you add custom deployment steps, data migrations, and code generators.
• Background Tasks — Type-safe TaskDefinition API for long-running background jobs (bulk imports, data migrations, media processing) with Lambda-aware timeout handling.
• WebSocket Support — Real-time connection registry with DynamoDB and SQL backends for live collaboration features like entry locking across editors.

Common Use Cases

• Multi-brand global content platform — A multinational enterprise deploys one Webiny instance to manage 70+ country-specific sites, each as an isolated tenant with its own content models, editors, and permission sets, sharing infrastructure costs while enforcing strict data boundaries.
• White-label CMS inside a SaaS product — A commerce platform vendor embeds Webiny’s Website Builder to let their customers build and manage pages without the vendor’s engineers writing a page-building system from scratch.
• Compliance-sensitive content operations — A pharmaceutical company self-hosts Webiny to keep research datasets on infrastructure they own and audit, using publishing workflows and immutable audit trails to satisfy regulatory requirements.
• High-scale government digital services — An EU electoral commission runs a Webiny instance behind CloudFront to serve millions of concurrent visitors during election periods, relying on Lambda auto-scaling and DynamoDB to absorb traffic spikes without pre-provisioning.
• Developer-team content tooling with AI — An engineering team uses Webiny’s MCP server to let Claude Code scaffold new content models, lifecycle hooks, and admin UI extensions from natural language instructions, with the TypeScript type system enforcing correctness of the generated code.

Under The Hood

Architecture

Webiny is structured as a 130+ package monorepo where each domain concern — headless CMS, file manager, website builder, background tasks, multi-tenancy, websockets — lives in its own scoped package with explicit interfaces. The core design primitive is a dependency injection container (@webiny/di) combined with a createFeature() factory pattern that registers named, typed capabilities into the container without global state. The entire platform is assembled by composing features together, and extension happens by registering additional features or decorating existing ones — not by modifying core code. Infrastructure is expressed as TypeScript Pulumi programs, and the entire project configuration lives in a single webiny.config.tsx file that uses JSX components for type-safe, IDE-autocompleted configuration of admin extensions, API extensions, infrastructure parameters, and environment variables.

Tech Stack

The backend runs on Node.js 22 Lambda functions triggered by API Gateway, DynamoDB Streams, and SQS — with all business logic written in TypeScript and all persistence going to DynamoDB as the primary data store, S3 for binary assets, and optional OpenSearch for full-text search at scale. The admin frontend is a React 18 single-page application that uses Lexical for rich-text editing, Radix UI for accessible primitives, and a custom context-based theming system. Pulumi manages all AWS resource provisioning, and the CI/CD pipeline runs on GitHub Actions. Testing uses Vitest with structured mocking patterns and a local DynamoDB emulator (dynalite) for integration tests, alongside Cypress for end-to-end coverage.

Code Quality

The codebase has extensive test coverage with nearly 750 Vitest test files spanning unit tests for individual features, integration tests against emulated AWS services, and end-to-end Cypress suites. TypeScript strict mode is enforced across all packages, with explicit interface abstractions separating storage implementations from business logic — for example, the headless CMS defines StorageOperations.Interface independently of the DynamoDB and SQL implementations. Error handling uses a typed WebinyError class rather than plain Error objects, and GraphQL responses follow a consistent envelope pattern. ESLint, Prettier, and pre-commit hooks enforce formatting and import organization, and circular dependency checks run as part of the build.

What Makes It Unique

Webiny’s most distinctive technical decision is expressing infrastructure configuration as JSX in webiny.config.tsx — React component trees that Webiny’s CLI interprets to generate Pulumi programs, giving developers IDE auto-completion, type checking, and composable patterns for infrastructure the same way they use them for UI. The MCP server is another standout: it ships Webiny-specific AI skill files that encode platform architecture and extension API knowledge, so AI agents generate code that targets real extension points with correct types rather than generic guesses. The feature DI pattern enables deep customization — decorating an existing feature’s behavior without subclassing or monkey-patching — and the hierarchical multi-tenancy model is a first-class architectural primitive rather than a bolted-on layer.

Self-Hosting

Webiny uses a split licensing model. The core packages (everything outside enterprise/ subdirectories) are MIT-licensed — you can use them commercially, modify them, redistribute them, and build products on top without restriction. Enterprise-tier features that live under enterprise/ directories carry their own proprietary licenses, and a commercial Business Edition ($79/month starting price) or custom-priced Enterprise Edition is required to unlock capabilities like advanced RBAC, SSO, audit logs, and team management. The MIT core covers the Headless CMS, Website Builder, File Manager, and the framework itself, which is sufficient for many production deployments.

Self-hosting Webiny means running on AWS — there is no GCP, Azure, or on-premises option. The infrastructure footprint includes Lambda functions for API and business logic, DynamoDB as the primary database, S3 for file storage, CloudFront as the CDN, and optionally OpenSearch for full-text search. Pulumi provisions all resources automatically with a single deploy command, but you are responsible for AWS account access, IAM permissions, cost management, and keeping infrastructure code updated as Webiny releases new versions. First deployments take 5–15 minutes of AWS provisioning time; ongoing deployments are incremental. Your team owns backups (DynamoDB point-in-time recovery and S3 versioning), monitoring (CloudWatch), and incident response.

The main trade-off versus Webiny’s managed hosting option (available on Enterprise plans) is operational ownership: self-hosters handle upgrades, DynamoDB capacity planning when not using on-demand pricing, OpenSearch cluster sizing, and any AWS service limits. The managed option adds SLAs, managed upgrades, professional support with guaranteed response times, and high-availability configurations. For teams that are already AWS-native and comfortable with Pulumi-managed infrastructure, the self-hosted path is operationally straightforward; for teams without AWS expertise, the managed path removes significant overhead.