# Upgrade Astro and Its Integrations in an Astro Site

Yes. A Rush agent bumps Astro, its integrations and plugins with pnpm, runs astro check and the full build, and opens one pull request that leaves out what broke.

[Run this on Rush](https://cloud.getrush.ai/run/upgrade-astro/astro/), in a Project that has your repository.

## What the agent does

In a site like satnaing/astro-paper, package.json pins astro ^7.0.3 with three official integrations, @astrojs/mdx ^7.0.0, @astrojs/sitemap ^3.7.3 and @astrojs/rss ^4.0.19, plus @astrojs/markdown-remark ^7.2.0, which astro.config.ts imports for its unified() processor. Around them sit the packages that break on an Astro major: @tailwindcss/vite and tailwindcss ^4.3.2 wired in through vite.plugins, the remark-toc, remark-collapse and rehype-callouts plugins, @shikijs/transformers ^4.3.0 for code blocks, and satori ^0.26.0 with sharp ^0.35.2, which render the OG images in src/pages/og.png.ts. The agent reads astro.config.ts first, so it knows which of these the site actually wires in.

The repository uses pnpm: pnpm-lock.yaml is lockfileVersion 9.0, pnpm-workspace.yaml lists esbuild and sharp under allowBuilds, and .github/workflows/ci.yml installs pnpm 11.3.0 on Node 24 and runs pnpm install --frozen-lockfile. package.json requires node >=22.12.0. The agent installs the same pnpm and Node, then runs pnpm outdated to list every package behind, grouped into the Astro core and integrations, the markdown pipeline, styling, the OG image stack, and tooling (@astrojs/check, eslint-plugin-astro, prettier-plugin-astro 0.14.1, typescript ^6.0.3).

There is no test script and no test file in the tree, so the build is the test. The build script is astro check && astro build && pagefind --site dist && cp -r dist/pagefind public/, which type-checks every .astro file and content collection in src/content.config.ts, renders every post under src/content/posts, generates the OG images and builds the Pagefind search index. The agent runs it after each group of bumps, along with pnpm run lint and pnpm run format:check, the two other steps ci.yml runs.

When a group fails, the agent reads the error, checks the package's changelog for a breaking change it can apply (a renamed config option, a changed plugin signature), and keeps the bump only if the fix is small and the build passes again. Otherwise it reverts that group in package.json and pnpm-lock.yaml and records the failing command and its first error lines. Exact pins such as prettier 3.9.3 are moved to an exact new version, not widened to a range.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Upgrade astro, every @astrojs/ package and the remark, rehype, shiki, tailwind, satori and sharp packages to their latest compatible versions with pnpm, one group at a time. After each group run pnpm run build (it includes astro check and the Pagefind index), pnpm run lint and pnpm run format:check. Keep a bump only if all three pass; if a small config change from the changelog fixes it, make it and say so. Revert any group that still fails and record the command and error. Open a pull request with one line per bump (old and new version) and a section for each upgrade left out and why.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The pull request changes package.json and pnpm-lock.yaml, and astro.config.ts or a file under src/ only where a changelog required it. The description lists each bump with its old and new version, grouped as the agent upgraded them, then the upgrades it left out with the command that failed and the error. The repository's own ci.yml runs on the pull request: frozen-lockfile install, lint, format check and the full build.

A reviewer checks the config changes against the Astro and integration upgrade notes, opens the deploy preview if the site has one to look at a post, the tags page, search and an OG image, and decides whether the upgrades left out are worth a separate pull request. Every build log is in the session transcript.

## Run it on every Monday morning

Astro and its integrations release often, and a theme repository falls behind quickly. A scheduled job can send this request each Monday with the repository in resources, so each week's pull request is small and every bump in it has passed the build.

With a webhook URL on the API key, Rush posts run.completed when the turn ends, and your handler can post the pull request link to the channel that owns the site.

## Why run it on Rush?

An Astro upgrade often fails in the build, not at install: astro check rejects a changed type, the markdown pipeline throws on a plugin, or sharp needs a rebuilt native binary. Finding which bump caused it means installing, building and reverting several times. In a Rush sandbox the agent does that with the repository's own pnpm and Node versions, and each pnpm and build command, with its output, stays in the transcript.

A dependency bot opens one pull request per package and leaves the red ones for you. Here the result is one pull request that already builds, with the failures explained. Several sites or themes can be upgraded at the same time, each in its own sandbox.

## Frequently asked questions

### My Astro site has no tests. Is a build enough?

For a static site the build covers a lot: astro check type-checks components and content collections, and astro build renders every page. It does not compare how pages look, so a reviewer should still open a few pages in a preview.

### Will it handle an Astro major version?

It tries. It reads the upgrade guide, applies the config changes it names, and keeps the major only if the build, lint and format check pass. If the change is larger, it leaves the major out and says what blocked it.

### Does it work with npm or Yarn instead of pnpm?

Yes. The agent uses the package manager the lockfile names. Change the request to name npm or Yarn if you want to be explicit.

### What about sharp and other native packages?

pnpm-workspace.yaml allows builds for esbuild and sharp, and the agent runs pnpm install with that file in place, so their install scripts run in the sandbox the way they do in CI.