techpotions on n8n: the automation behind our blog and newsletter
The self-hosted n8n that runs our own content operation. It schedules blog drafting, cross-posts published posts to dev.to with a canonical link back, and sends the weekly newsletter in resumable batches. The app keeps the rules and the data; n8n keeps the clock and the integrations.
We publish technical writing most days and wanted every post to reach dev.to and a weekly newsletter without anyone copying and pasting. The common way is to build the whole pipeline on the n8n canvas, and that is where automations get fragile: business rules hidden in expressions, a retry that emails someone twice, a long job that times out halfway.
We split the work. The Next.js app owns every decision and all the data: what to draft next, who is subscribed, what has been sent. n8n owns time and fan-out: a schedule asks the app to draft, a webhook takes each published post to dev.to and writes the result back, and a weekly loop sends the newsletter in batches until the app says it is done. A person still reviews and publishes every post.
Numbers that moved.
We run our own content operation on self-hosted n8n: the same kind of setup we build for clients. This is how it is wired, and what running it taught us.
Who does what
The rule we follow: n8n decides when, the app decides what. The canvas holds schedules, one webhook and a handful of HTTP calls. The decisions (what to draft next, who gets the newsletter, what has already been sent) live in the Next.js app, where they are versioned and reviewed like the rest of the code.
- Drafting: every 12 hours n8n calls the app, which drafts the next post from the topic backlog with OpenRouter and posts a preview link to Slack. A person reviews and publishes it in Payload. On Sundays the same run refills the backlog with 15 topics from live search signals.
- Cross-posting: publishing a post sends it to an n8n webhook. n8n cleans the tags down to dev.to’s limit of four, posts the article with its canonical URL so Google keeps crediting our site, and writes the dev.to link back into the post. Why the canonical URL is the whole game.
- Newsletter: on Wednesdays n8n asks the app to prepare the issue; on Thursdays it calls the send endpoint, 40 subscribers at a time, until the app reports done. Each subscriber is marked as sent, so a run that stops halfway picks up where it left off instead of mailing anyone twice.
- Every call between the two sides carries the same bearer token, checked at both ends.
What running it taught us
Long jobs do not belong in one request. The newsletter send is a loop of short, resumable batches rather than one long call that can time out halfway. How that loop works.
Schedules need a timezone. A send time written as fixed UTC drifts by an hour when the clocks change, and the fix is a timezone on the workflow itself. The daylight saving fix.
Why it matters for client work
This is the pattern we bring to client builds: keep the rules in code you can review, let n8n handle the clock and the integrations, and make every step safe to run twice. More in the n8n workflows we run in production, or see what we build with n8n.