What is Astro? The web framework, explained.

Both, and the decision is made per route. Prerendering is the default: the whole site is generated at build time and served as static HTML. A single route renders at request time with export const prerender = false; with output: "server" the default flips and individual pages come back with prerender = true. For dynamic pieces inside an otherwise static page there are server islands, rendered independently on the server and deferred with server:defer – the shell stays cacheable while the personalised element loads afterwards.

Not necessarily. By default the entire site is prerendered and static HTML pages are sent to the browser, which runs on any static host or CDN. If individual routes need to render at request time, you enable on-demand rendering there and add an adapter for the target runtime. Officially maintained adapters include the ones for Node, Vercel and Cloudflare. Which model makes sense for your project is covered under Astro hosting.

To build, yes: Astro is a JavaScript framework and its build runs in a JavaScript environment. In the browser the answer is different. By default Astro removes all client-side JavaScript from components. Anything that should run in the browser is requested explicitly, per component, through a client directive. A page with no interactive islands reaches the user with no framework JavaScript at all.

An island is an enhanced UI component on an otherwise static page of HTML – the term comes from the Astro project itself. There are two kinds. Client islands are interactive components that hydrate individually in the browser, controlled with client:load, client:idle or client:visible. Server islands render independently on the server via server:defer, so the page shell can stay cached.

Yes. Astro is UI-framework-agnostic, with official integrations for React, Preact, Svelte, Vue, SolidJS and Alpine.js. You can combine several frameworks in one project, but only inside an .astro file – the documentation states that only Astro components can contain components from multiple frameworks. Without a client directive your React component renders on the server and arrives as plain HTML. Existing components can often be carried over rather than rewritten.

The technical foundations are strong. By default your site is prerendered and served as static HTML, so content sits in the delivered document rather than appearing only after hydration. Built-in image optimisation infers dimensions and thereby avoids layout shift. Rankings still come from content, structure and links – a framework does not replace those. What is actually holding an existing site back shows up in an SEO audit.

The difference is architectural. Astro is a multi-page architecture with server rendering as the default, and it removes client-side JavaScript unless something asks for it. Next.js brings the app model that logged-in areas, dashboards and heavy client state assume. Rule of thumb: the more your project is a website, the more Astro fits; the more it is an application, the more Next.js fits. The long version: Astro vs. Next.js.

In their defaults they sit close together: all three produce static HTML that can live on any CDN. The differences are around that. Astro brings a component model in which interactive islands are written in React, Preact, Svelte, Vue, SolidJS or Alpine.js, a typed content model through content collections with Zod – and the option to let individual routes render at request time. Hugo and Jekyll are leaner in return, carry no JavaScript toolchain behind them and remain a good choice for purely static documentation or blogs. Official migration guides to Astro exist for both.

Four cases, and we would rather name them up front. First, logged-in applications with roles, real-time data and heavy client-side state – there an app framework is the right foundation. Second, pages where nearly every component would be interactive; the islands architecture then loses its point. Third, projects that depend mainly on a plugin ecosystem – shop, membership area, booking – where nobody wants to touch code. And fourth, teams who want to build layouts visually themselves: Webflow is the better tool for that, and we build it too.

Astro has been public since 2021 and follows semantic versioning. The current major line is Astro 7. The cadence is brisk: Astro 6.0 went stable in March 2026 and Astro 7.0 followed in June 2026 – two majors within one year. The planning-relevant part: extended maintenance with security fixes covers exactly one previous major version. Nothing dramatic follows from that, but an operational decision does: major upgrades belong in the calendar as a small recurring task rather than as a rebuild every three years. What that looks like is under Astro upgrades.

It is somewhat harder than for WordPress or React, and we say so plainly: there are fewer CVs with "Astro" on them. The effort is still smaller than it sounds, because Astro components are HTML, CSS and TypeScript and interactive islands are written in React, Preact, Svelte, Vue, SolidJS or Alpine.js. You are hiring from the general JavaScript market, not from an Astro market. The honest side of the ecosystem belongs here too: there is no plugin marketplace of the WordPress kind, and the documentation itself notes that some migration guides are still stubs.

Not automatically. If five pages stay five pages, change rarely and nobody in-house wants to work with Git, a visual tool gets there faster and cheaper – in that case we suggest Webflow. Astro starts paying off once page types repeat, once a blog or knowledge section joins, once content comes from a structured source, once load time and discoverability matter commercially – or once you want repository, hosting and domain fully in your own hands.

Usually yes. Official migration guides exist for WordPress, Next.js, Gatsby, Hugo, Jekyll, Eleventy, NuxtJS, SvelteKit and Docusaurus, among others – though the documentation itself notes that many of them are still stubs. For Webflow and Framer there is no official guide; that route means exporting or extracting the pages and rebuilding. Process and risks: migration to Astro.

Yes, through three combinable routes. A headless CMS with an interface, previews and permissions for everyone who edits daily. Content collections with Markdown in the repository, when content is structured and changes rarely. Or editing by chat: because the Zod schema is machine-addressable, an agent can only fill fields that exist, in formats that validate – change a paragraph, publish a post, swap an image as a message rather than a CMS session, with a commit, a preview and a rollback. That chat agents are day-to-day work here is evidenced by our own WhatsApp AI agent. What the route does not replace: approval workflows in large editorial teams, and structural layout changes.

Yes, and that is one of the reasons for building this way. Astro is open source under the MIT licence; there is no licence, no proprietary editor and no building block tied to one supplier. What you need: somebody who works with HTML, CSS, JavaScript and Git, the repository with its full history, documented build and deployment steps, and a manageable component library rather than a hundred individual pages. A handover stays uncomfortable, but it is onboarding rather than a rewrite.

We are – for what we built and what does not work the way it was agreed. That gets fixed under statutory warranty without a new invoice. A change request is a separate matter: a new feature or a new page type is a commission, not a defect. Which of the two categories a report falls into is something we say before we start, not afterwards. Fixed response and restoration times belong in a written maintenance agreement if your procurement team needs them.

That the classic attack surface of a content website largely disappears. A prerendered Astro site has no database, no admin login and no plugin ecosystem in the delivery path – the usual route through a vulnerable extension does not exist. What remains and genuinely deserves review: permissions on the repository and build pipeline, the provenance of npm dependencies, form and API endpoints, every route with on-demand rendering together with its runtime, a headless CMS as a separate system with its own login, and the domain and hosting accounts. We work with mandatory two-factor authentication, least privilege and regular dependency updates.

Astro is a framework and processes no personal data itself – the question is decided by hosting, forms, analytics and CMS. A static build can run with a provider in the EU or in Germany. We self-host fonts rather than loading them from third-party servers, cookie-free analytics options exist, and the form endpoint is chosen deliberately rather than inherited. We name every service provider involved so your data protection officer can put the processing agreements in place. We do not provide legal advice; the sign-off stays with you. More on this: GDPR-compliant websites.

Because we would rather say so than invent one. We do not yet have a publicly showable Astro client project. What we do have: a Webflow reference we built and maintain, our own products that we developed and shipped ourselves, and years of software development with repositories, continuous integration and operations. The framework is the smaller part of that work. Testing us is cheap: the initial assessment costs nothing, the repository is yours from day one, and measurement happens before and after launch inside your own project.

Yes. Astro is open-source software under the MIT licence; the framework itself carries no licence fee and no per-seat price, commercial use included. Costs arise from development, content, hosting and operations – and, if you use one, from a headless CMS.

An open-source project developed publicly in the withastro/astro repository. The MIT licence lists the copyright from 2021 in the name of Fred K. Schott. Astro is maintained and advanced by a core team and a community of contributors, currently on the Astro 7 line.

Official integrations exist for React, Preact, Svelte, Vue, SolidJS and Alpine.js. Several of them may appear on the same page, but only inside an .astro file – per the documentation, only Astro components can contain components from multiple frameworks.

Yes, that is one of the cases it was built for. Posts live as Markdown, MDX or Markdoc in a content collection with a Zod schema, queries run type-safely through getCollection(), and the built-in caching is explicitly intended for collections with thousands of entries.

The official name is simply Astro. People search for "Astro JS" or "Astro.js" anyway, because it is a JavaScript framework and many frameworks carry that suffix. Both refer to the same project – adding "framework" to your query saves time, since the word "Astro" is heavily occupied online by astrology services.