← Back to the blogI upgraded this platform to Astro 7 (and barely had to touch anything)
astrowebdevfrontendviterusttutorial

I upgraded this platform to Astro 7 (and barely had to touch anything)

I migrated albertorrg.dev from Astro 6 to Astro 7 in a few hours. Here's what really changed: Vite 8 with Rolldown (the Rust bundler), a migration without touching the config, my real build times, and the rock I tripped over — with code examples.

If you're reading this on albertorrg.dev, you're already looking at Astro 7 in action. A few hours ago this same platform was running on Astro 6, and I just migrated it to version 7, which shipped on June 22, 2026. Here's how it went, because for a major version jump I was surprised by how little I had to touch.

This isn't an "I read the changelog" post. It's what actually happened when I sat down to upgrade my own site, with the real numbers from my build and the one rock I tripped over along the way.

Why I bothered

This site is my lab. I use it precisely to try new things on something I care about that's actually in production, not on a throwaway project. When Astro 7 came out I wanted to see it running here before recommending it anywhere. The rule I always set for myself is the same: if I'm going to suggest it, I break it in my own house first.

The big one: Vite 8 and Rolldown

The headline of Astro 7 is that it now sits on top of Vite 8, and Vite 8 brings Rolldown, a new bundler written in Rust that replaces the usual pair (esbuild for development, Rollup for production). The idea is a single engine, fast and consistent, for both stages.

After upgrading I went to check what actually got installed, and there it was:

astro        7.0.3
vite         8.1.0
rolldown     1.1.3
tailwindcss  4.3.1

The Rust part isn't just marketing: the .astro compiler and the content processing moved to Rust too. On a site like this one, which is static and generates all its HTML at build time, you feel that directly in the timings.

The migration itself: a number change

Here's the part I liked most. I opened package.json braced for an afternoon of breaking and fixing things, and in the end the core change was this:

  "dependencies": {
-    "astro": "6.3.8",
+    "astro": "7.0.3",
  },
  "devDependencies": {
-    "@tailwindcss/vite": "4.3.0",
-    "tailwindcss": "4.3.0"
+    "@tailwindcss/vite": "4.3.1",
+    "tailwindcss": "4.3.1"
  }

My astro.config.mjs didn't need a single new line. Astro 7 makes several things stable by default that used to be experimental flags (the Rust compiler, queued rendering, advanced routing), so if you'd been enabling those by hand you'd have to pull them out of your config. I didn't have them on, so my config stayed untouched:

export default defineConfig({
  site: 'https://albertorrg.dev',
  output: 'static',
  trailingSlash: 'always',
  // i18n, integrations, tailwind... all the same as Astro 6
});

Zero config migration. On a major version, that's the best thing that can happen to me.

What I validated before publishing

I don't like deploying on faith. Before touching production I ran the type check and a full build locally:

astro check   # 0 errors, 0 warnings
astro build   # 20 pages generated

astro check passed clean without me having to adjust any types. And the production build generated the site's 20 pages (both homes, the blog in Spanish and English, every article, the RSS feeds and the sitemap) in around 3 seconds. Then I opened the Astro 7 site next to the Astro 6 one and compared them section by section: identical. That was the part I cared about most, because compiling is one thing and looking the same is another.

The deploy: one git push and on with my day

This site deploys itself. I don't log into the server to copy files: I git push to main and from there the pipeline takes over, running the pull on my own production machine, rebuilding the containers with Docker and bringing everything back up with its healthcheck. So "publishing Astro 7" was literally a commit with two files and a push.

To confirm it had really landed, the simplest thing in the world:

curl -s https://albertorrg.dev/ | grep generator
# name="generator" content="Astro v7.0.3"

That Astro v7.0.3 coming out of the live site was my signal that we were on the other side.

The rock in the road (which wasn't Astro's fault)

Not everything was textbook, but the problem was mine, not Astro's. I keep the repo on a disk with an NTFS filesystem, and when the package manager tried to assemble the dependencies there, the store landed on that disk and the install crawled: it couldn't link files across different disks and ended up copying everything by hand, painfully slow.

The fix was to send the store to a volume on the good disk, and the install went from never finishing to resolving in seconds. I'm writing it down in case it happens to someone else: when an install turns eternal, check which disk the store is falling on before you blame the tool.

Is it worth upgrading?

In my case, no doubt. Faster builds thanks to the move to Rust, zero config debt, and a site that ended up looking exactly the same as before. It's the kind of upgrade you want: you take the performance win without paying the toll of rewriting half the project.

If you have a reasonably standard Astro 6 site, my advice is to try it locally, run your check and your build, compare a couple of screens and go for it. It took me less than I expected, and it's already running where it matters most to me: right here.

Comments

Loading comments…