Three n8n Workflows That Keep a Social Queue Full

Most teams already run n8n for the unglamorous middle of the stack: a form fills a sheet, a webhook pings Slack, a nightly job reconciles two systems nobody wants to open. Social posting is usually the one step still done by hand, so the pipeline produces a perfectly good announcement and then stops, waiting for a person to copy it into a browser form.

It does not have to end there. Below are three workflows that close the last gap, built from nodes you already have plus the postqueen community node, followed by the things that will bite you, because they will.

Install the node and collect your channel IDs

The node ships on npm as n8n-nodes-postqueen. On a self-hosted n8n you add community nodes from Settings, then Community Nodes, then Install, and enter the package name. If you are on n8n Cloud, which community packages you may install is governed by n8n's own policy, so confirm that before you design a workflow around it.

Then create a credential with an API key from your postqueen dashboard under Settings, then Developers. Self-hosted installs point the credential at their own backend rather than the hosted API. Before building anything, collect your channel IDs: every workflow below needs them, and hunting for them halfway through a build is how the wrong account ends up hardcoded in a node nobody reopens for six months.

# Self-hosted n8n: Settings > Community Nodes
# > Install, then enter the package name:
n8n-nodes-postqueen
 
# Baking it into your own image instead?
# Add it to the n8n service, then:
docker compose up -d
 
# Collect the channel IDs your nodes will need
npm install -g postqueen
export POSTQUEEN_API_KEY=your_api_key
postqueen integrations:list

Recipe 1: an RSS feed into a reviewed queue

The goal here is not to fire a post the instant a feed updates. It is to turn every new article into something already written per network, already scheduled, and still cancellable by a human who is not awake right now.

• An RSS Feed Trigger polling your feed every fifteen minutes.
• A Filter node that drops what you do not announce: excluded categories, authors you do not publish for, anything tagged internal.
• A Code or Set node that builds the per-network text: the hook first for X, the context paragraph for LinkedIn, title and link alone for the feeds where that is all anyone reads anyway.
• The postqueen node, creating one post with your channels selected and a publish time two hours out.
• A Slack or email node telling a human what was queued, with a link to the calendar.

The two hour gap is the entire design. It is not latency you failed to remove, it is the review gate: long enough that someone can notice the article title still has a typo in it, short enough that the announcement is timely. If nobody intervenes, it goes out on its own. If somebody does, the fix costs one click instead of a deletion and an apology thread.

Deduplication is not optional

RSS feeds lie. Items get republished with a fresh timestamp when an editor fixes a typo, some feeds reorder without warning, and a restarted n8n instance can happily replay what it already saw last week. Keep a record of the item IDs you have queued, in a sheet, a database node or n8n's own static data, and check it before the postqueen node runs. Without that, one CMS edit posts the same article twice and your feed starts to look like a bot's feed, which at that point it is.

Recipe 2: the evergreen recycler

Your best posts from six months ago are still true and almost nobody saw them the first time. This workflow reposts them on purpose, on a rotation you control, rather than by accident when you run out of ideas on a Thursday.

Keep a table in Sheets, Airtable, NocoDB or Postgres with one row per evergreen post: the text, the channels, a status, and a last posted date. Then wire it up in five nodes.

• A Schedule Trigger, Monday at 8 AM, with the timezone set explicitly on the node rather than inherited and forgotten.
• A read from your table, filtered to status ready and last posted more than ninety days ago.
• A Limit node set to three, because a recycler with no ceiling empties your entire table into one morning the first time a filter is wrong.
• The postqueen node, spreading those three across the week instead of stacking them on the same minute.
• A write back to the table, setting last posted to today.

That write back is what makes the workflow safe to run twice. Without it, the same three rows are still the oldest next Monday and the same three posts go out forever, which is a bug that looks like a feature for about a month. With it, the table rotates on its own and the flow survives a retry, a manual run, and a colleague who clicks Execute to see what happens.

A recycler without a write back is not a recycler. It is a loop with an audience.

Recipe 3: announce the release you already tagged

The release notes are written. They are sitting in a tag. The announcement is a copy and paste job that somebody does badly at six on a Friday, which makes it the best possible candidate for automation.

• A GitHub Trigger listening for the release published event.
• An IF node that stops on prereleases, unless you genuinely want release candidates announced to the public.
• A Code node that turns the release body into per-network copy: the headline change for X, the what and the why for LinkedIn, the full list where long form works.
• The postqueen node, scheduled for the next morning slot rather than whenever CI happened to finish.
• A Slack message to your team channel, so colleagues see the announcement before the audience does.

Two details save this one from being a toy. First, cut the changelog rather than pasting it: a network post is not a changelog, and a dependency bump is not news to anyone outside the repository. Second, schedule for a human hour. Releases land when they land, frequently at midnight, and an announcement that nobody is awake to see is worse than the same announcement on Tuesday morning.

Things that will bite you

• Retries create duplicates. n8n retries a failed node, but if the failure happened after the post was created, the retry creates a second post. Track what you have already sent and check before creating.
• Rate limits are real. The hosted API enforces an hourly request cap and self-hosted installs set their own through the API_LIMIT environment variable. A flow that loops over eighty rows in one burst will meet it, so batch the items and add a delay.
• Timezones live in two places. The Schedule Trigger has one and your publish timestamps have another. Set both explicitly, or you will discover which is which on the last Sunday in March.
• Media has to be reachable. A file path inside the n8n container is not a URL anyone else can fetch. Upload the file first and reference what comes back.
• Test against something nobody reads. A private channel, or a self-hosted install with a throwaway account, costs an hour and saves you the post that went out eleven times.

None of these are exotic. They are the same failure modes every integration has, and they show up here with an audience attached, which is the only thing that makes them memorable.

When n8n is the right answer

n8n earns its keep when the trigger already lives in another system and the logic is deterministic: a feed updated, a row changed, a release shipped, and what happens next is the same every time. That is precisely the work you do not want a person doing, and precisely the work you do not want a language model improvising either.

When the job is one-off, or when it is genuinely language work rather than plumbing, a CLI call or a conversation over the MCP server gets you there faster with less to maintain. postqueen is open source under AGPL-3.0 and exposes all of those surfaces from the same account, so the question is only which one fits the workflow in front of you today. Whatever you build, keep a gap between the machine deciding and the audience seeing. Every recipe above is really the same idea wearing three different triggers.