Astro Hosting: Running Costs, EU Servers & Exit

01 — In short

Astro hosting in seven sentences.

In short

The short answer: a statically served Astro site is cheap to run. For many marketing sites a free or very inexpensive tier on a static host or CDN is enough. That is the normal case, not the exception.
Why: static prerendering is the Astro default output. At request time there is no database query and no application server assembling a page – there are files, and a CDN serves them.
What actually moves the cost: not the provider, but how much of your site renders on demand. On-demand rendering needs an adapter for the target runtime and produces function invocations. It is an architecture decision, made early.
Where money really goes: bandwidth on image-heavy sites, build minutes on large content sets, the CMS subscription as the biggest recurring line in most projects – and edge or function invocations when server rendering is used broadly.
EU hosting is the real requirement for many European buyers, and it is entirely feasible: the hosting location is a provider choice, not a property of the framework. More under GDPR-compliant websites.
Self-hosting is legitimate. Astro is MIT-licensed and the build output runs on any web server – including one inside your own data centre, behind your own firewall, run by your own operations team.
We do not print prices here, because provider tiers change constantly and a number from today is wrong in a quarter. You get a defensible estimate for your case; build cost lives under Astro development cost.

02 — Why it is cheap

Why running an Astro site costs so little.

Running cost comes from work performed at the moment someone requests a page. On a prerendered Astro site, almost no work happens at that moment – it happened once, at build time, for every visitor at once. That is the whole trick. It is not new, it is simply the default here instead of an optimisation someone has to remember.

No application server in the path – By default the entire Astro site is prerendered and served as static HTML. Nothing assembles a page per request, and no database is queried to do it. What a visitor asks for already exists as a file.
Delivery instead of computation – Static files are exactly what content delivery networks are built for: cache and serve. That is why the base load of an Astro site sits in the cheapest part of most price lists – the provider is doing the least expensive thing it can do.
Images are processed at build time – Astro ships image handling: the image components set loading behaviour, infer dimensions to avoid layout shift, and can emit several formats and sizes. With static output that conversion happens during the build – not on every request, and not inside a metered image transformation service.
Interactivity only costs where it happens – Astro strips all client-side JavaScript from components by default; a component becomes an island only through an explicit directive, and then hydrates immediately, on browser idle, or when it scrolls into view. Fewer shipped bytes means less bandwidth – and bandwidth is one of the few lines that grows with your success.
Server islands keep the shell cacheable – When one area genuinely has to be dynamic – a cart counter, a personalised block – a server island renders exactly that part separately while the page shell stays aggressively cached. That is the difference between a dynamic spot and a dynamic site, and on an invoice the difference is large.
Less surface to maintain – A statically served site has no public admin interface and no runtime extensions working in the background. That does not remove maintenance – dependencies and major upgrades remain real work, see support and maintenance – but it moves that work out of operations and into development, where it can be scheduled.

What "static" means here

Static describes delivery, not your content. Your content changes as often as you like; after each change the pipeline rebuilds the affected pages and publishes them. What the visitor receives is a finished file.

What still runs alongside

Form handling, site search, analytics, newsletter, booking: these run next to the site, not inside it. Each has its own pricing model – which is why we list them separately in every quote.

What we are not

We are not a hosting company. We run no data centre and we do not resell a tier with a margin on top. We help you choose, we set it up and document it, and you hold the contract with the provider in your own name.

Build cost versus running cost

One-off cost for concept, design and implementation lives under Astro development cost. This page is only about what recurs afterwards.

03 — The decision

Prerender or render on demand – this is where the bill is decided.

"Which host is cheapest?" is the second question. The first one is: how much of your site has to be produced at request time? Astro supports both and mixes them per route – an explicit setting takes an individual page out of prerendering. That split determines your monthly invoice, and it is settled during architecture, not during a provider comparison.

Prerendering is enough when …

Every visitor sees essentially the same thing, and content changes on editorial cycles rather than by the second.

Your pages present content: services, case studies, blog, documentation, landing pages, careers, locations.
Content comes from Markdown or a CMS and a build may run after each change – seconds to minutes, depending on the size of the set.
Personalisation is limited to specific areas that can load as an island or render separately as a server island.
You expect traffic spikes – a press hit, a broadcast, a campaign. Static files from a CDN are the calmest way through a surge.
Your legal team wants less surface to review: no publicly reachable backend, no runtime extensions, a short list of data flows.
You want maximum portability. A directory of files runs anywhere – that is the difference between moving and rebuilding.

You need on-demand rendering when …

Then we build it – and we tell you in advance which part of the bill it creates.

Pages must differ per visitor: a logged-in area, prices per customer group, live availability.
You accept data rather than only serving it: form processing, a cart, search queries against a third-party service.
Your content set is too large or too volatile for a full build – millions of pages, or changes by the minute.
Content must go live instantly, with no build in between. That is a legitimate editorial requirement, not a failure of planning.
You run a storefront with stock levels and customer accounts – see Astro e-commerce.
Your product works that way for the most part. Then the honest question is whether Astro is still the right tool: Astro vs. Next.js.

04 — Cost lines

Where the cost actually accumulates.

Seven lines, ordered by how often they genuinely hurt. There are deliberately no numbers here: tiers, quotas and free allowances change regularly at every provider, and a printed figure would be misleading by next quarter. What does not change is the shape of the cost – and you can audit that yourself.

Bandwidth – The line that grows with your success. What matters is rarely the number of page views but the weight per view – and that is almost always images and video. One image-heavy gallery can outweigh the rest of the site combined. Remedies: modern formats and appropriate sizes from the built-in image handling, video hosted with a video service rather than in your own directory, and real thumbnails in listings instead of full-size originals.
Build minutes – Every change triggers a build. On a forty-page site that is a footnote. On tens of thousands of detail pages generated from a large content set it becomes a line item – especially if editors save forty times a day. Remedies: the built-in caching content collections provide for large sets, targeted rather than full rebuilds, and batched deploys at fixed times instead of one per comma.
The CMS subscription – In most projects the biggest recurring line – frequently a multiple of hosting, and usually metered per seat or per environment. Which is exactly why the system choice belongs in the architecture phase rather than at the end: whether your content lives in content collections in the repository or in a headless CMS is the most expensive decision on this page.
Function and edge invocations – As soon as routes render at request time, you pay per invocation and per compute time rather than per byte served. For a handful of dynamic spots that is noise. For a whole site rendered on demand without a reason, it is the line that turns a two-figure tier into a three-figure one. So we decide it route by route and write down why.
Services running alongside – Form handling, search, newsletter, bookings, consent management, error monitoring: each has its own pricing, and together they often exceed hosting itself. We list them individually in the quote – including the free ones, so that nobody is surprised by an invoice later.
Domains, certificates, mail and monitoring – The unglamorous base layer. Domain renewals, wildcard certificates where needed, mailboxes, an uptime check. Small amounts, but they belong in the statement, because otherwise they land in another department where nobody can attribute them.
Maintenance and upgrades – Not a hosting line, but an operating line – and the more honest yardstick. Astro follows semantic versioning, and security fixes are provided for exactly one previous major version. With two majors released inside a single year recently, we plan upgrades as a small recurring task rather than a project. How we run that is under Astro support & maintenance.

05 — Operating models

Four ways to run an Astro site.

All four are defensible and we implement all four. The choice follows your IT organisation, your data protection requirements and how much of the site renders at request time – not what currently sounds modern.

Static host or CDN

The normal case for marketing sites. The build output is published to a CDN and served from there; the pipeline redeploys after every content change. Cheap, calm under load, little to review. For most of the sites we build, the hosting conversation ends right here.

Web development

A platform with an adapter

When parts of the site must render at request time, an adapter for the target runtime comes in. Astro maintains first-party adapters under the @astrojs scope, including ones for Node, Vercel and Cloudflare. We pick for the runtime you already operate, not the other way round.

Integrations

Your own server, your own infrastructure

Astro is MIT-licensed and the build output is portable: static files on any web server, and for on-demand rendering a Node process via the Node adapter, typically in a container. For organisations with an operations team, their own data centre or strict internal policy, this is often the shortest route to sign-off.

IT project management

Hosting inside the EU

For many European buyers this is the actual requirement. The hosting location is a provider and contract question, not a property of the framework – Astro produces files, and you decide where they live. We document the data flows of the finished site so your data protection officer has something to review.

GDPR-compliant sites

06 — How we work

How we settle your hosting.

Timing first, so you can plan: for a new site, hosting setup is a matter of one to three working days. Moving an existing Astro site to a different provider typically takes two to five working days plus DNS lead time. Converting a site from broad server rendering to mostly static delivery is not a hosting task but an architecture one – budget one to four weeks for that. What pushes those ranges up: the number of routes that render at request time today; redirect chains inherited from earlier relaunches; certificates and domains managed elsewhere; DNS propagation windows; a procurement or approval track inside a larger organisation; and data protection reviews with processing agreements, which run on their own clock.

First assessment

We settle three things: how large the content set is, how often it changes, and what has to look different per visitor. Those three answers produce nearly the whole running-cost picture – long before any provider name is mentioned.

Render strategy per route

We walk through the page types and decide which are prerendered and which render at request time. The result is a list, not a doctrine. Every on-demand route gets a written reason; if we cannot think of one, it gets prerendered.

Location and provider

Only now do we talk about providers, and along your requirements: hosting location, data processing terms, existing framework agreements, whether your IT wants to operate it, which runtime already runs there. The contract sits directly between you and the provider, in your name and on your invoice.

Setup, pipeline and cutover

Repository, build pipeline, preview environment, certificates, redirects, security headers. The old site stays online until the new one is ready; the switch happens via DNS once staging is verified. On a move we lower the DNS time-to-live in advance so the cutover takes minutes rather than days.

Handover and measurement

You receive the credentials, the data flow documentation and a statement of every recurring cost, including the services running alongside the site. Then we measure load behaviour and Core Web Vitals inside your own project, on your real user data. What that involves is under performance optimisation.

07 — EU, self-hosting, exit

EU hosting, your own infrastructure, and the way back out.

Three questions that come up reliably in European procurement and that most agency sites stay quiet about. Here they are, in order – without legal advice, because that is not something we provide.

Hosting location is a decision, not a property of the framework

Astro produces files. Where those files sit and who serves them follows from your provider choice, not from the framework. If your policy says delivery and log data must not leave the EU, we select a provider with EU data centres and a contractual commitment to match; if your IT wants to run it, we deliver there instead. In both cases, check more than the server location: check where logs, metrics and backups end up. In practice that is where the story gets untidy.

Static delivery makes the data protection review shorter

A prerendered site presents little surface: no publicly reachable editing backend, no runtime extensions quietly pulling in third-party scripts. What remains is still real work – forms, analytics, fonts, embedded video and maps, consent management. We document the data flows of the finished site so your data protection officer has something concrete to review rather than an assurance. What else surfaces in that review is covered under GDPR-compliant websites. The legal assessment stays with you or your counsel: we build, we do not give legal advice.

Self-hosting is a legitimate path, not an emergency exit

Astro is free software under the MIT license, and the build output is portable. Static output means a directory any web server can serve – including the one your IT has been running for a decade. If parts of the site need to render at request time, that requires an adapter for the target runtime; on your own infrastructure that is usually the Node adapter, typically containerised behind your existing reverse proxy. What you then carry is exactly what you would otherwise be paying for: availability, certificates, operating system patching, backups, scaling under load. For an organisation with an operations team that is often cheaper and always faster to get approved. For a five-person company without one it is usually the more expensive option, even when the invoice shows a smaller number.

The exit is built in, not negotiated

Lock-in happens when your content sits in a proprietary format inside somebody else's interface and export is a concession. This setup works differently: the source code is in your repository, content sits beside it as Markdown or in a CMS with a documented API, and the build output is ordinary files. Changing provider is three moves – run the build, publish the output with the new provider, switch DNS. Changing agency is equally unremarkable: you hold the credentials, we document inside the repository, and whoever comes after us finds a project that builds with the standard commands. We consider that obvious and write it down anyway, because in this industry it is not.

What we explicitly do not provide

We are not a hosting company and we run no data centre. We do not resell a tier with a markup, and we do not offer around-the-clock on-call cover. If your operation needs a guaranteed availability commitment with penalties attached, that operation belongs with a specialist provider or inside your own IT, and we work alongside them. What we do provide: architecture, selection, setup, documentation, the deployment pipeline and ongoing care of the project. The provider invoice goes to you, not through us.

What stays yours

Repository, domains, provider accounts and credentials are in your name. That is not a matter of trust, it is the default state – and the reason a move stays technically boring.

When the setting is larger

Where internal IT, procurement, legacy systems and deadlines are involved, we can also take on IT project management and run the coordination with your operations team.

If you are coming from elsewhere

A move rarely concerns hosting alone. What actually happens during a platform change is under migration to Astro – including the cases where we advise against it.

No legal advice

We build in a privacy-friendly way and document the data flows. Assessing contracts, consent and legal notices remains with you or your legal counsel.

08 — The expensive line

The CMS subscription is the line most likely to disappear.

If hosting costs close to nothing, the editing software becomes the largest recurring amount. This is where we add a modern AI stack: vincubate does not only build with Astro, we also let you edit your website by chat – through a Telegram bot, for instance. Change a paragraph, add a blog post, swap an image, correct a price: as a message, not as a CMS session.

Content in the repository instead of a subscription – If your content lives in content collections, there is no monthly licence for an editing interface – the structure is part of the project. For teams that publish rarely but in a structured way, this is the cheapest way to operate a site at all.
Editing by chat instead of a CMS session – You send a message, the agent writes the change, you get a preview URL back and approve it. The full workflow is described under edit your website by chat.
Why this holds up technically – Astro content sits in a typed, schema-validated model: content collections with a Zod schema. An agent can only fill fields that exist, in formats that validate. A bad edit fails the build – not the live site.
Every change is a reviewable commit – History, before and after, rollback: all present, because the path runs through repository and deployment. That is incidentally the argument that carries weight in an approval process.
Enterprises and sole traders alike – An editorial team keeps its system and uses chat for the many small corrections that clog the approval queue. A trades business with no CMS login sends a photo and a voice note from the site. If you can send a voice message, you can maintain your website.
Evidence rather than a claim – Chat agents are day-to-day work here: we built a WhatsApp AI agent for our own sales, and ran it in real customer conversations – with escalation to a human and monitoring of the thread.

Limit 1: not a replacement for an editorial system

Where several people publish daily, translations run in parallel and approvals are multi-stage and documented, you need a headless CMS. Chat complements it rather than replacing it – and the subscription stays on the invoice.

Limit 2: editorial responsibility stays with you

An agent proposes and writes. It does not decide whether a statement is true or whether a price may be communicated that way. That is why the preview is the handover point, not decoration.

Limit 3: structure remains development work

New page types, additional fields, changed layout or navigation are changes to code and schema. They run as ordinary development work, inside the project or the maintenance arrangement.

Limit 4: not automatically cheaper

The chat route saves a subscription but costs setup. At four changes a year it pays for itself quickly; with an editorial team running a calendar and roles, the subscription is the better buy. We tell you which case is yours – and the scope is defined per project.

09 — Honest limits

When our answer is the wrong one.

This page sells a service that is fundamentally cheap. Which makes the right-hand column the important one: the cases where you do not need us for hosting, or where a different route is simply better. We would rather say it now than in week three of the project.

Talk to us when …

This is about the architecture of your running costs, not about selling you a tier.

You do not know why your current site costs what it costs to run, and nobody can break the invoice into lines.
Your bill grows with traffic although the content barely changes. That is almost always an image problem or a rendering problem.
You face a location or data protection decision and need a technical assessment before legal can answer.
You have an existing Astro site that renders far too much on demand, because nobody questioned it during setup.
You want to move – to another provider, onto your own infrastructure, or away from a platform that holds you in place.
You want build and operation from one team, with a maintenance arrangement rather than a handover into nothing.

You do not need us here when …

Four of these cost us revenue. They are here anyway, because they are true.

Your site runs and the invoice is small. Hosting is rarely where optimisation pays – look at the CMS subscription first.
Your IT runs its own platform that everything ships to. Then we hand over the build artefact and you deploy it, which is the shorter path.
You need guaranteed availability with penalties and around-the-clock on-call cover. We do not offer that; specialist operators do.
You are only looking for somebody to press deploy. A configured pipeline is something your team operates itself, and we show them how at handover.
What you are building is a logged-in application. Then this is not a hosting question but an architecture one: custom software development.
Your team wants to build pages visually, without a repository and deployments. Then our Webflow service is the more honest proposal – subscription included.

10 — At a glance

Astro hosting at a glance.

The shape of the cost, not the numbers. Numbers come for your specific case – this table is what lets you sanity-check a quote before you get one.

Item	How it behaves	What it moves
Base delivery	Static prerendering is the Astro default: the entire site is prerendered and served as static HTML. That runs on any static host and any CDN.	Very little. For many marketing sites the base load stays inside the cheapest or free tiers – which is why hosting is rarely the line worth discussing.
On-demand rendering	Enabled per route; requires an adapter for the target runtime. Astro maintains first-party adapters under the @astrojs scope, including ones for Node, Vercel and Cloudflare.	The biggest lever on the hosting bill. Billing shifts from bytes served to invocations and compute time. The more routes are dynamic, the steeper the curve.
Bandwidth	Grows with the weight per page view, not with the number of pages. Images and video account for practically the entire difference.	The line that scales with your success. Modern image formats, correct sizes, and video hosted with a video service keep it flat.
Build minutes	Every content change triggers a build. Content collections bring caching for large sets.	Irrelevant on small sites. On tens of thousands of detail pages with a high change rate it becomes real – manageable through targeted rebuilds and batched deploys.
CMS	Astro is CMS-agnostic: content comes from content collections in the repository or from a headless CMS with an API.	The largest recurring amount in most projects, frequently a multiple of hosting. Which is why the system choice belongs in the architecture phase.
Hosting location	Free choice of provider, including EU data centres or operation on your own infrastructure. Astro prescribes nothing.	Rarely a cost driver, often an approval driver. What matters is where logs, metrics and backups sit, not only where delivery happens.
Timeline	New setup one to three working days. Provider move two to five working days plus DNS lead time. Converting broad SSR to mostly static one to four weeks.	Pushed up by the number of dynamic routes, inherited redirect chains, externally managed domains and certificates, and internal approval or procurement tracks.
Exit	Astro is MIT-licensed, the build output is ordinary files, and the source code sits in your repository.	No platform lock-in. Changing provider means build, publish, switch DNS. Changing agency stays an unremarkable event for the same reason.
Our take	With Astro, hosting is almost never the problem – and therefore almost never the right place to save. If you want to cut running costs, first check how many routes render on demand without a reason, then look at the CMS subscription. In that order, not the other way round.	How we would do it: prerender as much as possible, go dynamic only where a written reason exists. Choose the provider on data protection and operational requirements rather than on tier – the gap between the cheap options is smaller than an hour spent arguing about it.

11 — FAQ

Astro hosting and running costs: frequent questions.

First the questions procurement and IT actually ask – then the short ones.

"Our board wants to know what the new site costs per month. What do we tell them?"

Tell them the hosting share is small and, on a statically served Astro site, often negligible. The monthly total is usually the CMS subscription, the services alongside it – forms, search, newsletter, monitoring – and an optional maintenance arrangement. We break those out individually in the quote, including the free ones, so nobody is surprised by a line item later. A flat figure without knowing your content set would be a guess, and a guess will not get you through an approval.

"We have several thousand images in our media library. Does bandwidth become a problem?"

This is the case where bandwidth genuinely can become the largest hosting line – but it depends on weight per view, not on the number of files. Astro ships image handling: the image components can emit several formats and sizes, set loading behaviour and infer dimensions. Listings then serve small thumbnails rather than originals. It also matters that images are not routed around processing, since files placed in the public directory are served untouched. Video belongs with a video service, not in your hosting plan.

"Our IT wants to run the hosting themselves. Is that possible, or is it an exotic path?"

It is not exotic, it is one of the four normal options. Astro is MIT-licensed and the build output is portable: with static output it is a directory any web server can serve. If part of the site must render at request time, that usually means the Node adapter, typically as a container behind your existing reverse proxy. We deliver the artefact and the pipeline, your IT operates it. In organisations with their own operations team this is often the fastest route through internal approval.

"Our legal department requires hosting inside the EU. Is that feasible with Astro?"

Yes, and without a technical compromise: hosting location is a provider and contract question, not a property of the framework. Astro produces files, and you decide where they live. During the review, look at where log data, metrics and backups sit as well as where delivery happens – that is where it gets untidy in practice. We document the data flows of the finished site for your data protection officer; the legal assessment stays with you. More under GDPR-compliant websites.

"We have tens of thousands of product and detail pages. Will builds take forever?"

On very large sets, build time is genuinely the point that needs thought. Content collections bring caching for thousands of entries, and we rebuild selectively rather than fully where possible. If the set changes by the minute or runs into the millions, the honest answer is: those routes render on demand, and the cost moves from build minutes to function invocations. Both are plannable – we cost out both variants before you decide.

"We need personalisation and a logged-in area. Do costs then explode?"

Not necessarily, if the separation is clean. The decisive difference is between a dynamic spot and a dynamic site: a personalised block can render separately as a server island while the page shell stays aggressively cached. It gets expensive when an entire site renders on demand without needing to. If most of your product sits behind the login, though, the question is not hosting but tooling – then we should be talking about a custom web application.

"What happens if we no longer want to work with you?"

Then you leave, and it is technically boring. Repository, domains and provider accounts are in your name; we work inside them, we do not own them. The source code is documented and builds with the standard commands, and content sits as Markdown or in a CMS with a documented API. Changing provider or agency means build, publish, switch DNS. We consider that obvious and write it down anyway, because it is not universal in this industry.

"Our current host has looked after us for years. Do we have to switch?"

In most cases, no. A statically served Astro site runs on any hosting that can serve files – often it is enough to point the deployment at your existing contract. What we check first: whether it supports automated publishing, whether certificates and redirects are managed cleanly, and whether your plan copes with traffic spikes. Switching for its own sake costs you money and costs us credibility.

"Who is liable if the site goes down?"

The provider is liable for infrastructure availability under its own contract – which is why you sign it directly and in your own name instead of buying it through us with a markup. We explicitly do not offer around-the-clock on-call cover or a guaranteed availability commitment with penalties. What we can agree are contact hours and escalation paths within a maintenance arrangement. If your operation needs more than that, it belongs with a specialist operator or inside your own IT.

"We are expecting a traffic spike after a broadcast. Will it hold?"

Static delivery from a CDN is precisely the case this model was built for: a finished file is served from cache, and no process computes anything per visitor. In practice a surge mostly means more bandwidth – predictable, without error pages. It looks different if your most important page renders on demand or a form writes into a third-party service; we walk through those spots individually before an announced campaign. That is another reason to use dynamic routes sparingly.

"We currently pay for a CMS subscription. Can we get rid of it?"

Possibly – the honest answer depends on your editors. If a few people publish rarely but in a structured way, content collections in the repository are enough, and editing can additionally run through a chat channel. If several people publish daily, run translations in parallel and approve in stages, a headless CMS is the right tool and the subscription is money well spent. We cost out both paths and tell you which case is yours.

"Does a migration pay off at all, if hosting is that cheap?"

On saved hosting alone: almost never. If somebody sells you a migration on the hosting invoice, do the arithmetic. A move pays off on other measures – load time and visibility, less maintenance across a large extension landscape, faster delivery of new pages, a smaller attack surface. Whether that adds up for you is something we assess with an open outcome; the criteria and the counter-arguments are under migration to Astro.

Can you host an Astro site for free?

Often, yes. Because the site is prerendered by default and served as static HTML, a typical marketing site fits into the free or cheapest tiers at many providers. We do not print the limits here because they change constantly – we check them for your case before you decide.

Does an Astro site need a Node server?

Only if you use on-demand rendering. By default the site is prerendered and runs as static files with no application server at all. As soon as individual routes should render at request time, you need an adapter for the target runtime – on your own infrastructure, usually the Node adapter.

What is an Astro adapter?

An adapter makes an Astro project runnable on a particular server runtime and is required for on-demand rendering. Astro maintains first-party adapters under the @astrojs scope, including ones for Node, Vercel and Cloudflare. For purely static delivery you do not need one.

Does Astro run on ordinary shared hosting?

For static delivery, yes: the build output is HTML, CSS, JavaScript and image files that any web server can serve. The only requirement is that you can publish there automatically. On-demand rendering, by contrast, needs a suitable runtime environment.

Is Astro free?

Yes. Astro is free and open-source software under the MIT license. There are no licence fees – cost comes from implementation, hosting, a possible CMS and the services running alongside the site. What Astro itself is, is explained under what is Astro.

Can you self-host an Astro site?

Yes. The MIT license permits it and the build output is portable: static files on your own web server, and for dynamic routes a Node process via the corresponding adapter. Operation, certificates, backups and scaling then sit with your IT.

How long does a hosting move take?

For an existing Astro site, usually two to five working days plus DNS lead time. It takes longer with inherited redirect chains, externally managed domains and certificates, and internal approval tracks. The old environment stays online until the cutover.

12 — Cluster

More from the Astro cluster.

Build, operation, content and the way there – each page answers exactly one question:

13 — Go deeper

Astro hosting: what running the site actually costs.