> Most SaaS teams spend 20+ hours per week on content publishing. Over the past two weeks, the AIKit blog pipeline has published 138 posts without a single human intervention—no editor, no CMS login, no manual deploy.
The Problem: Content Bottlenecks
For any content-driven SaaS, the bottleneck isn't creation—it's publishing. You can generate 10 high-quality posts in the time it takes to review, format, upload, schedule, and promote a single one. Traditional CMS workflows require:
- Logging into an admin panel
- Formatting content into rich text blocks
- Setting featured images and meta descriptions
- Clicking through preview/publish/schedule flows
- Verifying the post renders correctly
At 5 minutes per post (which is optimistic), 138 posts would take over 11 hours of manual labor.
The Solution: Zero-Human Publishing
AIKit's auto-blog pipeline eliminates every manual step:
Architecture Overview
```
Content Calendar → Queue JSON files → queue-publisher.py → blog-publisher.py → D1 Database → Live Site
↕ ↕
cron (Mon/Wed/Fri) archive to published/
```
The pipeline is intentionally simple—no message queues, no webhook chains, no orchestration layer. Each step is a Python script that reads a file or runs a SQL command:
1. **Queue JSON** — A directory of `NN-slug.json` files, sorted alphabetically for FIFO ordering
2. **queue-publisher.py** — Picks the first file, passes it to blog-publisher.py
3. **blog-publisher.py** — Converts markdown to Portable Text JSON, runs 4-phase D1 insert
4. **D1 Database** — Cloudflare D1 is instantly consistent on read-after-write
5. **Live Site** — No deploy needed. Dynamic SSR routes query D1 per-request.
Key Design Decisions
**Why files, not a database queue?** JSON files are human-readable, git-committable, and survive database resets. Each file is a complete post—title, body_text, excerpt, category, tags. The published/ archive gives a full audit trail.
**Why Python scripts, not Workers?** The pipeline runs on a cron-accessible machine (macOS), not in-browser. Python gives us json.dump(), subprocess.run() for wrangler, and os.listdir() for queue management—no Cold Start latency.
**Why no admin UI bypass?** The pipeline inserts directly into D1. EmDash's admin UI uses Passkey/GitHub/Google OAuth only—no API keys, no service tokens. Direct D1 access is the only automation path, and it works.
Results After 138 Posts
| Metric | Value |
|--------|-------|
| Total posts published | 138 |
| Total human time | 0 minutes per post |
| Average publish latency | ~3 seconds per post |
| Failure rate | < 2% (slug collisions) |
| Queue auto-refill | Unlimited (AI-generated) |
| Cost per post | $0 (static content gen) |
The 4-Phase D1 Insert
The most technically interesting part is handling EmDash's circular foreign key constraint between `ec_posts` and `revisions`:
```sql
-- Phase 1: Insert post (NULL revision refs)
INSERT INTO ec_posts (id, slug, title, content, ...) VALUES (...);
-- Phase 2: Insert revision (references post)
INSERT INTO revisions (id, collection, entry_id, data, ...) VALUES (...);
-- Phase 3: Update post with revision refs
UPDATE ec_posts SET live_revision_id=?, draft_revision_id=?;
-- Phase 4: Insert SEO meta
INSERT INTO _emdash_seo (collection, content_id, ...) VALUES (...);
```
Phase 1 creates the post without revision references. Phase 2 creates the revision with a foreign key to the post. Phase 3 bridges them. The SEO insert is optional but improves Open Graph rendering.
Key Takeaways
1. **Simplicity beats complexity.** A file-based queue with Python scripts is more reliable than a distributed task queue for a single-server content pipeline.
2. **Direct D1 access is the secret weapon.** No admin panel, no API rate limits, no auth tokens to rotate—just `wrangler d1 execute`.
3. **Zero-cost scaling.** 138 posts cost $0 in computing. The bottleneck is content quality, not infrastructure.
4. **Every post auto-appears in /llms.txt.** Since both files query D1 dynamically, new posts are immediately discoverable by AI agents and LLM crawlers.
This pipeline is our dogfooding proof that automated content at scale works—and the EmDash D1 schema is flexible enough to power it all.