How to Update Astro on Your Website Safely

To update Astro safely, check which version you're on with pnpm astro info, run pnpm dlx @astrojs/upgrade on a fresh Git branch, then build the site, compare it with the live one and redeploy. Within the same major version (7.3 to 7.4, say) that's a ten-minute job. Moving from Astro 6 to 7 takes longer, because the new compiler is stricter about HTML and handles whitespace differently, so give it its own branch and an hour. This guide walks through each step and explains how to tell whether a security advisory actually affects your site.

Why now#

Astro 7.4 came out on 15 October 2026. For most sites it's a quiet, worthwhile update: a new astro build --timings flag that shows where your build spends its time, separate image services for build time and on-demand pages, and a notFound() handler for custom server entrypoints. It also raises the minimum Node.js version for Astro and its official integrations to 22.22.0, which is the change most likely to trip up an older setup.

A few days earlier, on 12 October, three security advisories were published on the Astro advisories page, rated Moderate and Low. An earlier batch on 27 August included one rated Critical. Advisories come out every few weeks, so a regular update routine is worth more than any single release.

Step 1: Find out which version you're running#

Open a terminal in your project folder and run:

pnpm astro info

astro info reports your Astro, Vite and Node.js versions, your package manager, output mode, adapter and integrations (CLI reference). Paste it into any bug report too. To see which packages have newer releases, run pnpm outdated. With npm, use npx astro info and npm outdated.

Then check where your major version stands. Astro's upgrade guide says the core team provides extended maintenance "for security fixes only" for one previous major version. At the time of writing, the latest release on npm is 7.4.0, so:

If you're on Astro 5 or older, plan the move now. The upgrade guides go one major version at a time, so you'll work through them in order.

Step 2: Read the advisory before you panic#

Each advisory lists the package it affects, the vulnerable versions and the patched version. Two details tell you how urgent it is for your site.

Which package. Not every Astro advisory is about astro itself. The 12 October server-side request forgery advisory, for example, is in @astrojs/node, the adapter for running Astro on a Node.js server, and is patched in 11.1.7. If your package.json doesn't list that adapter, it doesn't apply to you.

Which feature. The XSS advisory for script and style elements only affects sites that pass attacker-controlled data as a dynamic child of a <script> or <style> element in MDX or JSX, and it's fixed in astro 7.3.2. A brochure site whose content you write yourself is very unlikely to do that.

Many advisories concern on-demand rendering: image endpoints, adapters and anything that handles a request on a server. A fully static site, which is what astro build produces when you don't add an adapter, is plain HTML, CSS and JavaScript files on your host. The Freeframe Astro templates are built this way; the deploying docs show the setup for each host. That often means a server-side advisory doesn't reach the live site, but Astro still runs on your computer and on your host's build servers, so don't skip updates on that basis. A patch release costs you a few minutes.

If your site uses an adapter (@astrojs/node, @astrojs/netlify, @astrojs/vercel or @astrojs/cloudflare) and renders pages on demand, treat Critical and High advisories as same-day work.

Step 3: Check your Node.js version#

Astro 7.4 needs Node.js 22.22.0 or newer; the engines field of the astro package now says >=22.22.0. Check yours with:

node --version

If it's older, update Node.js on your computer first, then on your host, which usually has a Node.js version setting in the project's build settings (check your host's docs). The Freeframe Astro templates already ask for Node.js 24 or newer in their package.json, so they're well clear of the new minimum.

Astro's support policy explains that a minimum Node.js bump within a major version can happen in a minor release, which is exactly what 7.4 did. It's worth checking the release post for a line about Node.js every time you update.

Step 4: Apply a patch or minor update#

Start from a clean state you can return to: commit your work, then create a branch:

git switch -c update-astro

The easiest way to update is the official upgrade tool, which updates Astro and every official integration you use in one go (upgrade guide):

pnpm dlx @astrojs/upgrade   # or: npx @astrojs/upgrade

If you'd rather do it by hand, update astro and any @astrojs/* packages together, for example:

pnpm add astro@latest @astrojs/check@latest

Update integrations with Astro, not on their own. The 7.4 release notes say the new versions of @astrojs/cloudflare and @astrojs/markdoc require astro@^7.4.0, so updating one without the other can leave the project unable to install.

To stay on a supported older major version and take only its security fixes, pin the line instead: pnpm add astro@6 installs the newest 6.x release.

Step 5: Moving from Astro 6 to 7#

Astro 7 was released on 22 June 2026 (npm). The upgrade to v7 guide lists every breaking change. For a typical small static site, these are the ones that matter:

• A stricter compiler. Astro 7 replaces the Go-based compiler with a Rust one. Unclosed tags now fail the build, and invalid nesting, such as a <div> inside a <p>, is no longer quietly corrected. The build error points to the file; add the missing closing tag or change the outer element.
• Whitespace. compressHTML now defaults to 'jsx', so spaces between inline elements can disappear: a link that runs straight into the next word is the usual sign. Add {" "} where you need a space, or set compressHTML: true in astro.config.mjs to keep the old behaviour.
• Markdown. A new Markdown processor is the default and @astrojs/markdown-remark is no longer installed for you. If you use remark or rehype plugins, install that package and follow the guide's steps to switch back to the unified processor.
• Experimental flags. Several Astro 6 experimental features are now stable. Remove logger, queuedRendering, rustCompiler, advancedRouting and cache from the experimental block in your config.
• A reserved file name. src/fetch.ts is now used for advanced routing. If you have a file with that name for something else, rename it.

The same guide covers Vite 8, which Astro 7 uses for development and builds. Run pnpm dlx @astrojs/upgrade, work through the build errors one at a time, and read git diff before you commit.

Step 6: Build, compare and redeploy#

An update isn't finished until the built site has been checked. In the project folder:

pnpm astro check
pnpm build
pnpm preview

astro check runs type and template diagnostics, pnpm build writes the site to dist/ and pnpm preview serves that folder locally. On Astro 7.4 you can also run pnpm astro build --timings to see which pages or images take the longest to build. Then check:

• Every page loads. Click through the menu, the footer links and the 404 page.
• Spacing looks right. After the move to Astro 7, compare a few pages with the live site side by side, paying attention to text next to links, icons and bold words.
• Interactive parts work. Mobile menu, tabs, filters and the contact form (send a real test message; see the forms docs if it's not set up yet).
• The build log is clean. New warnings often flag something the next major version will remove.

Commit package.json and pnpm-lock.yaml. The lockfile is what makes your host install the exact versions you tested. Merge the branch and deploy as usual, then open the live site in a private window so you aren't looking at a cached copy.

Make updates routine#

• Turn on Dependabot security updates if your code is on GitHub (repository Settings, then Advanced Security; see GitHub's docs), so you get a pull request when a dependency has a known vulnerability.
• Watch the Astro blog, where every minor release and a monthly round-up are posted.
• Update monthly. Small, regular updates are easier to check than a year's worth at once.

Updating Astro is separate from updating a template. Once you've customised a template, pnpm dlx @astrojs/upgrade changes the framework underneath and leaves your pages alone. When a new template version adds something you want, Versions and updates explains how to copy over just those files. We've written the same guide for updating Next.js, and if you'd rather not update a framework at all, our Next.js vs Astro vs HTML comparison explains when plain HTML is the simpler choice. Every Astro template builds to a static site that any host can serve.