# Astro

> Builds a website into finished files at publish time, so no code has to load in the browser just to display the page.

- Vendor: Astro-Projekt (MIT), getragen von Cloudflare
- Canonical URL: https://www.convios.com/en/toolbox/astro
- Language version: https://www.convios.com/de/werkzeugkasten/astro
- Area: Content & web · Cluster: website stack
- Role: Building block · Origin: Established
- As of: 2026-07-30 · Reviewed: 2026-07-30 · Author: Dr. Oliver Gausmann, Convios GmbH
- Toolbox: https://www.convios.com/en/toolbox — Markdown: https://www.convios.com/en/toolbox.md

## Verdict

Prevents falling behind: A fast, machine-readable website is an expectation, not a distinction. The edge sits in the content and its linking, not in the build tool. What a static build reliably removes is failure modes: no client-side loading, no bought-in pre-rendering, no runtime dependency.

## Suitability by company size

- Solo: suitable with caveats — Requires development skills. Anyone who just needs a page and does not build is faster with a site builder.
- Mid-market: suitable — Fits as soon as a developer or agency looks after the site. Delivery then costs almost nothing, because only files are served.
- Enterprise: suitable — Works because the result is auditable: the delivered page can be read in full and checked automatically instead of assembling in the browser.

## Vendor staying power

Established: The vendor question works differently here, but it does arise. Astro is MIT-licensed and developed in the open. Full-time development, however, does not sit with a community: since 16 January 2026 it sits with Cloudflare, which acquired The Astro Technology Company together with all of its full-time staff. Before that, the company was funded by a 7m USD venture round raised in January 2022 and led by Lightspeed Venture Partners. Two things follow for users. Vendor failure does not hit you, because the source stays usable and forkable. What remains is that maintenance depends on a single company, and that company is also a hosting provider.

- Licence: MIT (source: https://astro.build/press/, as of 2026-07-30)
- Development: open repository, contributors and sponsors named publicly (source: https://astro.build/press/, as of 2026-07-30)
- Who carries the project: Cloudflare. The Astro Technology Company was acquired on 16 January 2026, and its full-time staff have worked on Astro as Cloudflare employees since then. (source: https://www.cloudflare.com/press/press-releases/2026/cloudflare-acquires-astro-to-accelerate-the-future-of-high-performance-web-development/, as of 2026-07-30)
- Commitments made at the acquisition: According to the project, Astro stays open source and MIT-licensed, its open governance and current roadmap remain in place, and a wide set of deployment targets stays supported, not just Cloudflare. This is a stated intention, not a contract. (source: https://astro.build/blog/joining-cloudflare/, as of 2026-07-30)
- Venture funding before the acquisition: 7m USD seed round announced on 12 January 2022, led by Lightspeed Venture Partners, with Haystack, Gradient and Uncorrelated Ventures (source: https://astro.build/blog/the-astro-technology-company/, as of 2026-07-30)
- Sponsorship money: Open Collective shows 873,559 USD raised in total and an estimated annual budget of 455,274 USD. The largest named backer is Netlify with 312,500 USD. (source: https://opencollective.com/astrodotbuild, as of 2026-07-30)

## Cost of leaving

Low: The output is ordinary files. They run on any web server, even without the tool that produced them.

## Regulation and data

| Point | Finding | Evidence | As of |
|---|---|---|---|
| Data processing agreement | not applicable — The tool runs at build time on your own machine or in your own pipeline. There is no vendor processing data. The hosting provider is what needs review. | evidenced | 2026-07-30 |
| Storage location | determined by the hosting provider — The tool produces files; it stores nothing. | evidenced | 2026-07-30 |
| Subprocessors | none | evidenced | 2026-07-30 |
| Third-country transfer | not applicable | evidenced | 2026-07-30 |
| Training on customer data | no data transfer — There is no data transfer to a vendor because the tool runs locally at build time. The training question therefore does not arise for this tool. | evidenced | 2026-07-30 |
| Retention and deletion | your own responsibility | evidenced | 2026-07-30 |
| Certifications | none, because this is not a service — A library carries no operating certificates. Evidence comes from the hosting provider. | partially evidenced | 2026-07-30 |
| EU AI Act, Article 50 | not affected — Not an AI system within the meaning of the regulation. | evidenced | 2026-07-30 |
| Audit logging | a matter for the hosting provider | evidenced | 2026-07-30 |

## Cost

- Entry: Free under the MIT licence. Costs arise only for hosting and for the working time that building and maintenance consume. (as of 2026-07-30)
- Where it gets expensive: Dependence on people who can build. A statically built site is cheap to run and expensive to change if nobody in-house can touch it.

## Three routes compared

### Website as a hosted builder

Click instead of build, monthly fee, fast start. The limit shows as soon as content comes from your own source, review chains are required, or the site itself is part of the product.

### AI app builder

Describe instead of build. Fastest to something visible, but the result is an application assembled in the browser and tied to the vendor's building blocks. For a site that needs to be found, that is the pricier route, because machine-readable pre-rendering has to be bought in.

### Build it statically yourself

The route we took. High one-off effort, near-zero operations afterwards, full auditability. It pays off when the website is a selling surface rather than a business card.

Recommendation by size:

- Solo: Only with development skills or someone who looks after it.
- Mid-market: A good default when the site influences revenue.
- Enterprise: A good default because acceptance testing can be automated.

## Context

- Implements method: [Demand Creation vs. Demand Capture](https://www.convios.com/en/methods/demand-creation-vs-capture) — Creating demand means publishing content that keeps being found without ad spend, and Astro ships exactly that content as finished pages instead of making it depend on a runtime layer.
- Implements method: [The 95:5 Rule](https://www.convios.com/en/methods/95-5-rule) — The rule demands presence with the buyers who are not in market today, and that contact runs through search and answer engines, which read a page more reliably when nothing has to be loaded at runtime.
- Alternative: [Lovable](https://www.convios.com/en/toolbox/lovable)
- Displaces: Bought-in pre-rendering for search engines, Runtime servers just to render pages

## Evidence

- MIT licence and open development — https://astro.build/press/ (as of 2026-07-30)
- Cloudflare acquired The Astro Technology Company on 16 January 2026 — https://www.cloudflare.com/press/press-releases/2026/cloudflare-acquires-astro-to-accelerate-the-future-of-high-performance-web-development/ (as of 2026-07-30)
- All full-time staff continue working on Astro at Cloudflare; licence and open governance remain in place — https://astro.build/blog/joining-cloudflare/ (as of 2026-07-30)
- 7m USD seed round in January 2022 led by Lightspeed Venture Partners — https://astro.build/blog/the-astro-technology-company/ (as of 2026-07-30)
- Sponsorship money and annual budget are disclosed publicly via Open Collective — https://opencollective.com/astrodotbuild (as of 2026-07-30)