The Facebook Content Engine: A Reaction-to-Traffic Loop, Not a Content Calendar

This is a self-hosted engine that connects to a Facebook Page, generates AI-written posts, schedules them, and runs the follow-up comment and tracking loop automatically — a single Docker container running on a Raspberry Pi, no cloud dependencies.

Most content-scheduling tools are calendars with an AI writer bolted on. Pick a time, generate a caption, publish. That's not what this is built around. The actual lever on Facebook isn't posting volume, it's engagement shape: a post that earns a comment gets pushed to more people than one that just gets a click. So the generation layer targets earning a reaction first, and treats outbound traffic as what happens after that reaction — not the thing a post gets judged on directly.

Each generated post is a full package: a caption, a first comment designed to bridge into the real content (explicitly not "link in comments" bait, which gets filtered out), an evidence hook, and headline/dek options. All of it scored against a five-layer engagement framework — what interrupts scrolling, what tension it creates, what public behavior it invites, what reinforces repeat engagement, what the user actually gets at the end. An operator picks a campaign mode (comments-first, authority-first, clicks-first), generates a few candidate packages, and either publishes immediately or schedules with timed follow-up comments.

Stack underneath: Astro for the app shell, a Node/Docker backend, SQLite on disk, Facebook's own API for publishing and page-activity tracking, an LLM for generation, and a cron loop handling scheduling, publishing, and follow-ups without anyone watching it.

Running Unattended Finds the Bugs

Autonomous posting-and-commenting on a schedule sounds simple until it's running unattended. The actual bugs that showed up: a slot-hours parser bug in the scheduling rebalance script that could misplace posts in the queue; a race condition where the same scheduled follow-up comment could get posted twice if publishing and scheduling overlapped; a D1 binding mismatch that broke the posts list under certain conditions; and generation jobs that needed to be hardened so a partial failure didn't leave a "blast" half-scheduled. None of these are exotic — they're the standard failure modes of any system that runs itself on a timer against a live, rate-limited external API. The fix pattern across all of them was the same: move from "should work" to strict validation and fallback completion at every step a cron tick touches.

Why Any of This Matters

The point was never Facebook engagement as an end in itself. It's Facebook as a distribution channel feeding traffic to owned properties. Comment-first design exists because Facebook's own algorithm rewards it; destination-site tracking exists because the metric that actually matters — time on article, revenue per impression — lives off-platform, not in Facebook's native insights. The tool is honest about that gap. Graph API hands over comments, impressions, and clicks. Everything past the click belongs to someone else's analytics.

Still Running, Still Getting Adjusted

75 commits across about two and a half months of real, unattended operation — long enough to surface the scheduling-race and binding bugs above, and to fix them under production conditions rather than in a demo. This is a living tool, not a one-shot build: it's still the thing that decides what actually gets posted, and it gets adjusted every time Facebook's own algorithm or API shifts under it.