The history of Astro: from a 2021 experiment to Cloudflare

You open an article to read it. Before you get to the first paragraph, the page may ask your browser to load code for a search box, a newsletter form, and a video player you haven’t used. Astro began with a question: how much of that work does the browser really need to do?

Its public introduction on June 8, 2021, proposed a framework that rendered HTML first and added browser JavaScript where developers explicitly needed it. The announcement’s title stated the ambition plainly: “Ship Less JavaScript.” Astro’s original announcement

That question stayed relevant as Astro grew. The framework added tools for larger content libraries, personalized features, server functions, and publishing workflows while keeping HTML at the center of the page.

If you use WordPress, this history helps explain where Astro fits: it can run the public website while WordPress manages your content. Connecting the two still takes planning, particularly for previews, plugins, and publishing.

The milestones at a glance

The dates below are useful starting points. The sections that follow explain what changed and link to the original announcements.

Before Astro: the idea behind islands

The idea behind Astro was already taking shape before the framework launched. Its documentation credits Etsy frontend architect Katie Sylor-Miller with coining “component island” in 2019, and Preact creator Jason Miller with expanding and documenting the approach in August 2020. Astro’s account of islands architecture

The idea is easiest to understand through a page. Consider an article with a header, body text, an interactive calculator, and a footer. The calculator needs code in the browser to respond to input. The article’s paragraphs do not need that same runtime simply to remain readable.

With islands, the calculator can run inside a page whose surrounding text is already HTML. Developers call the step that makes the component interactive “hydration.” The practical result is that different parts of the page can do different amounts of work.

Astro helped turn this pattern into a practical framework workflow. Developers could compose a page from components and decide which ones needed hydration, instead of treating the whole page as one client application.

2021: a public launch with a specific purpose

Fred Schott and Nate Moore authored the June 2021 introduction. The project came from the open-source developers behind Snowpack and Skypack, with community contributions. Its first public release was a beta, well before the eventual 1.0 milestone. The launch announcement

The early pitch let developers keep familiar tools while changing what reached the browser. Developers could use React, Vue, Svelte, Preact, or ordinary HTML and JavaScript. Astro would render the page to HTML and omit component JavaScript unless interactivity was requested.

Teams could use component tools they already knew. Using a component did not automatically mean sending its framework runtime to every visitor.

The launch also acknowledged the financial question early: keeping the framework free required a sustainable way to support its development. Technical design and open-source funding would develop alongside each other throughout Astro’s history.

Late 2021: Astro changes its foundations

Astro’s origins in the Snowpack ecosystem did not lock it to Snowpack. An October 6 preview announced a move to Vite, together with a new compiler written in Go and delivered through WebAssembly. Astro 0.21 preview

The finished 0.21 release followed on November 19, 2021. It brought the Vite build engine, Go compiler, improvements to package compatibility, and a revised development experience. The release credited substantial work from Nate Moore, Matthew Phillips, and Drew Powers. Astro 0.21 release

The internal tools changed, while the focus on content websites continued. That is useful context when choosing a framework: its underlying technology can evolve without every project needing a different purpose.

August 2022: Astro 1.0 establishes a production baseline

Astro 1.0 arrived on August 9, 2022. Its announcement framed the release as a commitment to API stability and production readiness. MDX support, image tooling, and stable server-rendered output were among its features. Astro 1.0 announcement

This is an easy detail to miss if you remember Astro only as a static site builder: production server output was already supported by 1.0.

Static generation produces HTML during a build. Server rendering produces it when a request arrives. Both can deliver readable HTML to the visitor; they differ in when the work happens and what information is available at that moment.

Teams could prebuild the pages that suited that approach and use a server where fresh information or visitor actions called for one.

January 2023: content becomes a structured part of the framework

Astro 2.0 launched on January 24, 2023, with content collections as its defining addition. Collections brought schema validation and generated TypeScript types to Markdown and MDX content. The release also introduced hybrid rendering, allowing static and server-rendered routes within one project. Astro 2.0 announcement

A content schema makes editorial assumptions explicit. If a template expects a title, publication date, and description, a collection can validate those fields rather than letting a missing value become a broken page. Astro’s accompanying explanation demonstrated this through typed Markdown frontmatter. Introducing content collections

For an editorial team, that can mean finding a missing description or required image before a page goes live. The value grows as more articles share the same fields and templates.

June 2023: Starlight gives documentation its own home

Starlight’s first release followed on June 5, 2023. The project’s first-anniversary account dates its launch and describes the initial package: search, generated navigation, internationalization, accessibility features, typography, and support for content formats including MDX. Starlight’s first anniversary

Starlight brought those pieces together for people writing documentation. A team could start with working navigation and search, then spend more of its effort explaining the product.

Starlight also represents work beyond the core runtime: writing, translation, accessibility, design, and maintenance. Those contributions are part of the framework’s history, even when they attract less attention than a new rendering feature.

August and December 2023: navigation, images, and daily development

Astro 3.0 shipped on August 30, 2023. It introduced support for view transitions, stabilized its newer image optimization tooling, and improved rendering and development behavior. Astro 3.0 announcement

View transitions expanded what navigation could feel like in an Astro website. Pages could transition with animated continuity, including persistent elements. Using Astro’s client navigation features still involves browser JavaScript; the point was to make richer navigation available when a project wanted it.

Astro 4.0 followed on December 5. Its highlights included the development toolbar, internationalization routing, experimental content caching, and further view-transition APIs. Astro’s own documentation also moved to Starlight. Astro 4.0 announcement

These releases addressed everyday website work: processing images, supporting languages, inspecting changes, and keeping builds manageable. Those details help turn a promising framework into something a team can maintain.

2024: the search for a sustainable business

Astro’s history includes a commercial experiment that did not work out as intended.

On March 12, 2024, the team introduced Astro DB as an integrated database offering. The launch combined a developer-facing database experience with hosted SQL infrastructure, drawing on Drizzle, libSQL, and Turso. Astro DB announcement

The hosted platform was called Astro Studio. On September 13, the team announced it would wind down Studio and open Astro DB to external libSQL databases. Schott’s explanation was direct: the hosted product had not found product-market fit or a convincing path to becoming a durable business. The Studio wind-down announcement

The distinction between the two names matters. Winding down Astro Studio did not mean withdrawing Astro itself, or discarding all of the database work. The framework integration continued in a more open form.

Our reading is that this episode helps explain the later Cloudflare agreement. A useful framework still needs a sustainable way to pay for the people maintaining it.

August 2024: Actions make server interactions easier

Astro 4.15, released on August 29, 2024, stabilized Astro Actions. Actions let developers define server functions with validated inputs and typed results, callable from components or HTML forms. Astro 4.15 announcement

A newsletter form is a useful example. Its page may consist almost entirely of content, while submitting an email address requires server work. Actions provide a framework-supported way to handle that interaction.

A mostly static website could add the server work needed for a form or another action. The hosting setup still had to support that work; publishing static files alone would not provide the backend.

December 2024: Astro 5 connects more content and isolates dynamic work

Astro 5.0 arrived on December 3, 2024, with two substantial developments: the Content Layer and Server Islands. Astro 5.0 announcement

The Content Layer expanded collections beyond local files. Loaders could bring content from external sources into the same typed API, giving templates a consistent way to use it.

Server Islands addressed a different boundary. A page could defer a dynamic server-rendered component while allowing the surrounding content to use its own caching strategy. An account avatar or personalized fragment could load independently of the main page.

The two kinds of islands do different jobs. Client islands handle interaction in the browser. Server Islands let part of the page wait for its own server work without holding up the rest in the same way.

For websites connected to a CMS, these changes offered more flexibility. The main page and its personalized sections could load and cache independently.

2025: the supporting features mature

Much of Astro’s progress in 2025 arrived through smaller releases. Astro 5.7, released on April 15, stabilized its Sessions API and introduced an experimental Fonts API. Sessions made it possible to maintain server-side data associated with a visitor across requests. Astro 5.7 announcement

Astro 5.10 followed on June 19 with stable responsive images and experimental live content collections. Live collections introduced a way to fetch through the collection system at request time, expanding beyond build-time loading. Astro 5.10 announcement

For publishing teams, the distinction is when a change reaches the reader. Some sites can rebuild after an update; others need to retrieve information during the request. Either setup needs a reliable connection to its content.

Keep the release dates in mind when reading older advice. An experimental feature can become stable later, so a historical limitation may no longer describe the version you are considering.

January 2026: the company behind Astro joins Cloudflare

On January 16, 2026, The Astro Technology Company announced it was joining Cloudflare. Its full-time employees became Cloudflare employees and continued working on Astro. The announcement committed to preserving the framework’s MIT license, open governance, and support for deployment targets beyond Cloudflare. The Cloudflare announcement

The stated rationale connected directly to the earlier business experiments. Schott described the difficulty of building paid services around the framework and the distraction that created. Cloudflare’s backing would allow the team to concentrate on Astro itself.

A separate funding explanation emphasized the continued role of sponsors and community maintainers. It reported that more than half of Astro’s core maintainers were community contributors. Supporting the future of Astro

Cloudflare became the home of the company team; the announced model still included the wider contributor community.

If you are considering Astro, check the practical details that matter to your project: its license, hosting options, maintenance, and the features your site needs. The company announcement provides context, but your requirements still decide the fit.

March 2026: Astro 6 brings development closer to production

Astro 6.0 shipped on March 10, 2026. It stabilized Live Content Collections, the Fonts API, and Content Security Policy support. It also substantially reworked the development server around Vite’s Environment API. Astro 6.0 announcement

The runtime work addressed an awkward source of bugs: code can behave differently in a local Node.js environment than it does on the platform hosting the finished site. Astro 6’s redesigned approach enabled development to run against the production runtime, including improved Cloudflare support.

The release also introduced experimental work on a Rust compiler, queued rendering, and route caching. Those experiments would become part of the next major release’s story.

For the person maintaining the site, the benefit is straightforward: there is a better chance of catching a hosting-related problem before customers see it.

June 2026: Astro 7 concentrates on speed and request control

Astro 7.0 arrived on June 22, 2026. It adopted a Rust compiler, Rust-powered Markdown and MDX processing, queued rendering, and Vite 8. The release also introduced Advanced Routing and stabilized route caching; CDN cache providers were still experimental. Astro 7.0 announcement

Building pages and serving them are different jobs. Build performance affects the work needed to produce the site. Route caching controls when a running site can reuse a response and when it needs a fresh one.

For a publishing workflow, avoiding unnecessary work can matter as much as making each operation faster. That is especially relevant when a content change affects a small portion of a larger site.

The CMS connection still needs to tell the site which content has changed and which cached pages need refreshing. Those rules are part of the project, even when the framework supplies the tools.

August and September 2026: incremental builds remain an evolving feature

Astro 7.2, released on August 6, introduced experimental incremental static builds. Opted-in routes could provide cache keys so Astro could reuse prerendered pages when the relevant code and data had not changed. Astro 7.2 announcement

Incremental builds decide which files need rebuilding. Runtime route caching decides which responses a running site can reuse. They reduce repeated work at different stages.

At this article’s September 17, 2026 research cutoff, the latest minor release verified here is Astro 7.3, announced September 3. It added refinements to preview servers, runtime logging, and custom Cloudflare request handling. Astro 7.3 announcement

Treat experimental features as choices to evaluate for the project, with their current limitations understood. A recent announcement alone is not a reason to make one essential to your publishing workflow.

What this history means for your WordPress site

Astro’s official WordPress guide describes using WordPress as a headless CMS: WordPress provides content through its REST API, or an optional GraphQL integration, while Astro renders the public website. Astro’s WordPress guide.

That is the arrangement we build around at WP Forged. Your team can keep a familiar place to write while the public templates are rebuilt separately.

The history helps explain why Astro is worth considering for that job. Its original focus on HTML has expanded to include structured content, server features, and more ways to handle publication. Our view is that those additions make the framework more useful when chosen around a site’s actual needs.

The connection still takes work. Previews, custom fields, images, forms, redirects, and publishing updates need to be planned and tested. Your editor should be able to make the next change as well as admire the new homepage.

Our WordPress and Astro overview explains that arrangement, and the compatibility guide covers the features to investigate. If you’re thinking about it for your own site, send us the URL and what you’d like to improve. You don’t need to know which rendering option to choose before starting the conversation.