TL;DR
AstroWind is not a SaaS boilerplate — it's the best free Astro starter for marketing and content sites. If you're building a landing page, documentation site, blog, or content platform (not an app), AstroWind is exceptional. Free, performant (Lighthouse 100), and production-ready. Wrong tool for app development, right tool for content-driven products.
What AstroWind Is
Source: github.com/onwidget/astrowind
What it includes:
- Astro 4 + TypeScript
- Tailwind CSS
- Landing page components (hero, features, pricing, testimonials, FAQ)
- Blog with MDX support
- Dark/light mode
- SEO-optimized (meta, OG images, sitemap, robots)
- Lighthouse score ~100
- No JavaScript runtime (static by default)
The Performance Case
AstroWind's core value proposition: near-perfect Lighthouse scores by default.
Lighthouse Performance: 100
Accessibility: 100
Best Practices: 100
SEO: 100
This happens because Astro ships zero JavaScript by default — every component renders to HTML at build time. Only components explicitly marked client:load or client:visible ship JavaScript.
---
// pages/index.astro
import Layout from '~/layouts/PageLayout.astro';
import Hero from '~/components/widgets/Hero.astro';
import Features from '~/components/widgets/Features.astro';
import Pricing from '~/components/widgets/Pricing.astro';
import FAQ from '~/components/widgets/FAQ.astro';
import Stats from '~/components/widgets/Stats.astro';
const metadata = {
title: 'Your SaaS — Description',
ignoreTitleTemplate: true,
};
---
<Layout metadata={metadata}>
<Hero
tagline="The tagline"
title="Compelling headline that converts"
subtitle="Supporting copy that explains the value proposition clearly."
actions={[
{ text: 'Get Started Free', href: '/signup', variant: 'primary' },
{ text: 'See Demo', href: '/demo' },
]}
image={{ src: '~/assets/images/hero.png', alt: 'Product screenshot' }}
/>
<Features
title="Why choose us"
items={[
{ title: 'Feature 1', description: '...', icon: 'tabler:bolt' },
{ title: 'Feature 2', description: '...', icon: 'tabler:shield' },
// ...
]}
/>
<Pricing
title="Simple pricing"
prices={[
{ title: 'Starter', price: 0, items: ['Feature A', 'Feature B'] },
{ title: 'Pro', price: 49, items: ['Everything', 'More features'] },
]}
/>
</Layout>
Blog with MDX
AstroWind's blog is production-ready out of the box:
---
// src/content/blog/my-post.mdx
import { Image } from 'astro:assets';
import hero from '~/assets/images/post-hero.jpg';
export const frontmatter = {
title: 'Post Title',
excerpt: 'Post excerpt for meta description and cards',
publishDate: '2026-03-08',
author: 'Author Name',
image: { src: hero, alt: 'Hero alt text' },
tags: ['tag1', 'tag2'],
};
---
# Post Title
Content goes here. Images, code blocks, and MDX components work.
<Image src={hero} alt="Hero" width={800} />
When AstroWind Makes Sense
AstroWind is the right choice when:
- Marketing site for SaaS app — Your app runs elsewhere (Next.js, Rails), and AstroWind is your public-facing site
- Documentation platform — Static generation means fast, indexed docs
- Blog/content-first products — No backend needed
- Landing page MVP — Ship a beautiful landing page quickly while building the app
Common architecture:
astrowind.com (marketing + blog) ← AstroWind (this)
app.astrowind.com (dashboard) ← Next.js / your app
What AstroWind Is NOT
AstroWind doesn't include:
- Authentication
- Database
- Billing/payments
- User management
- Server-side logic beyond simple API routes
- Real-time features
If you need those things, you need a different tool.
AstroWind vs Next.js for Marketing Sites
| Metric | AstroWind (Astro) | Next.js Boilerplate |
|---|---|---|
| Lighthouse score | ~100 | 80-90 |
| First paint | <1s (typical) | 2-3s (typical) |
| JavaScript bundle | ~0-10KB | 100-300KB |
| Setup time | Hours | Days |
| Server-side features | Limited | Full |
| SEO | Excellent | Good |
For pure marketing/content use cases, Astro wins on performance every time.
Getting Started
npm create astro@latest my-site -- --template onwidget/astrowind
cd my-site
npm install
npm run dev
The template is customizable through src/config.yaml for most settings:
# src/config.yaml
site:
name: YourSaaS
site: 'https://yoursite.com'
base: '/'
metadata:
title:
default: YourSaaS
template: '%s — YourSaaS'
description: "Your meta description"
robots: { index: true, follow: true }
openGraph:
site_name: YourSaaS
type: website
Who Should Use AstroWind
Good fit:
- Founders building a marketing site for their SaaS
- Content platforms where SEO performance is critical
- Developers who want a free, polished landing page quickly
- Products where the "app" is separate from the marketing site
Bad fit:
- Applications with auth/billing/database needs
- Teams who want one unified codebase (AstroWind is frontend-only)
- Real-time or dynamic content-heavy products
Final Verdict
Rating: 4.5/5 for its intended use case
AstroWind is genuinely exceptional at precisely what it does. If you're building a marketing or content site, it's the best free starting point available. The Lighthouse scores, component library, and blog system are all production-quality. Just don't confuse it for a SaaS boilerplate — it's a different tool for a different job.
Customizing AstroWind Beyond the Config
Most customization starts in src/config.yaml but the real work happens at the component level. AstroWind's components are in src/components/widgets/ — each is a standalone Astro component you can modify directly:
Hero.astro— the top-of-page section with CTA buttonsFeatures.astro— feature grid (icon + title + description)Pricing.astro— pricing table with plan comparisonStats.astro— metrics display (users, revenue, ratings)Testimonials.astro— customer quotes with avatars
The components are readable and consistently use Tailwind classes throughout. Adding a new homepage section means creating a new .astro component and importing it in pages/index.astro — no routing configuration needed. This is one of AstroWind's genuine advantages over React-based starters: page structure is immediately visible and editable.
For the blog, posts live in src/content/blog/ as .mdx files with frontmatter. Adding a new author, tag taxonomy, or post template requires editing the content collection schema in src/content/config.ts — straightforward for anyone familiar with Zod schemas.
AstroWind + App Architecture Pattern
The most common pattern in 2026: AstroWind as the public-facing site, a separate app for authenticated users.
yourproduct.com → AstroWind (this repo)
/ → Landing page
/blog/* → MDX blog posts
/pricing → Pricing page
/docs → Documentation
app.yourproduct.com → Next.js / SvelteKit / Rails
/dashboard → User dashboard
/settings → Account settings
/api/* → API endpoints
This separation has real advantages. The marketing site deploys independently of the app — a content change doesn't trigger app CI/CD. AstroWind's static output caches aggressively on CDN, keeping page load times under 1 second globally without configuration. The app can use whatever framework fits your needs without being constrained by the marketing site's tech stack.
The challenge: two repositories to maintain, two deployment pipelines, and consistent design between the two. Use a shared Tailwind config (published as an npm package) and shared design tokens to keep the visual identity aligned without coupling the codebases.
AstroWind vs Alternatives for Marketing Sites
| AstroWind | Nextra | Hugo | |
|---|---|---|---|
| Framework | Astro | Next.js | Go templates |
| Lighthouse | ~100 | 85-95 | ~100 |
| MDX support | ✅ | ✅ | ❌ |
| React components | ✅ (islands) | ✅ | ❌ |
| Landing page components | ✅ (built-in) | ❌ | Varies by theme |
| Learning curve | Low | Low (if Next.js familiar) | Medium |
| Free | ✅ | ✅ | ✅ |
AstroWind beats Nextra for marketing sites because it includes landing page components out of the box. Nextra excels for documentation sites. Hugo is faster at build time for massive content sites but lacks the React/JSX ecosystem.
For a SaaS product launching with a marketing site, AstroWind is the easiest path to a fast, polished landing page without writing components from scratch.
Key Takeaways
- AstroWind delivers Lighthouse 100 by default — zero JavaScript bundle for static pages, with React islands opt-in where needed
- Free to use and clone; no license cost for commercial products
- Ideal for marketing sites, content platforms, and documentation — not a SaaS application boilerplate
- The two-repo pattern (AstroWind marketing + separate app) works well in production; plan for shared design tokens
- Customization is component-based and readable; adding a new homepage section takes 30-60 minutes
- For documentation-first products, compare with Nextra; for app-heavy products, AstroWind handles only the public-facing layer and pairs with whatever app framework you choose
- The GitHub repository receives consistent updates tracking Astro's release cycle — important for a free project you'll depend on in production
- AstroWind is MIT licensed, meaning no restrictions on commercial use; you can build a commercial SaaS marketing site on top of it without attribution requirements or license fees
The SEO Case for Astro Over Next.js Marketing Sites
Search engine rankings depend heavily on Core Web Vitals, and Core Web Vitals depend heavily on JavaScript bundle size and Largest Contentful Paint timing. AstroWind's zero-JavaScript default means your marketing site pages have no blocking JavaScript — the entire page HTML is delivered in the first request, with images and fonts being the primary LCP candidates.
For competitive SaaS categories where SEO drives meaningful acquisition (productivity tools, developer tools, project management), a 40-point Lighthouse gap between your marketing site and a competitor's Next.js site has a computable revenue impact. An improvement from a 90 to 100 Lighthouse Performance score correlates with faster page loads that reduce bounce rates, which Google treats as a positive signal, which improves rankings over time.
This case is weakest for B2B SaaS sold through direct outreach, conferences, and partnerships rather than SEO. A 100 Lighthouse score doesn't help you close enterprise deals that start with a cold email. Evaluate whether SEO is a material acquisition channel for your product before making architectural decisions based on it.
The other SEO advantage of AstroWind is the static site generation model. Static HTML is cached at CDN edge nodes globally — your marketing site page loads in under 200 milliseconds for users worldwide. A Next.js app with server-side rendering adds server processing time to every marketing page request, even for pages that don't need dynamic content. For marketing sites that are genuinely static (pricing, features, landing page), SSG is the right choice and AstroWind's default.
Maintaining Design Consistency Across Two Codebases
The two-repo pattern (AstroWind marketing + Next.js app) requires intentional design system management to keep the user experience consistent. Users who arrive on your Astro landing page and then sign up and enter your Next.js app will notice if the typography, color palette, button styles, and spacing feel different.
The standard solution is a shared design token package published as an internal npm package (or a workspace package in a monorepo). Both the Astro site and the Next.js app import the design tokens and apply them independently to their respective component libraries. Token changes publish to both repos on the next deploy without requiring synchronized updates.
For smaller teams without the overhead of a shared package, using the same Tailwind configuration file in both repos and manually keeping them synchronized works for early-stage products. Set a calendar reminder to compare the two configs monthly. The drift is slow but compounds — you'll notice inconsistency in user testing before it becomes obvious to users.
Find the right boilerplate for your next SaaS on StarterPick.
See our guide to best SaaS boilerplates for the app layer that pairs with AstroWind.
Browse best Astro boilerplates for other Astro-based options for content and marketing sites.
Read why SaaS boilerplates choose Next.js for the app-layer context when combining AstroWind with a Next.js application.