Awesome Astro: The Opinionated Tour

If you search “astro ecosystem” you land on the same page everyone else lands on: one-aalam/awesome-astro. Nine hundred GitHub stars, a couple hundred curated links, organized by category, last touched a few months ago. It is the default mental map of the Astro ecosystem.

It is also half noise.

This is not a criticism of the project. Every awesome-* list on GitHub works by inclusion — a thing gets added when a contributor opens a PR — and very few work by exclusion, where stale or duplicated entries get pruned out. The result, on every awesome-list more than two years old, is the same: a real signal of useful tools buried under years of one-off experiments, dead demos, and packages that have been quietly superseded by features now built into the framework itself.

The awesome-astro list is the right place to start learning the ecosystem. It is the wrong place to build a stack from. This essay is a tour through the list with an opinion attached to every section: what’s worth pinning to package.json, what’s worth bookmarking, and what’s safe to scroll past.

The Categories

The list, today, has roughly seven sections:

Blogs — ~30 posts about Astro
Videos / Screencasts / Twitch — ~17 talks
Twitter Threads — ~7 condensed thought pieces
Repositories / Starter Kits / Components — ~30 themes and starters
Astro Packages / Libraries — ~22 npm packages
Astro Integrations — ~9 integrations
Built with Astro — ~40 example sites in production

I will skip Blogs, Videos, and Twitter Threads entirely. Not because they’re bad — some of them are excellent — but because the half-life of a framework blog post is roughly six months, and almost all of the content there predates Astro’s content collections, the new image pipeline, the View Transitions integration, and the islands architecture as it actually shipped. The official Astro docs and the Astro blog cover the same ground with content that is kept current. If you want to learn Astro in 2026, start there.

The four sections that actually matter for shipping are Repositories, Packages, Integrations, and Built with Astro. The rest of this post is a category-by-category tour through them.

Themes and Starter Kits

About thirty entries. The honest split:

Worth pinning:

AstroWind — the most-cloned production-grade marketing-site template in the ecosystem. Tailwind, dark mode, a real blog, SEO integration. If you need a marketing site by Friday, this is the starting line.
Cactus — opinionated personal-site / blog theme. Clean type, no JavaScript by default, MDX-ready. It is the template most personal-site rewrites should begin from.
Starwind UI — a shadcn-style component kit built native to Astro on Tailwind v4. Currently the most active project in the “real component library for Astro” space.
WebcoreUI — themable Astro component library, newer entrant, worth tracking.

Skip:

Most of the rest. The list contains many Vercel-deployed landing-page templates with names like AstroSaas, AstroMax, Gurido, Minimal Studio, Quick Store, MicroBlog — almost all of them are demo-quality, single-author, last-touched-a-long-time-ago, and have no clear maintenance contract. They are fine to look at for visual inspiration. They are not fine to base a production site on.

A note on Astro Ink / Astro Me / Astro Starter Kit: these belong to the list’s maintainer. They were excellent at the time. They were also written for Astro 1.x and have not kept pace with content collections, the new image pipeline, or the file-routing changes. Read them as historical artifacts.

The rule for themes is the same on every framework: pick the one with the most-recent commit, the most-active issue tracker, and the smallest deviation from the framework’s idioms. AstroWind, Cactus, and Starwind UI all clear that bar. Most of the rest don’t.

Packages and Libraries

This is the section where the noise-to-signal ratio is highest. Twenty-two packages are listed. I would install at most three of them.

The pattern: many of these packages were written before Astro had a feature, the feature shipped, and the package is still listed. Examples:

Listed package	Replaced by	Status
`astro-imagetools`	`astro:assets` (built in)	Skip — use the native API
`astro-google-fonts-optimizer`	Native font handling + Fontsource	Skip
`astro-link`	Plain `<a>` + Tailwind classes	Skip — solves nothing
`astro-stylesheet`	`<link>` tags in layouts	Skip — solves nothing
`astro-social-share`	Five lines of HTML	Skip
`astro-breadcrumbs`	A `for` loop in an `.astro` component	Skip
`astro-pandoc`	Niche to the point of irrelevance	Skip
`astro-spa`	Astro View Transitions (built in)	Skip — actively wrong

That is more than half the list, gone, because Astro shipped the feature natively or because the package wraps something that didn’t need wrapping. This is the dependency-count audit problem in miniature — every dep you install is a long-term liability, and a third-party wrapper around a built-in API has all of the cost and none of the value.

What’s actually worth installing from the Packages section:

astro-icon — by Nate Moore (Astro core). Hands-down the best icon story on Astro. Pulls from Iconify, ships only the icons you use, zero runtime JS.
astro-seo — fills a small but real gap. Generates the standard SEO meta + OpenGraph tags from a props object, instead of you reinventing them in BaseLayout.astro on every site.
accessible-astro-components — accordion, modal, breadcrumbs, pagination, with accessibility baked in. Useful when you need any of these and don’t want to handcraft them.

Three packages. Out of twenty-two. That’s the honest take.

The reason this section is so noisy is structural: Astro deliberately ships a small core and lets the ecosystem fill gaps. Most of the gaps that existed in 2022 have since been filled by Astro itself — content collections, image assets, view transitions, font handling, RSS — and the packages that filled those gaps are now duplicate weight.

Integrations

The list has about nine entries here. This is also where the list is most misleading by what it leaves out.

The integrations actually worth installing — almost none of which are in the awesome-astro list — are the official ones from the Astro team:

npm install \
  @astrojs/mdx \
  @astrojs/react \
  @astrojs/rss \
  @astrojs/sitemap \
  @astrojs/check

These five cover MDX rendering, React island support, RSS feed generation, sitemap.xml generation, and the TypeScript-aware astro check command. Every content site I ship has at least four of these. They live in the official integrations directory, which is the actual canonical inventory — the awesome-astro list is downstream of it.

Also missing from the list, and arguably the most important integration in the entire ecosystem:

@astrojs/starlight — the official documentation theme. If you are building a docs site, this is the single highest-leverage decision you will make. Starlight is the reason a lot of teams are abandoning Nextra and the reason “build docs on Astro” is now the default recommendation for OSS projects.

From the actual awesome-astro Integrations section, what to install:

@storyblok/astro — only if you really need a hosted CMS. Best-in-class integration. Most content sites don’t need a CMS at all, but if yours does, this is the path of least resistance.
@yeskunall/astro-umami — for self-hosted Umami analytics, one component, two lines of frontmatter. Static Signal uses this in production. Note the CSP gotcha: Umami’s tracker calls two different domains, so your connect-src needs both.
@unocss/astro — only if you’ve already made the UnoCSS bet over Tailwind. For most teams, Tailwind v4 via @tailwindcss/vite is the right answer and this integration is a no-op.

That’s it. Three to install from the list, plus the five-to-six official ones the list doesn’t even include. The Integrations section is small, but it punches harder per entry than Packages.

Built with Astro

This is, surprisingly, the most useful section in the list. It is also the section that requires the least judgment from you — every entry is a live site you can View Source on.

The pattern recognition you get from clicking through ten or fifteen of these is worth more than any tutorial:

Trivago Tech Blog and Serverless / CSS-Tricks show what a real production engineering blog looks like on Astro at scale.
Backlight and Rokt demonstrate that Astro is genuinely production-ready for company marketing sites where SEO and performance are commercial.
T3 Tools is a high-traffic Astro site with a strong opinionated visual identity — a useful study in how far you can push the framework before reaching for React.
component-party.dev is a content-heavy comparison site that is essentially what Astro was built for.

The list also surfaces a dozen personal sites and portfolios. Most aren’t worth clicking individually, but skimming them collectively gives you a calibration on the typical shape of an Astro personal site — and incidentally shows that almost all of them ship under 50KB of JavaScript total. That alone is worth the scroll.

This section is the one part of awesome-astro that is better the older the entries get: every site listed here has been in production for at least a year, which is a far more useful signal than “this theme has nice typography in its demo.”

What I Would Actually Ship

Distilling the whole tour into an opinionated package.json for a new Astro content site:

{
  "devDependencies": {
    "astro": "^6.3.5",
    "@astrojs/mdx": "^5.0.6",
    "@astrojs/react": "^5.0.5",
    "@astrojs/rss": "^4.0.18",
    "@astrojs/sitemap": "^3.7.2",
    "@astrojs/check": "^0.10.0",
    "@tailwindcss/vite": "^4.3.0",
    "@tailwindcss/typography": "^0.5.19",
    "tailwindcss": "^4",
    "shiki": "^4.0.2",
    "pagefind": "^1.5.2",
    "astro-icon": "^1.1.0",
    "astro-seo": "^0.8.0"
  }
}

Roughly thirteen direct devDeps. Two of them are from the awesome-astro list. Five are official @astrojs/* packages. The rest are either Tailwind, the search engine, Shiki, or React (only if you have islands).

A node_modules install for that list comes in under 400 packages. The whole site builds in under three seconds. That is the actual baseline. Any package you add beyond this should clear a real bar: what does this give me that I couldn’t do in fifteen lines of an Astro component?

For most things on the awesome-astro list, the honest answer is: nothing.

How to Read Any “Awesome” List in 2026

The awesome-astro list is doing exactly what it was designed to do — collect community contributions in one place. The problem is structural, not specific to this list or this maintainer. Every awesome-* list eventually drifts the same way: inclusion is easy, exclusion is hard, the framework grows in features faster than the list grows in curation, and a year later half of the entries are stale.

A few rules I now apply to any awesome-* list before treating it as a shopping cart:

Check the date on the repo’s last meaningful commit, not just the last “update README” commit. A list that only gets PRs adding new entries is not being curated; it is being appended to.

Cross-reference the framework’s own official directory. Astro has astro.build/integrations. Every framework I trust has something equivalent. The awesome-list is downstream of that, never upstream.

For every package in the list, ask: would I have noticed this missing if the list didn’t mention it? If the answer is no, you don’t need it.

Treat the “Built with X” section as the most valuable part of the list. Live production sites are the only entries that don’t bit-rot in place.

The awesome-astro list is a useful map of the Astro ecosystem’s history. The actual Astro ecosystem to build with in 2026 is much smaller, and most of it is documented at docs.astro.build. Read the list to understand where things came from. Read the docs to decide what to install.