Astro support and maintenance for websites that are actually in production.
Astro support and maintenance for sites in production: Astro ships majors quickly and maintains only one previous version. We keep your project inside that window, maintain dependencies and adapters – including on projects somebody else built.
Two majors in one year
Astro 6.0 in March 2026, Astro 7.0 in June 2026, Astro 7.2 in August 2026. Skipping updates puts you behind faster than any roadmap suggests.
One major of safety net
Extended maintenance with security fixes exists for exactly one previous major version. That makes maintenance predictable – not optional.
Takeover only after an audit
We look at inherited Astro code before we commit. You get an honest verdict, and we decline when a rebuild is the more defensible answer.
See for yourself what we build.
Real screenshots instead of promises: Mini Marvin is our own progressive web app – conceived, built and run live in the browser by us. We bring the same care to your web project.
Swipe baby names instead of scrolling
Mini Marvin is our progressive web app for finding baby names: swipe through 10,000+ first names – right in the browser, no app store needed.
Got a project in mind?
Describe it in three sentences – you get an honest first assessment, usually within 24 hours.
Why Astro maintenance is a real topic
- Astro 6.0 went stable on 10 March 2026, Astro 7.0 followed on 22 June 2026 and Astro 7.2 on 6 August 2026 – two major versions inside a single year.
The security window is narrow
- Astro's upgrade documentation states that extended, security-only maintenance covers exactly one previous major version.
- Two majors behind means no security patches at all.
What an Astro maintenance retainer covers
- Framework and dependency updates, adapter care for your runtime, content-model changes as the site grows, and new features without a full rebuild.
Inherited projects welcome
- We take over Astro websites built by another agency or freelancer – after an audit of the repository, and with the right to say no.
No lock-in
- The repository, hosting account, CMS and documentation are yours.
- If you leave, you take everything with you.
- Astro itself is MIT-licensed.
Prefer to talk it through?
A short call clarifies scope, effort and whether we are a fit.
What breaks when nobody maintains an Astro site.
Astro sites rarely fail spectacularly. They age quietly – and become a problem the moment somebody wants to change something.
Security support runs out
Astro follows semantic versioning, and extended maintenance with security fixes is granted to exactly one previous major version. Skip one major jump and then the next, and you are running a website that no longer receives security patches. That is not a hunch – it is written into the upgrade documentation.
A small update turns into a project
A major upgrade that waits a year is no longer an afternoon of work. Framework, build toolchain, UI integrations, adapter and CMS SDKs all arrive at once – and every breaking change lands on code nobody has touched for months.
The adapter no longer matches the runtime
On-demand rendering in Astro requires an adapter for the target runtime, such as @astrojs/node, @astrojs/vercel or @astrojs/cloudflare. Node versions reach end of life, hosting platforms change their runtimes. Without maintenance, it is not the website that breaks first – it is the build, usually at the worst possible moment.
The content model outgrows its schema
Content collections validate every entry against a Zod schema. The moment editorial or marketing needs a field that does not exist, workarounds start appearing inside body copy – or the build simply fails. Both are maintenance topics, not bugs.
Interactive islands drift apart
Astro is UI-framework agnostic: React, Preact, Svelte, Vue, SolidJS and Alpine.js can live side by side as islands. Each integration has its own release cadence. Left alone, they drift far enough apart that one update blocks the whole bundle.
Nobody remembers how to deploy
The most common gap is not code, it is knowledge: where the pipeline runs, which environment variables exist, who holds access to the CMS and the domain. Once the original agency is gone, reconstructing that often costs more than a year of planned maintenance.
Unsure about the stack?
We will tell you when another tool fits your project better.
What Astro website maintenance covers.
Maintenance here is not a bucket of hours that expires at month end. It is a defined scope – plus a roadmap for everything beyond it.
- Astro version and upgrade path – We keep your project on the current Astro 7 line, or document with reasons why an upgrade is waiting. Major jumps are planned, tested in a branch and only then shipped – never straight to production on a Friday afternoon.
- Dependencies and integrations – Build toolchain, UI integrations for React, Svelte or Vue, the Markdown and MDX pipeline, CMS SDKs: updates bundled, verified and shipped with a passing build – not auto-merged and hoped for.
- Adapter, hosting and deployment – When routes render on demand, we maintain the adapter for your runtime too – Node, Vercel or Cloudflare – including build pipeline, environment variables, caching rules and redirects.
- A content model that grows with you – New fields, new collections, a cleanly extended Zod schema and updated getCollection() queries. That keeps the editorial workflow usable as the site grows instead of suffocating in its own schema.
- New features without a rebuild – An extra landing page, a careers section, a calculator as an interactive island, personalised elements via server islands: Astro lets you extend in steps. A relaunch is rarely the cheapest answer to a new requirement.
- Measurement instead of claims – We measure your site in production – at deploy time and in the field data of real users – and derive work from that, rather than quoting somebody else's benchmarks. More on the Astro performance optimization page.
- Honest limits – A five-page brochure site with no on-demand rendering does not need a monthly contract. One planned update window a year is enough. We tell you that before you get an invoice for it.
Version status
Your project stays inside the window Astro still patches: exactly one major version of buffer, because that is all the framework offers.
Access
We work inside your repository and your accounts. No agency-owned accounts, no credentials only we know.
One named contact
You message a person who knows your project – not a ticket queue that has to relearn it every time.
Got a project in mind?
Describe it in three sentences – you get an honest first assessment, usually within 24 hours.
Taking over an Astro project somebody else built.
The most common reason people contact us is not a new project but an existing one: the agency is gone, the freelancer unreachable, the repository just sitting there. Here is how we proceed – and yes, step three can end in a no.
Access and inventory
Repository, hosting, domain, DNS, CMS, analytics: we list what exists and who has access to what. Surprisingly often this is the first time anyone sees that list in full.
Audit of the codebase
Astro version, rendering mode, adapter, content collections and their schemas, UI integrations, build time, dependencies with known advisories, the ratio of prerendered to on-demand routes. Plus a look at structure and readability – not at taste.
Verdict and honest recommendation
You receive a written verdict with three possible answers: take it over as is, take it over after a stabilisation phase, or rebuild. If a project is not sound, we decline. A maintenance contract covering code we cannot stand behind helps nobody.
Stabilisation
Before ongoing care starts: bring Astro and its dependencies to a defined state, make the build reproducible, document environment variables, and make deployment traceable from a branch.
Operations handover
From here the retainer runs: planned update windows, one fixed channel for requests, changes shipped through pull requests with a preview environment instead of straight to production.
Roadmap instead of a ticket pile
Every quarter we sort what actually moves the website forward: new content, new features, technical debt. That is the part pure maintenance contracts usually skip. Where several vendors are involved, we can also take on IT project management.
Prefer to talk it through?
A short call clarifies scope, effort and whether we are a fit.
When an Astro maintenance retainer pays off – and when it does not.
Not every Astro website justifies a monthly invoice. So this page sells you the other side too.
A retainer makes sense when …
Your website is part of operations, not just a digital brochure.
- Routes render on demand, so an adapter, a runtime and environment variables need ongoing care.
- Editorial or marketing publish regularly and the content model has to grow with them.
- Downtime costs revenue: shop, lead generation, bookings, appointment funnels.
- A CMS, a CRM or a payment provider is connected and their SDKs follow their own release cadence.
- You plan new sections, campaign pages or languages every few months.
- You have no in-house development team that reliably schedules major upgrades.
You do not need a retainer when …
Then an update window on request is enough – and we say so even when it argues against us.
- Your site is a small, fully static brochure website with no on-demand rendering: one planned update window a year usually covers it.
- Content barely changes and no external systems are connected.
- You have an in-house team that already runs Astro in its stack – targeted support beats a contract there.
- A relaunch is due within months anyway: then the budget belongs in the new build, not in maintaining the old one.
- You only need a single change. That is an order, not a subscription.
- Your requirements have long outgrown a website – then the conversation is about custom software development instead.
Your Astro site is live – but nobody is maintaining it?
Send us the URL and, if possible, a look into the repository. You get an assessment of the version status, the risk and the realistic effort – before anyone talks about a contract.
Response times, turnaround times – and how long an audit takes.
Prices are not on this page. Times are. Maintenance is bought on times rather than on scope descriptions: when does somebody respond, when is it fixed, how long until you even know where you stand. The ranges below are our honest expectation for the way of working described above – counted in working days, with no shift rota behind them.
Four occasions cover almost everything that actually happens inside a retainer:
- Production incident: response the same working day, usually within a few hours. Site unreachable, build failing, forms not arriving. Response means somebody looks at it and tells you what is going on. How fast it is fixed depends on the cause – a failed deploy is rolled back in minutes, an outage at your hosting provider is not in our hands, and a fault inside a third-party integration takes as long as that vendor takes.
- Change request from day-to-day work: reply within two working days, delivery usually within a week. An extra field in the Zod schema, another landing page, a block of copy, a redirect. Small items ship with the next regular deploy. Anything that needs a new page type gets estimated before work starts, not invoiced after it.
- Planned update window: half a day to a full working day, monthly or quarterly. Minor and patch updates for Astro, the build toolchain, UI integrations and CMS SDKs – bundled, built in a branch, reviewed on a preview, then shipped. The cadence is set by how many third-party systems are connected, not by the number of pages.
- Major upgrade: one to three working days on a contained project, one to two weeks with many integrations. Astro follows semantic versioning and ships majors at a fast pace, and security fixes cover exactly one previous major version. That makes this a recurring appointment rather than a special project. The detailed sequence is on the Astro upgrade page.
Then the two windows people always ask about first when handing over an inherited project. An audit of an inherited Astro repository takes three to five working days from the moment access is granted, as long as the site is fully prerendered and reasonably contained – and one to two weeks once routes render on demand, several collections and a CMS are involved, or the build is not reproducible. You get a written verdict, not a verbal impression. The stabilisation that follows – a defined version state, a reproducible build, documented environment variables – runs one to three weeks, depending on how far behind the project has fallen.
What we do not offer and therefore do not sell: round-the-clock on-call. We are a small team, and the times above apply on working days. If your operation genuinely needs 24/7 cover with a rota, that is a legitimate requirement – just not ours. It belongs in the hosting contract or with a provider who staffs shifts, and we tell you that before you sign rather than after. Fixed response and restoration times go into the agreement on request; whatever is written there is binding.
The reason maintenance dates actually slip is never the technology. It is missing access, an approval for the update window still sitting with somebody, or content for a new page that does not exist yet. When access is in place and feedback comes back within a few working days, the ranges above hold. Where several vendors are involved – host, CMS provider, agency – we can take on project management and coordinate it. What the scope costs is something we say after the inventory; the drivers are listed individually under Astro development cost.
What pulls the range down
A fully prerendered site with no adapter. Few connected third-party systems. A repository with a reproducible build and documented environment variables. And one person on your side who is allowed to approve an update window.
What pushes it up
Routes rendering on demand with an adapter and its own runtime. Several UI integrations side by side. CMS, CRM or payment SDKs with their own release cadence. Every further language. And a version state that is already two majors behind.
The usual reason for delay
Access and approvals, not code. An upgrade that has been waiting three weeks in a branch for sign-off is not a technical problem. We name the open item early instead of waiting quietly.
Unsure about the stack?
We will tell you when another tool fits your project better.
Astro maintenance at a glance.
Eight criteria that genuinely come up in vendor selection and procurement: answered short, each with its caveat beside it. The last row is our opinion, not a summary.
| Criterion | How it looks on Astro | The caveat |
|---|---|---|
| Why maintenance is needed | Astro follows semantic versioning and shipped two major versions during 2026. Extended maintenance with security fixes covers exactly one previous major version – the window is narrow, but predictable. | An expired window does not switch anything off. Your site keeps running; it simply stops receiving security patches. The pressure is real but rarely acute. That justifies planning, not panic. |
| What baseline care covers | Astro and dependency updates, adapter and deployment, extensions to the Zod schema behind content collections, small fixes, response to monitoring alerts, and a written status. | New page types, design work, editorial content, migrations and an accessibility review are commissioned work, not baseline care. Which of the two a request falls into is something we say up front – not on the invoice. |
| Response and turnaround | Incident: response the same working day. Change request: reply within two working days, delivery usually within a week. Planned update window: half a day to a full working day, monthly or quarterly. | Working days only, no shift rota, no round-the-clock on-call. If your operation needs 24/7, that belongs in the hosting contract or with a provider who staffs a rota – not with us. |
| Escalation during an outage | Roll back to the last working build, then find the cause in a branch, then ship a verified deploy. Changes always go through pull requests with a preview environment instead of straight to production. | A rollback is only as good as the pipeline. On inherited projects without a reproducible build, that is the first item of stabilisation – and until it is done, we do not commit to it. |
| Contract and notice period | Our standard proposal: monthly billing, four weeks notice to the end of the month, no minimum term. Fixed response times go into the agreement as binding commitments on request. | A retainer is not a condition – maintenance also works as individual orders. Without an agreement there is no committed response time either. The cost range comes after the inventory; the drivers are under Astro development cost. |
| Taking over inherited projects | After an audit of three to five working days, or one to two weeks with on-demand routes and a connected CMS. You receive a written verdict with three possible answers. | One of those three answers is no. We do not take responsibility for code we cannot stand behind. And the audit is a paid engagement – including when no contract follows it. |
| Security and access | A prerendered Astro site has no database, no admin login and no plugin ecosystem in the delivery path. We work with mandatory two-factor authentication, least privilege, and access inside your own accounts. | The attack surface does not disappear, it moves: npm dependencies, repository and pipeline permissions, form and API endpoints, the CMS as a system of its own. That is precisely the part that has to be maintained. |
| Exit and handover | Repository, hosting, domain, CMS and documentation are in your name from day one. We close with a handover covering version state, open items and the deployment process. | A handover is work, not a button. Requesting it on the day you cancel means waiting a few working days for it. We would rather plan it in as its own small package. |
| Our take | A retainer pays off as soon as routes render on demand or a third-party system is connected. That is where movement is constant and somebody has to keep up, and where unplanned maintenance quickly costs more than planned maintenance. For a purely prerendered site with no integrations, one update window a year is enough – and we say so even when it argues against us. | We advise against it when you need genuine round-the-clock cover – then we are the wrong team – or when a relaunch is already decided. In that case the budget belongs in the new build rather than in maintaining the old one. And if nobody on your side ever wants to touch a repository, Webflow is the more honest suggestion. |
Got a project in mind?
Describe it in three sentences – you get an honest first assessment, usually within 24 hours.
Frequently asked questions about Astro support and maintenance.
The questions that come up in real conversations – from the basics to what procurement and IT security want to know before anyone signs.
How often does an Astro website need to be updated?
Astro follows semantic versioning and ships major versions at a fast pace: Astro 6.0 went stable in March 2026, Astro 7.0 in June 2026, Astro 7.2 in August 2026. Security fixes cover exactly one previous major version. In practice that means minor updates continuously and one planned major upgrade per cycle – so you never end up two majors behind and outside the patch window.
What does Astro maintenance cost per month?
It depends on scope. A static marketing site with occasional content sits well below a site with on-demand rendering, a connected CMS and continuous development. We only quote after the inventory, and we put the range in writing, split into baseline care and further development. For project-level figures, see our page on Astro development cost.
Do you take over Astro projects built by another agency?
Yes – after an audit. We review the repository, Astro version, adapter, content collections, integrations and build, and hand you a written verdict. If we conclude the codebase is not sound, we decline or recommend a rebuild. We do not take responsibility for code we cannot stand behind; that would be a bad deal for both sides.
What happens if we want to leave?
You keep everything. Repository, hosting account, domain, CMS and documentation are in your name from day one, and we work with access you can revoke at any time. We close with a handover covering the current version status, open items and the deployment process. Astro itself is MIT-licensed, so the framework creates no dependency on us.
Will a major upgrade break our website?
A major jump can contain breaking changes – that is exactly what semantic versioning signals. So an upgrade never happens directly in production: first in a branch, following the documented upgrade notes, with a build and link check and a preview you click through yourself. Only then does it go live. This is precisely why maintenance should be planned rather than reactive.
Can we still edit content ourselves under a retainer?
Yes, that is the normal case. Content lives either in content collections inside the repository or in a connected headless CMS – in both cases your team edits without us. We step in when the model itself has to change: new fields, new collections, new page types. For what that looks like day to day, see editing your website by chat.
Is maintenance possible without an ongoing contract?
Yes. A retainer is not a condition here. Some projects only need one update window a year, and then that is exactly what you commission. We say openly when a monthly contract makes no sense for your site – a small static website is rarely a retainer case. The reverse also holds: once on-demand rendering, a CMS and integrations are involved, ad-hoc maintenance quickly costs more than planned maintenance.
How fast do you respond when our site is down on a Monday morning?
On working days the same day, and in practice usually within a few hours: somebody looks at it and tells you what is going on. How fast it is fixed depends on the cause – a failed deploy is rolled back in minutes, an outage at your hosting provider is not in our hands. What we do not offer is round-the-clock on-call. If you need genuine 24/7 cover, it belongs in the hosting contract, and we say that before you sign.
What exactly is inside baseline care, and what do you bill separately?
Included: updates for Astro, the build toolchain, UI integrations and CMS SDKs, care of the adapter, pipeline and environment variables, small fixes, response to monitoring alerts, and a written status. Not included, and therefore a separate commission: new page types, design work, editorial content, migrations, campaign funnels and an accessibility review. Which of the two categories a request falls into is something we say up front – not on the invoice.
A deploy took the site down. How does escalation work?
In this order: roll back to the last working build, then find the cause in a branch, then ship a new deploy with checks. That is exactly why changes go through pull requests with a preview environment instead of straight to production. You reach a named person who knows your project, not a queue. The honest caveat: a rollback is only as good as the pipeline. On inherited projects without a reproducible build, that is the first item of stabilisation.
What happens if you are unavailable for a longer period?
We are a small team, that is a real risk, and we treat it as one. Everything runs inside your accounts: repository, hosting, domain, CMS. The repository carries documentation for the build, deployment, environment variables and content model, and the build is reproducible. Astro is MIT-licensed, so no component is tied to us. Any team that works with JavaScript and Git can pick it up. A switch stays unpleasant – but it is not a rebuild.
What term and notice period does the maintenance agreement have?
Our standard proposal is monthly billing with four weeks notice to the end of the month and no minimum term. If your procurement needs a fixed term, different notice periods or committed response and restoration times, we negotiate that in writing – and then it is binding. We keep the notice period deliberately short: a maintenance agreement should justify itself every month. Anyone who stays because leaving is expensive is not a satisfied client.
Who is liable if something breaks after an update?
We are – for what we changed. Anything that stops working as agreed after an update we shipped, we restore under the statutory warranty without a new invoice. Separate from that are faults originating in a third-party system – hosting provider, CMS, payment service – and change requests, which are not defects. Which category a report falls into is something we say before we start. Further liability arrangements belong in the agreement, not on a website.
Our IT security team asks about the attack surface and about your access rights. What do we tell them?
That a prerendered Astro site has no database, no admin login and no plugin ecosystem in the delivery path – the usual route through a vulnerable extension simply does not exist there. What remains, and therefore gets maintained: npm dependencies, repository and pipeline permissions, form and API endpoints, a headless CMS as a system of its own with its own login, plus domain and hosting accounts. We work with mandatory two-factor authentication, least privilege, and access inside your accounts that you can revoke at any time. Where secrets live is documented.
How do you handle GDPR, hosting location and subprocessors in day-to-day operation?
Astro itself processes no personal data – the question is decided by hosting, forms, analytics and CMS. A static build can run with a provider in Germany or the EU; we self-host fonts rather than pulling them from third-party servers, and analytics comes in cookie-free variants. We name every service provider we use so your data protection officer can put the processing agreements in place, and we flag changes to that list. We do not give legal advice. More on our GDPR-compliant websites page.
Do you use AI tooling in maintenance? What does that mean for our code and data?
Yes, and we would rather say so than hide it. AI-assisted tools speed up routine work such as dependency updates, migration steps and test cases; a human stays accountable. Every change goes through review, type checking and a build in continuous integration before it ships. Credentials, personal customer data and confidential documents do not go into such tools – that is a rule here, not a judgement call. If your policy restricts or forbids their use, we follow it and write it into the contract.
Can we take maintenance in-house later, or hand it to another agency?
Yes, the setup is built for that. You get the repository with its full history, documented build and deployment steps, an overview of environment variables and a handover with open items. On the worry behind the question: Astro components are HTML, CSS and TypeScript, and interactive islands are written in React, Preact, Svelte, Vue, SolidJS or Alpine.js. So you hire from the general JavaScript market, not from an Astro market. There are still fewer CVs with "Astro" on them – plan for a short ramp-up.
You have no public Astro reference. Why should we trust you with a live website?
Because we would rather say that than invent one: we have no publicly showable Astro client project yet. What we do have is a Webflow reference we built and maintain, our own products in production, and years of software development with repositories, continuous integration and deployment. Operations is the larger part of this work; the framework is the smaller one. Testing us is cheap: the audit is a finished engagement, not a contract – and the verdict stays with you even if you hire somebody else afterwards.
Is Astro free?
Yes. Astro is open-source software under the MIT licence; there is no licence fee for the framework itself. Costs arise in implementation, hosting, operation and – if you use one – the headless CMS. The drivers are listed individually under Astro development cost.
How long does an Astro version receive security updates?
Astro follows semantic versioning. According to the upgrade documentation, extended, security-only maintenance covers exactly one previous major version. Two majors behind means a website with no security patches at all – which is why a planned upgrade window is the cheapest part of any maintenance.
Does an Astro website need a server?
Not necessarily. By default the entire site is prerendered and served as static HTML, which runs on any CDN or static host. Only when individual routes need to render at request time does an adapter for the target runtime come in, for example for Node, Vercel or Cloudflare. More on the Astro hosting page.
Can you use React components in Astro?
Yes. Official integrations exist for React, Preact, Svelte, Vue, SolidJS and Alpine.js, and several of them may appear on the same page – though only inside an .astro file. For maintenance that means each of those integrations has its own release cadence and gets updated in the update window.
Maintenance that does not start with an outage.
Tell us where your Astro website stands: version, hosting, who built it. You get an honest assessment of whether ongoing care makes sense and at what scope. Usually within 24 hours.
Request Astro maintenance.
Briefly describe what you need – ongoing care, takeover of an existing project, or a single update window. We will come back with an assessment.
We usually reply within 24 hours.
Remote & on site – working across the DACH region (DE, AT, CH), with international project experience.
Related pages.
Astro Agency
The overview: how we build with Astro, what the stack does well and where its limits are.
Learn moreAstro Web Development
A new build instead of a takeover: concept, implementation and launch of an Astro site.
Learn moreAstro Performance Optimization
Existing Astro site feeling slow? Measure, find causes, fix them specifically.
Learn moreAstro Migration
Moving from WordPress, Webflow, Framer or Next.js – with a redirect concept.
Learn moreWhat Is Astro?
Islands, server-first rendering, content collections: the basics without marketing fog.
Learn moreWebflow Agency
The sister service – when a visual platform fits your team better.
Learn more