What's New in Astro 7.2: Incremental Builds Land

Astro 7.2 shipped on August 6, 2026, and it carries the feature big content sites have been asking for since static builds existed: incremental static builds. Stop rebuilding pages that have not changed. It is experimental for now, but the design is worth understanding today, because it changes the build-time math for any site with hundreds or thousands of prerendered pages.

Alongside it: a way to opt out of session support for smaller bundles, a background mode for astro preview, and a small quality-of-life fix for custom loggers. Here is the tour.

The headline: incremental static builds (experimental)

Today, every astro build regenerates every prerendered page, whether it changed or not. On a ten-page marketing site nobody notices. On a blog with a thousand posts, a docs site, or a programmatic SEO build, the rebuild time is almost entirely spent re-rendering pages that are byte-for-byte identical to the last deploy.

Astro 7.2 introduces a cache that skips those pages. The mechanism has two halves:

• Astro’s half: the build hashes each route’s full module graph - the template, its layouts, components, imported assets, and package code. If any code the page depends on changes, the hash changes, and the page rebuilds.
• Your half: routes opt in by returning a cacheKey from getStaticPaths(). That covers the data side, which Astro cannot see into. A page is reused only when both the module hash and the cacheKey match the previous build.

Enable it in your config:

import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    incrementalBuild: true,
  },
});

Then give each route a cache key. For content collection pages, the entry’s digest is the natural fit:

---
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map((post) => ({
    params: { slug: post.id },
    props: { post },
    cacheKey: post.digest,
  }));
}

const { post } = Astro.props;
---
<h1>{post.data.title}</h1>

Things worth knowing before you flip it on:

• Routes without a cacheKey always render. Opting in is explicit and per-route, so an existing project behaves exactly as before until you add keys.
• The cache lives in cacheDir (default node_modules/.astro/). For CI to benefit, you need to persist that directory between builds - the same way you already cache node_modules.
• It is experimental. The team is collecting feedback, and the full design is written up in the incremental builds RFC. Do not build your deploy pipeline’s correctness around it yet; do try it on a branch and report what you find.

Opt out of sessions: session: false

Astro 7 gave server-rendered pages built-in sessions. Astro 7.2 adds the other direction - if you do not use them, you can now remove the machinery:

import { defineConfig } from 'astro/config';

export default defineConfig({
  session: false,
});

With that set, Astro.session is undefined, the Cloudflare, Netlify, and Node adapters skip setting up their default session driver, and the session runtime disappears from your bundle. Any defensive if (Astro.session) checks you already have keep working.

There is also an automatic version: projects with no session driver configured get the runtime tree-shaken out regardless of the flag. Fully static sites had nothing to remove in the first place - this one is for server-output projects that never touched sessions and did not want to pay for them.

astro preview --background

astro dev learned to run in the background earlier in the 7.x line; astro preview now matches it:

astro preview --background

The server detaches, and three companion commands manage it: astro preview status, astro preview logs, and astro preview stop. Like the dev equivalent, it activates automatically for AI coding agents - which is exactly where it earns its keep. An agent can start a production preview, curl it, read the logs, and shut it down without holding a terminal open. If you script your own smoke tests against a built site, same win.

Relative logger entrypoints

Small one: custom loggers can now be pointed at with a relative path instead of a URL:

import { defineConfig } from 'astro/config';

export default defineConfig({
  logger: {
    entrypoint: './src/custom-logger.js',
  },
});

The URL form still works; this just removes a conversion dance for the common case.

Upgrading

Minor release, no breaking changes, one command:

npx @astrojs/upgrade

Or bump directly: npm install astro@latest, pnpm upgrade astro --latest, or yarn upgrade astro --latest. If you are still on Astro 6 or earlier, the jump to the 7 line is the one with real migration steps - we covered it in What’s New in Astro 7.

Who should care

If your site is a handful of pages, Astro 7.2 changes little for you today - upgrade for the fixes and move on. The release is aimed at the sites that grow: blogs with deep archives, docs, podcast back catalogs, programmatic pages. That is where skipping unchanged pages turns a minutes-long build back into a seconds-long one, and where the cacheKey pattern is worth wiring in early.

Every AeroLaunch theme runs on the Astro 7 line, so a theme you pick up today upgrades to 7.2 with the standard one-command bump - and the content-heavy ones stand to gain the most from incremental builds as the feature stabilizes. Drop in your content, keep shipping, and let the build cache do the boring part.