Astro 6.3 — what's new in the latest version of the framework?

In early May 2026 the Astro team released version 6.3 of the framework. The update isn’t as loud as a big major release, but it brings a few concrete changes worth knowing about — especially if you’re considering Astro for a new project or already have a site built on it.

The headline feature is experimental advanced routing, which gives you full control over how the site handles incoming requests. On top of that, Astro deals better with images fetched from external sources, and the default settings for SVG files have gained extra safeguards. One at a time.

What exactly changes in Astro 6.3?

The 6.3 release isn’t a revolution, just a solid tidying-up of the details. The main themes are: more flexibility for advanced integrations, safer work with media and small improvements to cookie handling. Each of these changes answers real needs that have come up in the community and on GitHub over recent months.

The full release notes were published by Matthew Phillips on the official Astro blog on 7 May 2026. Below is a summary of the most important points, with some practical commentary.

Experimental advanced routing

This is by far the biggest change in 6.3. Astro now gives developers full control over how a user’s requests flow through the site. You can hook in your own handlers, decide what order they run in, redirect part of the traffic to external services or mix a framework like Hono straight into the Astro pipeline.

In practice that means Astro stops being a “closed box” that only serves its own pages and becomes a flexible tool for building web apps with mixed traffic. You could, for example, serve everything under / as classic Astro pages and hand /api over to a completely different back end.

The simplest example looks like this:

import { FetchState, astro } from 'astro/fetch';

export default {
  fetch(request: Request) {
    const state = new FetchState(request);
    if (state.url.pathname.startsWith('/api')) {
      return fetch(new URL(state.url.pathname, 'https://api.example.com'));
    }
    return astro(state);
  }
};

In this code, anything hitting a URL starting with /api goes to an external service, while the rest is handled by Astro as usual.

It gets even more interesting with the Hono integration — a light framework for building apps that run in environments like Cloudflare Workers, Deno or Bun. Astro 6.3 exposes ready-made handlers compatible with Hono, so you can attach them as further middleware layers:

import { Hono } from 'hono';
import { logger } from 'hono/logger';
import { actions, middleware, pages, i18n } from 'astro/hono';

const app = new Hono();

app.use(logger());
app.use(async (c, next) => {
  if (new URL(c.req.url).pathname.startsWith('/admin')) {
    return c.redirect('/login');
  }
  return next();
});

app.use(actions());
app.use(middleware());
app.use(pages());
app.use(i18n());

export default app;

The developer decides the order in which the logger, custom middleware, actions, pages and internationalisation run. Astro becomes one of the building blocks rather than a monolith.

The handlers you can assemble into a pipeline are: astro, trailingSlash, redirects, sessions, actions, middleware, pages, cache and i18n. They can be imported from astro/fetch or astro/hono, depending on your preferred style.

The feature is currently marked as experimental — it needs the relevant flag enabled in the config and may still evolve. The full documentation is in the official Astro docs.

Redirect handling for remote images

This is a change that sounds technical but, in practice, solves an annoying problem. Many image-hosting services — CDNs, media libraries, cloud integrations — don’t return the file directly but redirect to a different URL. Previously, Astro simply got lost in that case.

In version 6.3 the framework follows up to 10 redirects when fetching a remote image. Importantly, every URL in the redirect chain is checked against your security config (image.remotePatterns or image.domains). If any of the redirects leads to a host that isn’t allowed, you get a clear error message instead of a silent failure.

A practical scenario:

import { defineConfig } from "astro/config";

export default defineConfig({
  image: {
    domains: ["example.com", "cdn.example.com"]
  }
});

And the usage in a component:

<Image
  src="https://example.com/assets/image.png"
  width="1920"
  height="1080"
  alt="Sample image."
/>

If example.com redirects to cdn.example.com — it works, because both hosts are on the list. But if it redirects to malicious.com (which isn’t on the list) — Astro shows an error instead of quietly fetching unverified content.

For less restrictive projects you can also allow all https hosts:

import { defineConfig } from "astro/config";

export default defineConfig({
  image: {
    remotePatterns: [{ protocol: 'https' }]
  }
});

A small thing, but it saves plenty of hours of debugging when integrating with external CDNs.

SVG: processing off by default

Here the Astro team chose security. Previously the framework could process SVG files through Sharp (converting them to PNG, for example). The problem is that an SVG is a text document that can contain embedded scripts. Processing an unknown, untrusted SVG created a potential risk.

In Astro 6.3 this operation is off by default. If you try to pass an SVG into the image optimisation pipeline, you’ll get a clear error. Importantly — importing an SVG as a component in a page still works as normal. The change only affects rasterisation (turning it into a bitmap such as PNG).

If you genuinely need this feature and you know your SVG sources are trusted, you can turn it on manually:

import { defineConfig } from "astro/config";

export default defineConfig({
  image: {
    dangerouslyProcessSVG: true,
  }
});

The name of the flag (dangerouslyProcessSVG) is a signal in itself: use it deliberately, at your own risk.

Small improvements: a new consume() method for cookies

This is a change that’ll please developers working with AstroCookies. There’s a new consume() method that marks a cookie as “consumed” and returns the appropriate Set-Cookie headers. If, after calling consume(), you try to call set() again on the same cookie, you’ll get a warning in the console.

The method replaces the earlier static AstroCookies.consume(cookies) method, which has been marked as deprecated. The old call still works (backward compatibility), but the new form is clearer and less error-prone.

What does this mean in practice for business websites?

If you’re not a developer and you’re reading this to find out “will our Astro site benefit from any of this” — the answer is simple: probably yes, but you won’t notice much at first glance.

The most important changes are about security (SVG, redirect validation) and flexibility for more advanced integrations (Hono routing). A typical business website, landing page or blog gets them “in the package” — with no need to rework the code. For us, updating to a newer version is usually a quarter of an hour’s work plus verifying that the build and deploy still work correctly.

In practice you’ll more often see the benefits of the whole Astro 6.x line — faster builds, better Core Web Vitals, cleaner types in content collections. Version 6.3 is simply another step in the same direction.

How to update a project to Astro 6.3?

The quickest way:

npx @astrojs/upgrade

You can also do it manually, depending on your package manager:

npm install astro@latest
pnpm upgrade astro --latest
yarn upgrade astro --latest

After updating, it’s worth running the build (npm run build) and checking that nothing breaks. Most projects will update without any changes. The full list of changes is in the official Astro changelog on GitHub.

If you’re only just starting out with this framework, we recommend our intro: What is Astro? A modern framework for building fast websites. And if you’re wondering whether it’s worth migrating from WordPress to Astro, we have a separate piece too: Why Astro instead of WordPress?. We follow the wider ecosystem as well — see what’s new in Starlight, Astro’s documentation tool.

At Astrofy we keep our clients’ projects up to date with the latest stable versions of Astro. If you have a site worth rebuilding, or you’re planning a new project — get in touch and we’ll happily take a look at what can be done.