The Labs Website is built on a modern "Headless" architecture, separating the content management system (backend) from the presentation layer (frontend).

This separation allows us to use the best tools for each job: PayloadCMS provides a robust, developer-friendly content management experience, while Astro delivers an ultra-fast, static frontend for our visitors. This architecture allows us to move fast, keep costs low, and deliver an exceptional user experience.

Architecture Overview

1. The Frontend: Astro

We use Astro 5 as our static site generator. Astro is unique because it defaults to shipping zero JavaScript to the client. It pre-renders pages into static HTML at build time, ensuring:

• Blazing Fast Performance: Pages load instantly because there's no heavy framework initialization.
• SEO Optimization: Search engines can easily crawl the pre-rendered static HTML.
• Type Safety: We use TypeScript throughout the frontend to ensure robust code.

The frontend consumes content from the PayloadCMS API at build time. It generates a sitemap automatically with prioritized routes (e.g., Blog Posts vs. Landing Pages) and optimizes images using Sharp and Tailwind CSS v4 for styling.

2. The Backend: PayloadCMS

Our backend is powered by PayloadCMS 3.0 (running on Next.js 16 and React 19).

• Database: PostgreSQL for structured content storage.
• Storage: AWS S3 for media assets (images, documents).
• Editor: The Lexical editor provides a rich writing experience.
• API: It automatically generates a GraphQL and REST API based on our defined collections (Pages, Posts, Media, etc.).

Why This Architecture?

• Decoupled & Secure: The public frontend is just static files. Even if the backend goes down, the website stays up. The CMS is hidden behind a firewall or restricted route, reducing the attack surface.
• Best-in-Class Performance: By generating static HTML, we achieve Core Web Vitals scores that are hard to beat with traditional dynamic sites.
• Developer Experience: Both frontend and backend are written in TypeScript, sharing types and interfaces. This makes refactoring easier and reduces bugs.
• Cost Effective: Serving static files is significantly cheaper than hosting a server-side rendered application that requires constant compute power.

Automated Rebuilds with GitHub Actions

One challenge with Static Site Generators (SSG) is updating content. Since pages are built ahead of time, how do we show new blog posts without manually deploying code?

We solved this using Webhooks and GitHub Actions.

1. The Trigger: We implemented a custom hook in PayloadCMS (triggerFrontendRebuild.ts). Whenever a "Post" or "Page" is published or updated, this hook sends a request to the GitHub Actions API.
2. The Workflow: This triggers a specific workflow (rebuild-frontend.yml) in our repository.
3. The Build: GitHub Actions spins up a runner, checks out the latest code, pulls the fresh content from the Payload API, and rebuilds the Astro frontend.
4. The Deployment: The new static site is packaged into a Docker container and pushed to our container registry, ready to be pulled by our production server (or handled by a tool like Watchtower).

This gives us the "set it and forget it" ease of a traditional CMS like WordPress, but with the performance benefits of a static site.

Future Improvements

While our current setup is robust, there is always room for growth:

• Hybrid Rendering / ISR: As the site grows, rebuilding the entire site for every spelling correction might become too slow. We could explore Astro's Hybrid rendering or Incremental Static Regeneration (ISR) to only rebuild changed pages.
• Enhanced Preview Mode: We currently have a Live Preview in Payload. Improving the integration between Payload's preview frame and Astro's dev server could provide an even smoother "What You See Is What You Get" editing experience.
• Edge Caching: Deploying the static assets to a global CDN (Content Delivery Network) would further reduce latency for international visitors.