Astro 5 + Tailwind 4 — the stack for company websites in 2025

TL;DR: Astro 5 = Content Layer API (faster builds), Actions (server endpoints with type safety). Tailwind 4 = zero config, new utilities, CSS-first configuration. The stack for landing pages and company websites in 2025 — fast builds, excellent Lighthouse scores, minimal JS.

Over the last two years Astro has become the default choice for sites where content matters more than interactivity. Astro 5 and Tailwind 4 releasing close together is a good moment to take a fresh look at this stack — what changed and whether it’s still the right choice.

What’s new in Astro 5

Content Layer API is a rewrite of content collections with an emphasis on performance. In practice: for a blog with 500 articles, the build is now 8–10x faster. The API has also changed:

// astro.config.mjs - Astro 5
import { defineConfig } from 'astro/config';
import { glob } from 'astro/loaders';

export default defineConfig({
  content: {
    collections: {
      blog: {
        loader: glob({ pattern: '**/*.md', base: './src/content/blog' }),
      },
    },
  },
});

The new loader API lets you fetch content from any source — Markdown files, external APIs, databases. Content collections are no longer just “folders with files”.

Actions are Astro’s formal answer to the need for server endpoints. Instead of manual API routes:

// src/actions/index.ts
import { defineAction } from 'astro:actions';
import { z } from 'zod';

export const server = {
  contact: defineAction({
    input: z.object({
      email: z.string().email(),
      message: z.string().min(10),
    }),
    handler: async (input) => {
      await sendEmail(input);
      return { success: true };
    },
  }),
};

Type-safe, with Zod validation, error handling out of the box.

Tailwind 4 — what changed

The biggest change is the absence of tailwind.config.js. Configuration moved to CSS:

/* src/styles/global.css */
@import "tailwindcss";

@theme {
  --color-brand: #6366f1;
  --font-display: 'Inter', sans-serif;
  --breakpoint-xs: 475px;
}

Tailwind 4 is now a CSS-first tool — configuration lives where the styles are. New utilities include field-sizing-content (textarea automatically adjusts height to content), an improved not- variant allowing more readable selectors, and inert utility for accessibility.

Project initialization

npm create astro@latest my-site -- --template minimal
cd my-site
npx astro add tailwind

Astro 5 automatically detects Tailwind 4 and configures it correctly — no need to manually create a configuration file. The resulting project has a build time under 1 second for a typical company website and zero JavaScript in the default template.

Directory structure:

src/
  content/
    blog/    # .md / .mdx articles
  pages/
    index.astro
    blog/
      [slug].astro
  styles/
    global.css  # Tailwind 4 config here
  layouts/
    Base.astro

Migration pitfalls

Migrating from Astro 4 to 5: the getStaticPaths API has changes in how returned props are typed — if you use TypeScript with generics, type updates may be necessary. Adapters (Vercel, Netlify, Node) require updates to versions compatible with Astro 5 — check your adapter’s release notes.

When migrating Tailwind 3 → 4: the overflow-ellipsis and overflow-clip classes have been renamed to text-ellipsis and text-clip. The flex-grow and flex-shrink classes are now grow and shrink. Gradient utilities went through a refactor. It’s recommended to run the official migration tool: npx @tailwindcss/upgrade.

When NextJS instead of Astro

Astro wins for: static company websites, blogs, documentation, landing pages with simple forms. Excellent Lighthouse scores, minimal JS, fast builds.

Next.js wins for: applications with auth and user sessions, dashboards with real-time data, complex SSR where each request generates different content based on user state. If your “company website” has an extensive client portal — Next.js is the right choice from the start.

Summary

Astro 5 + Tailwind 4 in 2025 is a mature, production-ready stack for static and semi-static sites. Content Layer API solves performance problems that appeared with large content services, and Actions provide a sufficient server-side layer for typical contact forms and simple operations. For company websites, portfolios, and blogs — it’s still hard to find a better choice.