Project Overview & Goals

What the Serverless CMS is

The Serverless CMS is a multi-tenant content management platform for building and operating websites. From a single deployment, administrators can provision any number of independent sites, and authors can build pages visually from reusable components. Published pages are rendered to static HTML and served from a global CDN, giving visitors fast, cacheable pages with no server-side rendering at request time.

It runs entirely on serverless AWS infrastructure — there are no servers, containers or clusters to manage. Every moving part is a managed AWS service (DynamoDB, S3, Lambda, API Gateway, Cognito, CloudFront, SES/SNS), so the platform scales on demand and bills per request.

The whole system is described declaratively and deployed with the Serverless Maven Plugin: the AWS resource graph is generated from src/main/serverless/config.json rather than hand-written infrastructure code.

What it achieves

  • Operate many sites from one platform. Each site gets its own domain, content, templates, theme, users/permissions and published output, while sharing one control plane and one deployment.
  • Visual, component-based authoring. Pages are assembled from a library of reusable components (text, images, navigation, tables, tabs, teasers, and custom-built components) arranged into template-driven layouts.
  • Separation of authoring and delivery. Editing happens against a DynamoDB-backed content store through an authenticated API; visitors are served pre-rendered static HTML from S3 + CloudFront. A slow editor action never slows down a public page view.
  • Safe, governed publishing. Draft/published states, per-page version history, page locking, publish requests/approvals, bulk publishing and whole-site rebuilds give teams control over what goes live and when.
  • Full site lifecycle automation. Creating a site automatically provisions its DNS records, TLS certificate, CloudFront distribution and storage; deleting a site tears them back down.
  • Resilience and portability. Sites and platform settings can be backed up to a zip archive and restored, supporting migration and disaster recovery.
  • Zero-maintenance scaling. Pay-per-request DynamoDB, on-demand Lambda and CDN caching mean the platform absorbs traffic spikes without capacity planning.

Who it is for

Audience
What they do
Platform administrators
Provision sites, manage users, groups and permissions, curate the component library and platform-wide design variables, run backups.
Site editors / authors
Build templates and pages, manage media, apply themes, configure SEO, and publish.
Website visitors
Consume fast, static, SEO-friendly pages delivered from the CDN.
Developers / integrators
Build custom components, consume the public delivery API, and extend the platform.

Core capabilities

  • Sites — multi-tenant provisioning with automatic domain, certificate, CDN and storage setup.
  • Templates & pages — reusable page templates with editable zones; hierarchical pages addressed by slug.
  • Components — a versioned library of HTML/CSS/JS component bundles with configurable dialogs and design variables.
  • Theming & design variables — per-site themes, breakpoints and platform-level design tokens.
  • Publishing workflow — drafts, version history, locking, publish requests and approvals, bulk publish, and full-site rebuild.
  • Media & fonts — per-site asset store with uploads and custom web fonts.
  • Users & access control — Cognito-backed identity with global groups and per-site roles resolved into fine-grained permissions.
  • SEO & discoverability — per-page SEO metadata, JSON-LD, sitemaps, robots.txt, and AI-crawler access controls plus crawler analytics.
  • Backup & restore — stepwise, any-size site and platform backups to zip.

Design principles

  1. Serverless-first. Prefer managed, pay-per-request services over anything that must be provisioned, patched or scaled by hand.
  2. Declarative infrastructure. The deployed system is a function of version-controlled configuration, not manual console changes.
  3. Author/deliver split. Keep the authoring control plane isolated from the public delivery plane for performance and blast-radius reasons.
  4. Static delivery. Do the rendering work once at publish time, then serve cached static assets.
  5. Least privilege. Each function is granted only the specific resource links and permissions it needs (see Security).

Continue to System architecture & flows »