AIKit runs on **Astro v6** with **Cloudflare Workers SSR** and **D1** as its live content database — a fully dynamic architecture that queries blog posts, sitemaps, and SEO metadata directly from D1 at request time, eliminating static rebuilds entirely.
The Problem: Static builds can't handle LLM-generated content pipelines
Traditional static site generators (SSGs) are built for a world where content is authored by humans and deployed in bulk. A markdown file gets written, the site rebuilds, and a static HTML file is served. This works well when you have 5 blog posts a month — it falls apart when you're generating 50 posts a day via LLM pipelines.
AIKit's auto-blog plugin uses large language models to generate SEO-optimized content autonomously. With a static architecture, every new post would require:
- A full site rebuild (potentially minutes per deployment)
- Regeneration of all sitemaps and index pages
- A redeployment to Cloudflare's edge network
- Cache invalidation for every changed route
This is operationally wasteful and fundamentally limits how frequently content can be published. Worse, it creates a tight coupling between the content pipeline and the deployment pipeline — a failure in either breaks the other.
The Solution: Astro v6 + Cloudflare Workers SSR + D1 live queries
AIKit's architecture solves this by moving content storage and retrieval to **D1**, Cloudflare's serverless SQLite database, and serving all content through **Astro v6's Cloudflare Workers SSR adapter**. The key insight: instead of rendering blog posts at build time, render them at _request time_ from a database that the LLM pipeline writes to independently.
Astro v6 Breaking Change: The `cloudflare:workers` Import Pattern
Astro v6 introduced a significant breaking change in how Cloudflare bindings are accessed. Previous versions used `Astro.locals` or environment-variable-based patterns. In v6, the recommended approach is the `cloudflare:workers` virtual import:
```typescript
// Astro v6 pattern — replaces deprecated Astro.locals runtime
import type { Env } from 'cloudflare:workers';
// In Astro pages and endpoints, bindings are accessed through
// the platform object with proper TypeScript types
```
This pattern gives direct, typed access to all Cloudflare bindings — D1 databases, KV namespaces, R2 buckets, and AI bindings — directly from Astro components and API routes. The migration path from v5 to v6 requires:
1. Updating `wrangler.toml` to declare bindings
2. Importing from `cloudflare:workers` instead of using `Astro.locals`
3. Updating the Astro config adapter to `@astrojs/cloudflare` with the `workers` runtime
Architecture Overview: How components fit together
| Component | Role | Tech Stack |
|---|---|---|
| **Astro v6 SSR** | Server-side rendering at the edge | Astro + @astrojs/cloudflare |
| **Cloudflare Workers** | Request handling & routing | Workers runtime (ES modules) |
| **D1 Database** | Content storage & query layer | Cloudflare D1 (SQLite) |
| **Auto-Blog Plugin** | LLM-powered content generation | AIKit LLM pipeline → D1 inserts |
| **Dynamic Sitemaps** | SEO index generation | Astro endpoint route → D1 query |
| **llms.txt** | AI-crawlable site index | Astro endpoint route → D1 query |
The data flow is straightforward:
1. The **auto-blog plugin** generates content via an LLM and writes it directly to D1
2. Astro components on the **Workers SSR runtime** query D1 at request time
3. **Dynamic sitemaps** and **llms.txt** are generated from live D1 queries — no rebuild needed
4. **Cache headers** ensure frequently-accessed pages are served from Cloudflare's edge cache
Code Example: Dynamic sitemap route pattern
Here's how AIKit implements a dynamic sitemap that queries D1 at request time:
```typescript
// src/pages/sitemap-index.xml.ts
import type { APIRoute } from 'astro';
import type { Env } from 'cloudflare:workers';
export const GET: APIRoute = async ({ platform }) => {
const env = platform?.env as Env;
const db = env.AIKIT_D1;
// Query all published posts from D1
const { results } = await db.prepare(
`SELECT slug, updated_at FROM blog_posts
WHERE status = 'published'
ORDER BY updated_at DESC`
).all();
const urls = results.map((post: any) => `
<url>
<loc>https://ai-kit.net/blog/${post.slug}</loc>
<lastmod>${post.updated_at}</lastmod>
<changefreq>weekly</changefreq>
<priority>0.8</priority>
</url>`).join('');
return new Response(
`<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls}
</urlset>`,
{
headers: {
'Content-Type': 'application/xml',
'Cache-Control': 'public, max-age=3600, s-maxage=3600'
}
}
);
};
```
The same pattern applies to `llms.txt`, which serves an AI-readable index of all site content:
```typescript
// src/pages/llms.txt.ts
import type { APIRoute } from 'astro';
import type { Env } from 'cloudflare:workers';
export const GET: APIRoute = async ({ platform }) => {
const env = platform?.env as Env;
const db = env.AIKIT_D1;
const { results } = await db.prepare(
`SELECT slug, title, excerpt FROM blog_posts
WHERE status = 'published'
ORDER BY created_at DESC`
).all();
const entries = results.map((post: any) =>
`- ${post.title}: https://ai-kit.net/blog/${post.slug}`
).join('\n');
return new Response(
`# AIKit\n\n## Blog\n${entries}\n`,
{
headers: {
'Content-Type': 'text/plain',
'Cache-Control': 'public, max-age=3600'
}
}
);
};
```
Both routes use D1 queries at request time, meaning any new post written to the database is immediately visible in the sitemap and llms.txt — no redeployment required.
The Auto Blog Plugin: D1 as content bus between LLM and site
The auto-blog plugin is where AIKit's architecture truly shines. It acts as a **content bus** between AIKit's LLM engine and the live Astro site:
```typescript
// auto-blog plugin core flow (simplified)
async function generateAndPublish(topic: string) {
// 1. LLM generates the blog post
const post = await aikit.generate({
prompt: `Write a blog post about ${topic}`,
format: 'markdown',
seo: true // enables SEO metadata generation
});
// 2. Write directly to D1 — no build step needed
const slug = slugify(post.title);
await db.prepare(
`INSERT INTO blog_posts (slug, title, body, excerpt, tags, status, created_at, updated_at)
VALUES (?, ?, ?, ?, ?, 'published', datetime('now'), datetime('now'))`
).bind(slug, post.title, post.body, post.excerpt, JSON.stringify(post.tags)).run();
// 3. That's it. The next request to /blog/{slug} renders the new post.
// Next sitemap crawl picks it up automatically.
return { slug, url: `https://ai-kit.net/blog/${slug}` };
}
```
Because D1 is **serverless SQLite**, writes are transactional and globally consistent through Cloudflare's edge network. The plugin can schedule content generation on cron triggers, batch-process topics, or respond to webhooks — all without touching the Astro build pipeline.
This decoupling is critical for scale:
- **Content pipeline** and **deployment pipeline** operate independently
- Posts can be published at any cadence (1/hour, 100/hour — same operational cost)
- Rollbacks are simple SQL statements (`UPDATE status = 'draft' WHERE slug = ?`)
- A/B testing and scheduled publishing are trivially implemented as D1 queries
Key Takeaways
1. **Static builds don't scale for LLM-generated content.** When your content pipeline generates posts autonomously, requiring a full rebuild for each new post is a bottleneck that limits frequency and operational reliability.
2. **Astro v6 + Cloudflare Workers SSR makes dynamic content feasible at the edge.** The `cloudflare:workers` import pattern gives typed, ergonomic access to D1 and other Cloudflare bindings directly from Astro components and API routes.
3. **D1 as a content bus decouples generation from serving.** The auto-blog plugin writes to D1, and the Astro SSR site reads from D1 — two independent systems connected by a shared database. This is the architectural pattern that scales.
4. **Dynamic sitemaps and llms.txt update automatically.** With request-time D1 queries, every new post is immediately discoverable by search engines and AI crawlers. No rebuild, no redeploy, no cache purge.
5. **Cache headers still give you edge performance.** Just because content is dynamic doesn't mean it's slow. Cloudflare Workers SSR combined with sensible `Cache-Control` headers (1-hour edge caching) gives you near-static performance with fully dynamic content.
AIKit's architecture proves that you don't have to choose between the speed of static sites and the flexibility of dynamic content. With Astro v6, Cloudflare Workers, and D1, you get both — and a content pipeline that scales effortlessly with LLM-driven generation.