vercel with astro

Vercel with Astro

Vercel suits an Astro site that is mostly static and partly not. The pages are built and served as files; the handful of routes that have to do something when they are asked become functions, without the rest of the site paying for them. The setup work is deciding which routes those are and being explicit about it.

Connect Vercel See the setup

Vercel at a glance

What I do: An Astro site on Vercel, with the static pages served from the CDN and only the routes that genuinely need a request running as functions.
Typical setup: Adds 2–4 days
How it is bought: Part of a migration scope, or a Continuous development request once the site is yours
Category: Hosting

Setup

How I set up Vercel

Vercel fits an Astro site that is static in most places and dynamic in a few. The build prerenders what it can and serves those pages from the CDN; anything left runs as a function when it is asked. Keeping that second list short is the entire performance story, and it is easy to grow it by accident: a page that opts out of prerendering looks exactly the same and is now invoked on every visit.

So the first job after a deploy is checking what actually got prerendered against what was meant to. The second is the redirects. They live in the project config rather than in the site, which means a migration's redirect list and the routes it points at are maintained in two places and can quietly disagree. Generating both from one source removes a class of failure that otherwise shows up months later as a rule nobody can reach.

The last one is preview deployments, which are genuinely useful and are public by default. Every branch gets a URL, so unreleased pages, client work and prices are reachable by anybody holding the link. That is a decision to make before the first branch rather than after somebody forwards one.

How the handoff works

01
Push

A commit, on a branch
02
Build

Pages prerendered, routes split out
03
Preview

A URL for the branch, before release

Key handoff
04
Promote

The reviewed build becomes production
05
Verify

Redirects and routes requested on the real domain

Why this is the key handoff

Static by default, dynamic on purpose. The adapter decides what is a file and what is a function. Everything prerendered is served from the CDN; what is left runs per request, and keeping that list short is the whole performance argument.

Included

What gets connected

Static pages served from the CDN
Server routes as functions, where a page needs one
Redirects and headers declared in the project config
Preview deployments per branch, for review before release
Scheduled rebuilds where the site publishes on a calendar

Before you add it

What to watch out for

01

Which routes are static is a decision, not a default

Astro's adapter prerenders what it can and leaves the rest to run per request. A page that quietly opts out becomes a function invoked on every visit, which is slower and costs money, and nothing on the page looks any different. Worth auditing what actually got prerendered after the first deploy.
02

Preview deployments are a leak if nobody thinks about them

Every branch gets a public URL. That is the feature, and it means unreleased copy, client names and pricing are reachable by anyone with the link until protection is turned on. Decide before the first branch, not after somebody shares one.
03

The config is a second place URLs are decided

Redirects and headers live in the project config rather than in the site, so a migration's redirect list and the site's own routes are maintained apart and can disagree. Generating them from one source is worth the small amount of work it takes.

More tools

Keep exploring

All integrations Astro development Continuous development

Next step

Let me plan your next step.

Send your site

I can scope a migration. Send a brief and I will reply by email with next steps.