Astro Upgrade – Major Version Upgrade to Astro 7

In short

Why this page exists: Astro's own upgrade documentation states that extended, security-only maintenance covers exactly one previous major version. The current line is Astro 7. If you are running Astro 5 or older, your framework no longer receives security fixes.
Why it suddenly affects a lot of teams: Astro 6.0 went stable on 10 March 2026 and Astro 7.0 arrived on 22 June 2026 – two major versions inside a single year. Planning updates once a year falls behind faster than the calendar suggests.
How to check your version in two minutes: the astro entry under dependencies in your repository's package.json names the major version. No access to the repository? Then that is the first finding – and we will look for you.
What a major upgrade actually is: not incrementing a number, but bringing framework, configuration, content model, UI integrations, adapter and CMS SDKs onto one level – and then verifying every route against the previous build.
Why skipped majors compound: each major carries its own breaking changes and its own upgrade path. Two skipped jumps mean two sets of changes landing at once on code nobody has touched for months. The effort does not grow linearly.
Without a feature freeze: the upgrade lives in its own branch with a preview environment, editors and campaigns carry on, and rollback is a revert. Your live site stays untouched until you approve the switch.
When we advise against it: if the site is small, stable and due to be replaced within a year, a major upgrade is rarely the best use of the budget. And on inherited code the audit comes before the quote – sometimes with a rebuild as the answer.

01 — Where teams start

How you know an upgrade is overdue.

Astro projects do not raise their hand. They keep working while the ground shifts underneath them. These six sentences are the ones we hear most – and almost always only once somebody wanted to change something.

“We do not even know which version this is.”

The most common starting point is not a technical problem but an information problem. The site runs, the agency contract lapsed, and nobody in the building can say whether Astro 4, 5 or 6 is underneath. While that is open, neither the risk nor the effort can be quantified honestly.

“The build worked yesterday.”

A build rarely breaks because your code changed. It breaks because something outside it changed: a Node version reaches end of life, a hosting platform swaps its runtime, a package pulls a new version through. A project on an old major line has no headroom left for that kind of movement.

“We are two majors behind.”

This is the expensive variant. Not because of the number, but because breaking changes from two upgrade cycles land on the same code at the same time. When something stops working afterwards there is no single cause any more, only a list of candidates – and each one has to be ruled out individually.

“One integration is blocking all the others.”

Astro is UI-framework agnostic: React, Preact, Svelte, Vue, SolidJS and Alpine.js run side by side as islands, each on its own release cycle. If one of those integrations does not reach the current Astro line, the whole upgrade hangs on it. Surfacing that dependency is part of the audit – not a surprise halfway through.

“The upgrade is waiting for a quiet quarter.”

There is no quiet quarter. That is exactly why we build the upgrade so it does not need one: its own branch, rebased continuously, a preview environment you can click through. The cost of waiting is not the waiting itself – it is that another major version may ship in the meantime.

“The agency that built it no longer exists.”

What is usually missing then is not the code but the knowledge around it: where the pipeline runs, which environment variables exist, who has access to CMS and domain. Reconstructing that is regularly the larger item – and the reason we start inherited projects with an audit rather than a quote.

02 — Version check

How to find out what your site actually runs on.

Before anyone talks about effort, one number belongs on the table: the major version. Five routes to it, from the easiest to the most honest.

Look in package.json – The root of your repository contains a package.json. Under dependencies there is an astro entry, and its first number is the major version. This is the most reliable answer because it describes what actually gets installed – not what was once planned.
Cross-check the lockfile – Your package manager's lockfile records which version was genuinely installed last. On projects with open version ranges the two sometimes disagree. For the question “are we still inside the support window”, the lockfile is the one that counts.
Read the last successful build – The log of your last deployment names the versions of framework, runtime and integrations in use. It also answers a second, quieter question: when was this site last built at all? If that was years ago, the build itself is the first thing to check.
Compare against the support window – The current line is Astro 7. Per the upgrade documentation, extended maintenance with security fixes covers exactly one previous major version. That produces a hard line: Astro 6 still receives security fixes, Astro 5 and older do not. Everything else on this page is a judgement call – this part is a fact.
If you have no access – Then that is the real finding. A repository nobody in your company can reach is a bigger risk than an outdated framework version, because without access no security fix can be applied either. We help reconstruct access before we talk about upgrades at all.
The honest limit of this check – The version number tells you how big the jump is. It tells you nothing about how hard it will be. That is decided by integrations, adapter, content model and how much hand-written code leans on framework internals. So the number is always followed by a look inside the repository.

The support window

Astro follows semantic versioning. Extended maintenance – security fixes only – covers exactly one previous major version. The framework offers no more headroom than that, and nobody should plan for more.

The cadence

Astro 6.0 on 10 March 2026, Astro 7.0 on 22 June 2026, Astro 7.2 on 6 August 2026. Two major versions in one year is not an outlier; it is the planning baseline.

The null result

If the check shows you are already on the current line, the answer is “nothing to do”. You get that in writing and no quote. For the ongoing case there is maintenance.

03 — Scope

What a major upgrade actually touches.

A major upgrade is not a version bump in one file. It is six work areas that have to land together – and this is the order we look at them in.

Framework and configuration

The Astro config is where major versions announce themselves most clearly: renamed or removed options, changed defaults, responsibilities that moved. We work through the upgrade guidance for each skipped major in sequence, instead of guessing at the end which jump caused which change.

Content model and collections

Content collections have existed since Astro 2.0 and have evolved across the majors – from schema definition through the config file to queries with getCollection() and getEntry(). The upgrade advantage: the Zod schema validates every entry at build time, so anything that no longer fits surfaces immediately. More under Astro CMS.

Content model

UI integrations and islands

React, Preact, Svelte, Vue, SolidJS, Alpine.js: every integration has to support the target major, and every one runs its own release cycle. We check first whether they all come along. An integration that is gone or unmaintained is its own decision – replace it, maintain it yourself, or rebuild the island.

Adapter, runtime and deployment

As soon as routes render on demand, an adapter for the target runtime is attached – the first-party options include Node, Vercel and Cloudflare. Adapter, runtime version, environment variables and build pipeline move together, not one after the other. Purely static output is considerably simpler here.

Images, types and build toolchain

Built-in image handling, the TypeScript configuration with its presets and the build toolchain all move with the majors. We run astro check, because the dev server does not type-check on its own, and we look at which images go through the optimiser and which ones sit in public/ and bypass it entirely.

CMS SDKs and external services

Astro is CMS-agnostic, but the SDKs for your headless CMS, your form service and your CRM follow their own cycles. They are pulled along during the upgrade and verified individually, not batch-updated on hope. What that means for editors is covered under headless CMS.

Headless CMS

04 — Process

How an Astro upgrade runs with us.

The same sequence for one jump as for three. What changes is how long steps two and four take – not the order.

Inventory and version verdict

Astro version, rendering mode, adapter, integrations, content collections and their schemas, CMS connection, Node version, state of the pipeline. Plus the question of whether the build even runs reproducibly today. The output is a written verdict naming your distance from the current line and the places where we expect resistance – before any quote.

Route inventory as the acceptance list

We pull every route from the sitemap, the build output and analytics, and turn it into a list: page types, dynamic routes, pagination, feeds, language variants, redirects. That list becomes the verification list later. It is written before the upgrade, so that afterwards nobody has to decide by feel whether “everything works”.

Groundwork on the main branch

Everything that carries no breaking change happens first and separately: minor and patch updates, tidied dependencies, a build that runs reproducibly, type checking via astro check. That shrinks the actual major jump down to exactly the changes it really contains – which is what makes it reviewable in the first place.

The major jump in its own branch

Only here does the version change, and it changes one major at a time rather than in a single leap, even when three jumps are open. Between jumps the project has to build. The branch is rebased onto main regularly, so your day-to-day work never has to stop and the distance between the two states stays small.

Regression testing against the previous state

Both states are built and compared: route by route against the inventory; titles, meta tags, canonical URLs, structured data and redirects diffed; images checked for format and dimensions; islands checked for hydration behaviour. Plus a preview environment you click through yourself. Because static HTML is the default output, much of this is a comparison of two build results rather than an opinion.

Switch over, measure, document

The switch goes through the regular pipeline with a defined rollback path. Afterwards: Core Web Vitals and error patterns in the field against the pre-upgrade baseline, Search Console watched, deviations chased down promptly. It closes with a short record of the new state, the places that changed and the next jump that will fall due.

05 — Operations

Upgrading without freezing the website.

The most common reason an upgrade never happens is not technical – it is fear of standstill. Marketing has a campaign planned, editors have posts queued, and nobody wants to be told they cannot publish for four weeks. That is avoidable.

Why a feature freeze is usually unnecessary

An Astro upgrade happens in its own branch. Your live website is untouched by it until you approve the switch. Content, corrections and new landing pages go to the main branch and out to production the usual way in the meantime; the upgrade branch is rebased at short intervals. What matters is the lifetime of that branch, not whether one exists at all: an upgrade branch that is open for two days is harmless. One that is open for six weeks becomes a construction site of its own.

So we cut the jump small. Everything without breaking changes – minor updates, tidied dependencies, a reproducible build – runs on the main branch beforehand. The branch then contains exactly the changes the major jump forces, and is short-lived accordingly. If a project is three majors behind, we turn one long branch into three short ones and ship in between.

One honest caveat belongs here: working on completely undisturbed without any coordination only holds while your content work and the upgrade do not overlap. If your team wants to restructure the content model or introduce new page types in the same window, agreeing a sequence is cheaper than merging it out afterwards. That costs days, not quarters – but it is not zero.

What we actually verify after an upgrade

“Looks fine” is not an acceptance test. Because Astro prerenders by default and ships static HTML, a large part of an upgrade can be verified as a comparison of two build results: old state, new state, route by route. The comparison runs against the inventory from step two, not against somebody\'s memory of the homepage.

Completeness: does every route in the inventory exist in the new build? Missing pages surface here, before they surface in Search Console.
Head data: title, meta description, canonical URL, hreflang references, Open Graph and structured data diffed directly – these are the places where a changed default quietly moves something.
Content validation: content collections are checked against their Zod schema. An entry that no longer validates after the upgrade breaks the build – and therefore not the live site.
Images: do they still go through the built-in optimisation, are dimensions and formats intact, are remote sources still allowed in the config? Wrong dimensions are the fastest route back to layout shift.
Islands: does every interactive component hydrate with its intended priority again – immediately, on idle or on becoming visible? A client:load that has quietly been pulled forward is invisible to the eye and visible in the field data.
Types and build: astro check with no new errors, and a build that is reproducible in the pipeline rather than on one person\'s machine.
Runtime: if routes render on the server, test the adapter and the runtime environment on the target platform, not just locally. That is exactly where the surprises live that stay invisible in dev mode.

After that we measure in the field against the pre-upgrade baseline – in your own project, with your own users. Third-party benchmark numbers are deliberately absent from this site: they say nothing about your website. How we go about that is spelled out under Astro performance optimisation.

How long it takes – and what moves the number

A range rather than a number, because a number without context would be wrong. For a well-maintained project exactly one major behind, with few integrations and purely static output, an upgrade typically sits in the range of a few days. Two majors behind with several UI integrations, a connected CMS and on-demand rendered routes moves towards two to four weeks. Three or more majors, plus unmaintained integrations and a build that does not run today: four to eight weeks – and at that point the question of a rebuild belongs honestly on the table rather than being avoided.

These ranges are planning experience, not a commitment. What shifts them is short and can be established up front: the number of skipped majors; how many UI integrations are involved and whether all of them are still maintained; whether routes render on demand and therefore bring an adapter and a runtime with them; how large the route inventory and therefore the verification surface is; how deep the content model goes; whether the build runs reproducibly today; and whether anyone in-house can deploy.

We deliberately do not put prices on this page, because a number without a verdict would be a guess. The cost drivers are exactly the variables just listed, and after the first call you get a defensible estimate with its assumptions written out. How our pricing is composed in general is covered under Astro development cost. Where several suppliers are involved – hosting here, CMS there, agency somewhere else – we can take on the IT project management and coordinate the sequence.

The way back

Every step exists as a commit, and the switch runs through the regular pipeline. Going back means a revert and a deployment of the previous state – one move, not a crisis project.

Your accounts

We work in your repository and your accounts. No agency-owned accounts, no credentials only we hold. Astro itself is MIT-licensed; the framework creates no dependency on us.

The weeks after

The first weeks after the switch are part of the project: field data against the baseline, Search Console watched, deviations chased down promptly – rather than declaring the project finished on switch day.

06 — Afterwards

Staying current is cheaper than catching up.

An upgrade is a project. Staying current is a habit. The difference between the two is the reason this page exists at all.

The cadence sets the cost

Astro follows semantic versioning, and the published cadence is a matter of record: Astro 6.0 went stable on 10 March 2026, Astro 7.0 on 22 June 2026 and Astro 7.2 on 6 August 2026. Per the upgrade documentation, security fixes cover exactly one previous major version. Thinking about updates once a year against that cadence is a structural problem: by the time the next date comes round, another major may have shipped and one jump has become two.

The economic point is unglamorous but solid. A major jump taken promptly is a small, isolatable set of changes against code somebody still has in their head. The same jump two years later, bundled with two others, is a search. Not because the individual changes got worse, but because the causes can no longer be separated. That is why an Astro maintenance retainer is the real answer to this page: it prevents the situation the page exists for. If you do not want a retainer, plan a fixed update window per major cycle instead – that is the minimum version, and for small static sites we will say plainly that it is enough.

A good moment to move editing to where your team already is

An upgrade touches the content model anyway. That makes it the cheapest possible moment for a question that otherwise never gets asked: is the path your content travels actually the right one? We do not only build with Astro – on request we put a modern AI stack on top, so you can maintain your website by chat, for example through a Telegram bot. Change a paragraph, add a blog post, swap an image, correct a price: as a message, not as a CMS session.

It works technically because Astro content sits in a typed, schema-validated model. Content collections describe a Zod schema per content type; Astro validates every file against it and derives the TypeScript types from it. That makes the content machine-addressable, and the schema doubles as the guard rail: an agent can only fill fields that exist, in formats that validate. A faulty edit fails the build, not the live page. Every change lands as a reviewable commit with a preview and a rollback – the same mechanics the upgrade itself relies on. If your content lives in a headless CMS, the same flow runs through its API instead.

The audience point matters to us: this works for an enterprise with an editorial team just as well as for a sole trader who will never open a CMS. If you can send a voice message, you can maintain your website. The evidence that chat agents are day-to-day work here rather than slideware is the WhatsApp AI agent we built for our own sales process and ran in real customer conversations.

And the limits, so this does not turn into a marketing promise: the chat path does not replace an editorial system for large teams with approval workflows – it supplements one. Editorial responsibility stays with you; an agent proposes and writes, it does not decide. Structural changes such as new page types, layout or navigation remain development work. The scope is defined per project: which collections, which fields, which approval level. One practical note specific to upgrade projects: while an upgrade branch is open, the agent keeps writing to the main branch – so your content still goes live and the branch picks it up on the next rebase. What that looks like day to day is on edit your website by chat.

07 — Decision

When an upgrade is worth it – and when we advise against it.

This page sells a service whose best answer is sometimes “not now” or “not at all”. Both columns are the filter we apply in the first call.

An upgrade is worth it when …

The site is staying, it carries business, and it should still be changeable in two years.

You are on Astro 5 or older and therefore no longer receive security fixes for the framework.
Your website carries revenue: lead forms, bookings, a shop connection, campaigns with budget behind them.
You plan to expand next year – new page types, another language, a careers section – and need current libraries to do it.
Routes render on the server, so adapter, runtime and environment variables have to be maintained regardless.
Your build no longer runs reliably – in which case the upgrade is not a nice-to-have but the repair of your ability to act.
You have an in-house team meant to develop the site further but blocked from using current integrations on an old line.

We advise against it when …

Then you get a recommendation from us rather than a quote – even when it argues against us.

The site is small, static and stable and will be replaced within a year anyway. Then the budget belongs to the successor, not to the old build. A short risk review and updates inside the existing major still make sense.
A relaunch has already been decided. Running two projects on the same codebase in parallel costs more than either one alone.
The project came from somebody else and nobody has looked inside yet. Then the audit comes first – and its result may be “rebuild”.
The code leans deeply on framework internals or builds on integrations nobody maintains. Where the rework reaches the size of a rebuild, we say so instead of hiding it in upgrade hours.
What you are building has outgrown a website – logins, roles, real-time data. Then the conversation is about custom software development, not about a version number.
Nobody in-house can deploy and no maintenance is planned either. Upgrading a site that nobody will maintain afterwards only postpones the problem by two majors.

08 — At a glance

At a glance: your version and what it means.

The short answer to the question most people arrive with: are we still inside the support window, and what follows from that?

Astro version status, support situation and recommendation – as of August 2026.
Where you are	What it means	What we recommend
Astro 7	The current major line. You are inside the support window; minor and patch updates are part of normal maintenance.	Nothing major. Apply updates continuously and schedule the next major cycle instead of waiting for it.
Astro 6	One major behind. Per the upgrade documentation, this is the one version still receiving extended maintenance with security fixes.	Plan now, do not panic now. A single jump is manageable – but the moment the next major ships, this line falls out of the window.
Astro 5	Two majors behind. Outside the window in which Astro provides security fixes.	Schedule the upgrade. Two jumps in sequence rather than in one leap, with a passing build between the steps.
Astro 4 or older	Several majors behind. Alongside the framework, integrations, adapter and runtime have usually aged out too.	Audit first, decide second. Upgrade and rebuild get costed against each other seriously here – not rhetorically.
Version unknown	The most common case. Without the number, neither risk nor effort can be quantified honestly.	Get a version verdict. Two minutes in package.json, or a short look from us – free of charge and with no obligation to buy.
No access to the repository	The bigger risk. Without access no security fix can be applied either, whatever the version says.	Access first. Reconstruct repository, hosting, domain, DNS and CMS – that comes before any version discussion.
Relaunch planned within twelve months	An upgrade would stabilise a codebase that is going away in the foreseeable future.	Usually do not upgrade. Apply security-relevant updates inside the existing major and put the budget into the successor.
Our take	The version number is rarely the real problem. The real problem is that nobody knows it – and that maintenance was planned as optional while Astro shipped two major versions inside a single year.	Verdict first, decision second. We would never sell an upgrade without having looked inside – and in a fair share of these conversations our honest answer turns out to be “later” or “rebuild instead”. That answer costs us a quote and costs you nothing.

09 — FAQ

Astro upgrade: frequently asked questions.

First the questions that actually get asked in the buying committee – then the short ones.

We do not know which Astro version our site runs on. How do we find out?

The root of your repository contains a package.json. Under dependencies there is an astro entry, and its first number is the major version. As a cross-check, your package manager's lockfile shows what was actually installed last. If nobody in the company can reach the repository, that is the real finding – and it matters more than the number itself, because without access no security fix can be applied either. Send us the URL in that case and we will look for you.

Our site has run stably for two years. Why touch it at all?

“Running” and “being maintained” are two different things. Astro follows semantic versioning and, per its upgrade documentation, ships security fixes for exactly one previous major version. The current line is Astro 7, which puts Astro 5 and older outside it. There is a practical side too: if you want to change something in a year, the jump will be bigger then than it is today. If your site is small, static and due to be replaced soon, we will tell you plainly to save the money.

We have missed two major versions. Is a rebuild not more honest than an upgrade?

Sometimes yes, and we cost it out rather than assert it. Four things decide the comparison: how many integrations are still maintained, how deeply your own code leans on framework internals, whether the build runs reproducibly today, and how large the route inventory is. Two jumps on a well-kept project are usually far cheaper than a rebuild. Three jumps on a codebase with orphaned integrations regularly tip the maths – and then we recommend the rebuild.

Will there be a feature freeze during the upgrade? Marketing has a campaign planned.

Usually not. The upgrade runs in its own branch; your website stays unchanged until the switch, and content, corrections and new landing pages keep going live the usual way. The upgrade branch is rebased at short intervals. One caveat, honestly stated: if your team wants to restructure the content model or add new page types in the same window, we agree a sequence for it. That costs days, not quarters.

What happens if the upgrade goes wrong? How do we get back?

Every step exists as a commit, and the switch runs through the regular deployment pipeline. The way back is a revert plus a deployment of the previous state – one move. More importantly, it rarely gets that far: the preview environment shows the new state in full before anything is switched, and you click through it yourself. The rollback path is written down before anyone touches production.

Our website has several hundred pages. How do you verify nothing broke?

Not by looking at it. Before the upgrade we build a route inventory from the sitemap, the build output and analytics – including dynamic routes, pagination, feeds and language variants. Afterwards both states are built and compared: does every route exist, are titles, meta tags, canonical URLs and structured data intact, do images and islands behave as before? Because static HTML is the default output, that is a comparison of two build results rather than a matter of taste.

Our agency is unreachable. Will you upgrade code somebody else wrote?

Yes – after an audit. We look at the repository, the Astro version, the rendering mode, the adapter, content collections, integrations and the build, and we produce a written verdict. It has three possible outcomes: upgrade as is, stabilise first and then upgrade, or rebuild. If we cannot stand behind the code, we decline. The process for that is described under Astro support and maintenance.

We render routes on the server on Cloudflare. What changes about the adapter?

On-demand rendering in Astro requires an adapter for the target runtime; the first-party options include Node, Vercel and Cloudflare. During a major jump the adapter is lifted together with the framework, and the runtime environment is tested on the target platform rather than only locally – that is precisely where differences appear that stay invisible in dev mode. Environment variables, caching rules and redirects belong to that step. Purely static projects are considerably simpler here.

We have React and Svelte components on the same page. Does that break?

Astro is UI-framework agnostic and multiple frameworks may coexist on a page. During an upgrade the relevant question is not the coexistence but whether each individual integration supports the target major. That is why the check sits right at the front: an integration that cannot come along would otherwise block the entire upgrade. Then there are three paths – replace it, rebuild the island, or take over maintaining it. We make that decision with you before the jump, not in the middle of it.

Our content lives in a headless CMS. Does the upgrade affect our editors?

Day to day, normally nothing changes – the CMS stays the CMS. Technically, though, your system's SDK is pulled along, and the queries Astro uses to fetch content are verified against the new state. While the upgrade branch is open your editors keep publishing as usual. The one thing we recommend is not to restructure field definitions in the CMS during that window, because it would overlap with the upgrade.

What does an Astro upgrade cost?

A number without a verdict would be a guess, so there is none here. The effort hangs on six things: the number of skipped major versions, the count and health of your UI integrations, whether routes render on demand and therefore bring an adapter along, the size of the route inventory as verification surface, the depth of the content model, and the state of your pipeline. After the first call you get a defensible estimate with its assumptions written out. For context: Astro development cost.

How long does an Astro upgrade take?

As a planning range: a well-maintained, purely static project with few integrations and exactly one major behind sits in the range of a few days. Two majors behind with several integrations, a CMS connection and on-demand rendered routes is closer to two to four weeks. Three or more majors with orphaned integrations and a build that does not run today: four to eight weeks – and there the rebuild question belongs on the table. These are planning figures from experience, not a commitment.

Will we lose rankings during an upgrade?

A major upgrade is not a migration: URLs, content and structure stay, the substructure changes. Even so we check exactly the places where a changed default can quietly move something – titles, meta tags, canonical URLs, hreflang, structured data, sitemap and redirects, each diffed between the old and the new build. Afterwards we watch Search Console and field data through the first weeks. We give no absolute guarantees on this; we show you what we verify.

Can we do the upgrade ourselves and just have you review it?

Yes, and it is a sensible format if you have your own team. The usual shape is a combination: we deliver the version verdict, the route inventory and the verification list, your team performs the jump, and we go through the pull request and the build comparison. Often we also take on the places that snag – the adapter, the content model, or an integration that will not come along. For teams who intend to run Astro themselves afterwards, this is usually the cheapest variant.

We do not want to end up here again. How do we prevent that?

By making upgrades stop being projects. In practice: small updates continuously, a fixed window per major cycle, a build that runs reproducibly in the pipeline, and one person who owns it. At a cadence of two major versions inside one year, an annual date no longer reliably suffices. That is what the ongoing maintenance is for – and for small static sites we will say plainly that a planned update window is enough.

Our CTO asks: two major versions in one year – is Astro unstable?

A fast major cadence is not the same as instability. Astro follows semantic versioning: breaking changes land explicitly in major versions and ship with upgrade guidance, instead of appearing unannounced in a minor. That makes planning possible, but it also requires that somebody plans. Teams without a process for major jumps experience the cadence as a burden; teams with one get predictable, documented change windows. The fundamentals are covered under what is Astro.

What is the current Astro version?

The current major line is Astro 7. Astro 7.0 was released on 22 June 2026 and Astro 7.2 on 6 August 2026. The line before it, Astro 6.0, went stable on 10 March 2026. We deliberately do not name a current patch version here, because it changes constantly.

How long does Astro support older versions?

Astro follows semantic versioning and, per its upgrade documentation, offers extended maintenance – security fixes only – for exactly one previous major version. With Astro 7 as the current line that means Astro 6 still receives security fixes, and Astro 5 and older do not.

Can you skip Astro major versions?

Technically yes, economically rarely. Each major carries its own breaking changes and its own upgrade path. We therefore jump one major at a time and require the project to build between the steps, so it stays traceable which jump caused which change.

Is an Astro upgrade free?

Astro itself is MIT-licensed, so there are no licence costs. What you pay for is the work: the verdict, the jump, adjustments to integrations and the adapter, regression testing and the switch. On a well-maintained project one major behind, that is a modest item.

Does an Astro upgrade need downtime?

Normally not. The new state is built and verified in a preview environment, and the switch runs through the regular deployment pipeline. Downtime does not come from the upgrade itself but at most from parallel changes to hosting, runtime or DNS – and those we schedule separately.

10 — Cluster

More from the Astro cluster.

Every page answers exactly one question – services, migrations, comparisons and fundamentals:

11 — Go deeper

Astro upgrade: from Astro 5 or 6 to the current major line.