Twenty-eight nodes that take an Instagram reel apart, work out where every cut is, and rebuild the whole thing shot for shot around a different product. Same shot count, same pacing.
There's no client on this one. It's a template I built and submitted to n8n's Creator Hub, which means the whole thing is readable rather than described. It's here because of what it took to make it reliable, and that part transfers to any build.
Short-form video ads follow a rhythm. Six or seven cuts, each held for a beat, in an order that works. If you already know a particular reel performs, the useful thing isn't copying the footage, it's keeping the structure and swapping what's in it.
So the workflow downloads the reel, detects every cut, pulls one frame per scene, has a model describe what each shot is doing, generates a new image for each scene anchored to a different product, animates each one, and reassembles them in the original order at the original durations.
Scroll it sideways. Three of those loops are retry paths, one per slow external service, which is the whole reason it finishes rather than timing out.
Anyone can wire eight boxes together. What decides whether a workflow is still running in three months is what happens when the things it depends on misbehave. I ran this end to end against live APIs rather than trusting the docs, and three of them didn't match their own descriptions.
The actor named for reels only accepts usernames, not reel URLs. Feed it a link and it returns nothing useful. The general scraper with a direct-URL parameter is the one that works, which you only discover by running both.
Pointing at the newest model sounds sensible. It tracks whichever version is newest, which is also the one under the heaviest load with the tightest free quota, so it started returning hard rate limits. Pinning an older, quieter version fixed it and cut the response time to thirteen seconds.
Five seconds or ten, nothing in between, while real scenes are one second or three or six. So every clip gets generated long and trimmed back to its true duration at assembly. That's why the rebuilt timing matches the source exactly instead of approximately.
n8n let one node bind a credential belonging to an entirely different service, because both happened to be header authentication. No warning, nothing red. Left alone it would have sent one vendor's API key to another vendor's server on the next run.
Nothing catches that except auditing which credential each node is actually pointed at. It's the sort of thing that never shows up in a demo and matters enormously in something you're going to leave running.
You almost certainly don't need a reel rebuilt. But the parts that made this one survive are the same parts that decide whether an invoice pipeline or a lead router is still working next quarter.
Slow operations submit a job and poll for it rather than holding a connection open and hoping. Anything that can fail gets a retry, because a model returning a server error under load is normal rather than exceptional. Every assumption gets tested against the live service rather than the documentation. And the whole thing gets run end to end before anyone calls it finished.
The kitchen system runs on the same habits, which is why it's been running since June without me.
Twenty minutes. Tell me what it does and where it goes wrong, and I'll tell you whether it's worth building.
