n8n Automation HubWhy split it
Rendering is the slow, expensive half and it's the half that can fail in interesting ways. Uploading is quick and safely retryable. In one workflow, a failure in the upload or thumbnail chain meant reasoning about a run that had already spent its render. After the split the Creator's run takes about half an hour, and the Publisher finishes in well under a minute.
What travels in the row
The queue tab has one row per episode with these columns: row_id, episode_date, status, long_form_path, long_form_title, long_form_description, long_form_tags, chapters_text, thumbnail_source_path, shorts_json, created_at, published_at and youtube_long_id. The shorts_json field holds zero to three shorts, each with its own path, title and publish time.
The chapter list shows why this design matters. In the monolithic workflow the upload node reached back to a Build Chapters node by name. After the split that node lives in a different workflow and can't be referenced at all, so the Creator computes the chapter text and stores it as a literal field in the row, and the Publisher never recomputes it. The earlier version of that reference had already caused trouble once, when a node with no outgoing connections never ran: see the dead-end node article.
Timestamps are absolute
Shorts are scheduled to go public at times chosen when the Creator renders. Those are stored as absolute UTC timestamps rather than offsets such as thirty minutes from now, and the Publisher clamps any time that is already in the past to the present. If the Publisher runs late, a stored offset would drift; a stored absolute time can only end up early, and the clamp handles that.
The key and the buffer
row_id is the episode id, for example ep_20260915, unique per day, so the Publisher's update matches exactly one row. That is the safeguard from the non-unique column article. The Publisher runs two hours after the Creator. The Creator's typical run is about half an hour, so the buffer is generous, and a Publisher that finds no ready row simply exits.
What to watch on the first days
The workflow validated with no errors, but the real test is the queue. Check that a new ready row appears after the Creator's slot, that it flips to published after the Publisher's, and that the video is actually on the channel. The queue on this instance shows that cycle on three consecutive days.
The split also made a later failure easy to see. On a day when the Creator produced nothing, the Publisher had no ready row and exited, which is exactly what a green workflow that produced no episode looks like from the outside.
Monolith versus Creator and Publisher
| One workflow | Creator + Publisher | |
|---|---|---|
| Failure late in the chain | The render is wasted or the run state is unclear | The row stays ready and the next Publisher run retries the upload |
| Editing the upload step | Risks the whole daily run | Only touches the quick, retryable half |
| Data between steps | Any node can reference any earlier node | Only what is written into the queue row |
| Visibility | Execution log only | The queue sheet shows each episode's state |
| Extra cost | None | Designing the row and keeping its columns in sync |
Rules for the queue row
- Everything the Publisher needs is a literal value. Titles, descriptions, chapter text, paths, publish times. The Publisher should never have to recompute anything.
- The key is unique by construction. An episode id such as
ep_20260915can't collide, a title can. - Times are absolute UTC timestamps. The Publisher can run late, and an offset would drift with it.
- Status changes are written by exactly one side each. The Creator writes ready, the Publisher writes published.
- Nested data goes into one JSON column. The shorts list lives in
shorts_jsoninstead of a variable number of columns.
What I would do differently
Two things came up after the split went live, and both are covered in their own articles. First, the Creator should claim its source topic the moment it picks it, otherwise a backlog of ready rows leads to duplicate renders. Second, the Creator should only append the queue row after checking that every file the row points to exists on disk. A row that says ready but points at a missing file makes the Publisher fail every day until someone fixes the row by hand.
If you split a workflow like this, write down the row's columns first and build both workflows against that list. Most of the bugs I hit later came from a field one side expected and the other side never wrote.
Frequently asked questions
Why split a video workflow into two?
Rendering is slow and can fail, while uploading is quick and safe to retry. Separate workflows mean a failed upload doesn't waste a render, and editing one half doesn't risk the other.
How does the Publisher get data from the Creator?
Only through the queue row. One workflow can't reference another workflow's nodes, so everything the Publisher needs is written into the row as a literal value.
Why store publish times as absolute timestamps?
If the Publisher runs late, an offset like 'in 30 minutes' would shift with it. An absolute time can only end up in the past, and the Publisher clamps that to now.
What should the queue row key be?
Something unique by construction, such as an episode id built from the date. Matching on a title or topic risks updating the wrong row.