Building production apps with Astro

Astro is not just for static sites. In this guide, I share the architecture patterns I use to build production apps with Astro.

Why Astro for production apps?

Three reasons:

1. Less JavaScript by default — your users download fewer bytes
2. Islands when you need them — add interactivity only where it matters
3. SSR, SSG, and hybrid in one project — choose per-route, not per-app

The architecture I use

1. Hybrid rendering by default

Most production apps need at least one dynamic route (a dashboard, a settings page). Hybrid rendering lets you keep marketing pages static and dynamic pages server-rendered — in the same project.

2. Content collections for typed content

Anything that is "content" (blog posts, docs, product descriptions) goes in a content collection. You get end-to-end type safety and frontmatter validation for free.

3. Database integration via a single module

I keep all database access in src/db/*.ts. Components never import the database directly — they call a function from the db module. This keeps the data layer swappable and testable.

4. Authentication via httpOnly cookies

Store session tokens in httpOnly, same-site, secure cookies. Never in localStorage. Never in a regular cookie. Astro's middleware makes this clean.

5. Sessions in middleware

Parse the session once in middleware, attach it to locals, and read it in any page or endpoint. No prop-drilling sessions through the component tree.

Performance patterns

Image optimization

Use Astro's built-in <Image> component for every image. It generates srcset, sizes, and modern formats automatically. The biggest performance win in most projects.

Font optimization

Self-host fonts with @fontsource. Avoid Google Fonts CDN — it adds a third-party request and a render-blocking stylesheet.

CSS

Astro scopes CSS by default. Use it. Avoid utility-only frameworks unless your team is bought in.

Common mistakes

1. Putting business logic in components — keep components presentational
2. Using client directives everywhere — only hydrate what needs interactivity
3. Ignoring the build output — inspect your dist/ folder regularly
4. Treating SSR like a serverless function — Astro middleware runs on every request; keep it fast

Closing

Astro rewards architecture discipline. The framework stays out of your way, which means your architecture is on you. Spend the time to design it well up front, and Astro will scale with you.