Cloudflare + Astro: Six Months Later, What We Learned Building Production Sites

Real production experience from building bilingual, content-driven sites on Astro for LatAm and US markets.

On January 16, 2026, Cloudflare announced the acquisition of The Astro Technology Company. The entire Astro core team joined Cloudflare. The framework stayed MIT-licensed and open-source. Then in March, Astro 6 beta shipped with Live Content Collections, a unified dev/prod runtime, and automatic CSP.

Six months later, we have enough production mileage at Mintec to offer a grounded assessment — not of what the press release promised, but of what actually works, what doesn't, and how this changes the decision matrix for LatAm businesses choosing a web framework.

The Short Answer: Should You Build on Astro 6 Today?

Yes — with specific caveats based on your content profile.

If your site is content-driven (blogs, marketing pages, documentation, bilingual content, news), Astro 6 is arguably the best option in 2026. If your site requires heavy personalization, real-time user dashboards, or complex server-state management, you should look at Astro + Server Islands for the static parts and a framework like Next.js or Remix for the interactive sections.

The Cloudflare acquisition eliminated Astro's biggest risk: framework abandonment. A team now backed by a $30B infrastructure company is not going anywhere. The second-biggest risk — Cloudflare locking Astro to its own platform — is worth monitoring but has not materialized in practice. Astro 6 still deploys to Vercel, Netlify, AWS, and self-hosted setups without friction.

What the Cloudflare Acquisition Actually Changed

Let us be specific about what improved and what did not.

What got better: Development speed. The Astro team went from a small startup with VC pressure to a fully-funded feature team at Cloudflare. Astro 6 shipped three months after the acquisition. That pace was unheard of in the previous funding cycle.

What did not change: Platform neutrality. Astro still uses the adapter pattern. You can deploy to Cloudflare, Vercel, Netlify, or any Node.js server. We tested all four paths. The @astrojs/cloudflare adapter got more attention (unsurprisingly), but the Vercel and Netlify adapters remain stable and well-maintained.

What is genuinely better: The dev experience. Astro 6's dev server runs on workerd — Cloudflare's open-source Workers runtime. For our team in San Pedro Sula, that means the local development environment matches production byte-for-byte. The category of bugs we used to call "works in dev, breaks in prod" essentially disappeared.

Astro 6 Features That Actually Matter in Production

After shipping multiple sites on Astro 6, here is the feature breakdown with real impact:

Live Content Collections: Game-Changer for Dynamic Content

The most significant addition. Before Astro 6, Content Collections were build-time only. If your data changed, you rebuilt. For a bilingual blog or marketing site, that was fine. But for e-commerce inventory or real-time pricing, it was a dealbreaker.

Live Content Collections fetch data at runtime using the same type-safe API. We used this on a client project that needed to display product availability from a Shopify store without rebuilding. The implementation was clean — defineLiveCollection with a Shopify loader, then getLiveEntry on each product page. Zero rebuilds. Fresh inventory data on every request.

The framework we use at Mintec to decide between Live and static Collections is simple:

• Static Collections: Blog posts, case studies, service pages, documentation — anything that changes less than once per hour
• Live Collections: Product inventory, pricing, personalized content, user-specific data

Mix both on the same site. Astro handles it transparently.

Unified Dev/Prod Runtime: Eliminates an Entire Bug Category

Before Astro 6, you wrote code locally on Node.js and deployed to Cloudflare Workers on workerd. Different runtimes meant different behavior. Edge functions that worked locally would fail in production because a specific Web API was missing or behaved differently.

Astro 6's Vite Environment API fixed this by running the same runtime locally and in production. For our development workflow, this was the most impactful change. We eliminated roughly 15% of our edge-case bugs overnight — the ones that only appeared after deployment.

Automatic CSP: Security Without the Headache

Content Security Policy headers prevent XSS attacks by telling the browser which scripts and styles are allowed to execute. Implementing CSP manually requires hashing every inline script and style on every page. On a site with dynamic content, that is a maintenance nightmare.

Astro 6's csp: true configuration generates CSP headers automatically, hashing all scripts and styles including dynamically loaded ones. We enabled it on three client sites in under ten minutes each. For companies handling sensitive customer data — common across fintech and healthcare clients in our portfolio — this is an easy security win.

Breaking Changes: What You Need to Know for Migration

If you are migrating from Astro 5, budget 1-2 hours per site:

• Node.js 22+ required (Node 18 and 20 dropped)
• Astro.glob() removed — use import.meta.glob() instead
• <ViewTransitions /> replaced by <ClientRouter />
• Zod 3 → Zod 4 (stricter schema validation)

We migrated our own site (50+ pages, bilingual, with complex content collections) in under 90 minutes. The Zod upgrade required the most attention — some existing schemas needed adjustments.

Astro vs Next.js in 2026: A Decision Framework

The most common question we get from clients: "Should we build this on Astro or Next.js?" Here is the honest framework we use, not marketing copy.

Choose Astro when:

• The site is content-driven (blogs, marketing, documentation, bilingual content)
• Performance is the #1 priority — zero JavaScript by default
• You are deploying to Cloudflare Pages and want native edge integration
• You need bilingual or multilingual content — Astro's static generation handles localized builds naturally
• You want minimal operational complexity — static sites are simpler than SSR

Choose Next.js when:

• The application has significant server-state requirements (dashboards, live collaboration)
• You need a unified frontend and API layer in one project
• Your team is already deep in the React ecosystem with App Router patterns
• Real-time features (WebSockets, server-sent events) are core to the product

Choose both when: You use Astro for the marketing site and Next.js for the application. This is more common than you think. Mintec's own architecture separates the blog and landing pages (Astro) from the client portals (Next.js). The separation keeps the marketing site fast and the application flexible.

Why This Matters for LatAm Businesses

LatAm brands face specific web performance challenges that Astro + Cloudflare address directly.

LatAm audiences typically connect to servers in the US or Europe. Every round-trip adds 100-200ms of latency. Static sites generated by Astro and served through Cloudflare's global CDN (330+ locations) eliminate most of these round-trips. The HTML, CSS, and JavaScript are pre-built and served from the edge location closest to the visitor.

For a user in Tegucigalpa accessing a site hosted on Cloudflare, the static assets arrive from a nearby edge node — not from a server in Dallas or Miami. The difference in Time to First Byte (TTFB) is typically 200-400ms.

We measured this on a client site serving both US and LatAm audiences. With Astro static generation + Cloudflare CDN, the median TTFB dropped from 680ms (origin server in Miami) to 120ms (Cloudflare edge node in Panama City). That is the difference between passing Core Web Vitals and failing them — and between converting a lead and losing them.

What We Would Do Differently

No retrospective is honest without admitting mistakes. Here is what we got wrong:

1. We overestimated migration complexity. We budgeted two weeks for our first Astro 6 migration. It took one developer less than two days. The @astrojs/upgrade tool handles 90% of the automated work.

2. We underestimated Live Content Collections. We initially treated them as experimental. They are production-ready and the most compelling reason to upgrade.

3. We did not plan for the Zod 4 migration. The stricter schema validation broke a handful of our content schemas. It was a 30-minute fix, but it surprised us during a Friday deployment.

The Verdict

Astro 6, six months after the Cloudflare acquisition, is the strongest content-driven web framework in the market. The acquisition removed the existential risk, Astro 6 delivered on its feature promises, and the platform-neutrality commitment has held.

For LatAm brands building bilingual, content-driven sites — especially those deploying to Cloudflare's edge — Astro 6 is the clearest path to fast, secure, and maintainable web development in 2026.

If you are evaluating frameworks for your next project, start with your content profile, not the hype. Astro wins where content is king. Use it where it shines, pair it with something else where it does not. That is the honest answer.

At Mintec, we build on Astro, Next.js, and other frameworks depending on the use case. Contact us if you want a no-obligation assessment of which architecture fits your business.