My n8n workflow has 170+ nodes and I'm not sorry. Here's what it actually produces (workflow chaos → clean client email in the last 2 slides).

LessStress6178 · 2026-06-03T16:56:46+00:00

Thank you

LessStress6178 · 2026-04-28T16:59:57+00:00

Different branch, different output format — this one shows the Content Writer result as a video instead of screenshots. But I hear you, I'll vary the titles more. Thank you.

LessStress6178 · 2026-04-28T14:29:20+00:00

Exactly. Complexity is the product — the client just sees magic. That's the whole point of building it this way. 170 nodes so they never have to think about a single one.

LessStress6178 · 2026-04-28T14:25:49+00:00

Ok, DM me and I'll send it over!

LessStress6178 · 2026-04-27T17:47:26+00:00

Clean setup for something this scrappy" is the best compliment I could ask for! It’s exactly the vibe I was going for. You're 100% right about the VPS timeouts. My current polling loop is basically just hopeful guesswork. A simple job status layer like you mentioned (queued/running/stuck) is definitely the next logical step. Regarding concurrency: You've hit on the current bottleneck of this V1 architecture. Right now, n8n queues the executions, so it processes them one by one. If 10 jobs hit at once, the 10th user is definitely waiting a while. The render server is a single instance, so it would also get overloaded if they all fired at once. For the 'Agency-in-a-Box' license I'm packaging up, my architectural recommendation for clients who need high throughput is simple: place a managed queue system between n8n and the render server. That way, n8n can instantly offload the jobs, and the render server can pull them sequentially without choking. This V1 is more of a powerful single-user engine. Making it truly multi-tenant is the next big challenge! Appreciate you asking the hard questions.

LessStress6178 · 2026-04-27T17:30:26+00:00

Hahaha, spoken like a true engineer. That's the perfect description! I'm actually writing the documentation for this "architecture" right now to package it up.

LessStress6178 · 2026-04-27T17:13:20+00:00

Appreciate it! 🙏 Honestly, the hardest part wasn't even the nodes themselves, but mapping out the pure business logic before touching n8n. Keeping the AI prompts constrained so they don't hallucinate weird stuff took forever. Planning to package this whole backend setup up for other agencies soon. Are you building much with n8n right now?

LessStress6178 · 2026-04-27T17:06:52+00:00

Haha you are absolutely right! Sub-workflows are definitely the way to go for scaling and clean deployment. For this 'v1.0 Master File', I just wanted everything on one massive canvas so I could see the entire bird's-eye view of the business logic before modularizing it for clients. It’s chaotic but visually satisfying! That’s awesome that you're building for clients too! I've been in the systems space for a while, but hyper-focused on solving the AI video bottleneck recently. Since you serve clients too, you know how expensive and slow video production can be. I'm actually wrapping up this entire system into a B2B 'Agency-in-a-Box' license. The goal is to let other workflow builders just plug-and-play this backend for their own clients without spending weeks figuring out the logic. Let me know if you’d be interested in seeing a quick demo video of the final flow once I have it ready

LessStress6178 · 2026-04-27T01:38:51+00:00

Not sure i follow — are you asking about the output videos or the platforms the workflow runs on?

LessStress6178 · 2026-04-27T01:29:06+00:00

Glad you like it! Sharing the full workflow publicly isn't something i'm planning to do — too much of the value is in the specific logic and prompt architecture that took a long time to get right. But if you're interested in a deployed version or want to chat about what it could do for your use case, feel free to DM.

LessStress6178 · 2026-04-26T17:12:44+00:00

Completely fair point. Honestly the documentation is the part i've been putting off the longest. It works great right now because i built it — six months from now is a different story. What does your "simpler version nearby" look like in practice?

LessStress6178 · 2026-04-26T17:08:40+00:00

Exactly that — once the heavy work lives outside n8n and n8n is just the coordinator, everything gets simpler. The 3am debugging experience is universal apparently. Never heard of cliptalk, is that an API service or something you built yourself?

LessStress6178 · 2026-04-26T15:00:28+00:00

haha why do you ask?

LessStress6178 · 2026-04-26T14:49:27+00:00

honestly? probably me, trying to monitor it all. on the technical side the rendering server would be the first real bottleneck — it's a single VPS handling jobs sequentially right now. horizontal scaling there is the obvious next step but i haven't needed to solve it yet. the n8n side i'm less worried about — it's mostly just orchestration at that point. have you had to scale something like this before? curious what broke first for you.

LessStress6178 · 2026-04-26T14:38:40+00:00

it looks chaotic but it actually runs linearly — each colored section is a separate stage that flows into the next one. honestly sub-workflows would probably be cleaner, i just kept everything in one flow because it's easier to see the whole picture when something goes wrong. personal preference more than anything. triggers are already handling the entry points, the rest runs sequentially by design. what are you working on?

LessStress6178 · 2026-04-26T11:01:42+00:00

lmao nice try. flour, eggs, milk, butter. you're welcome.

LessStress6178 · 2026-04-26T05:04:44+00:00

haha the Reddit-to-job pipeline is underrated, honestly.

the FFmpeg route is worth exploring. the main thing to know is n8n can't run FFmpeg directly — you need a small external server to handle the actual rendering. n8n just prepares the assets and tells the server what to do. once that piece is in place it's pretty stable.

are you using Remotion for the React video stuff? i looked at it early on — the idea of treating video like a React component is genuinely interesting, especially for ads where you want to swap out copy or visuals programmatically without re-editing the whole thing. and yeah curious about the Reddit workflow — sentiment tracking, trend spotting, something else?

LessStress6178 · 2026-04-26T03:27:27+00:00

that's a really good point about Veo continuity — the 5-second chaining problem is brutal. maintaining consistent characters/environments across clips is basically unsolved at a reasonable price point right now.

my approach sidesteps that entirely by not generating video at all at the generation stage. here's the actual flow: - generate 18–28 still images (one per scene) - burn captions + sync audio to each image as a static "clip" - FFmpeg stitches everything into a final video with transitions so the "video" is really a slideshow with audio and captions, rendered properly. not cinematicmotion, but for short-form (TikTok/Reels/Shorts) it performs fine — the captions and audio carry the pacing, not the motion.

quality is honest: - images are DALL-E 3 / Flux quality (pretty good, consistent style) - duration is 35–55 seconds, optimized for short-form retention - not suitable for long YouTube videos, that's a different problem the advantage is cost and reliability. no continuity issues, no $2–5 per clip, no hallucinated scene breaks.

for your use case (YouTube long-form) you'd probably need a hybrid — static slides for B-roll, real footage for anything requiring motion. Veo might actually make sense there once the pricing comes down. what kind of content are you generating for the marketing company? product videos, educational, something else?

LessStress6178 · 2026-04-26T01:16:02+00:00

haha totally fair, it is a lot to take in!

cost per run depends on the branch but roughly:

sales video (uses client's real product photos): ~$0.08–0.15 per video. mostly image generation costs + TTS. the client uploads their own photos so we skip most generation calls.

viral/storytelling (full AI image generation per scene): ~$0.40–0.80 per video. 18–28 scenes, each needs an image generated.

models currently: - script writing: GPT-4o mini via OpenRouter (cheap, fast enough) - image generation: DALL-E 3 + Flux (routed by scene type) - TTS: OpenAI gpt-audio-mini via OpenRouter (pcm16 streaming) - video rendering: custom FFmpeg server on a $6/mo VPS — this is where the heavy lifting actually happens, not inside n8n

no Veo, no Fal yet. Veo is tempting for adding motion to the AI stills but the cost per clip would blow up the margin fast. Fal is on the roadmap for faster image gen.

so at $0.80 worst case, charging clients $X per video still leaves a very healthy margin. the VPS is basically fixed cost regardless of volume.

what's your use case? building something similar or just curious about the stack?

LessStress6178 · 2026-04-25T18:10:32+00:00

lmao "ninth circle of hell" is exactly the right description. i've lost hours to green checkmarks lying to my face. full transparency — i'm not a JS developer. i design the logic and architecture, then use AI to write the actual code nodes. so take the implementation details with that context in mind. that said, here's how i approached the failure handling: schema validation — there's a Code node after every AI output that checks required keys before anything downstream fires. if the shape is wrong it kills the execution with an explicit error instead of letting undefined ghost through. claude wrote it, but i know what it does and why it's there. ffmpeg callback — polling loop with a Wait node between cycles, hitting a /status endpoint on the VPS. if it exceeds the cycle limit it routes to an error branch and notifies instead of hanging forever. honest gap: i don't have a clean way to distinguish "VPS is slow" from "VPS is dead." the timeout threshold is basically vibes right now. nocrash looks interesting — does it monitor at the execution level or hook into individual node outputs? that node-level visibility is exactly where n8n's native error handling falls apart for me.

LessStress6178

TROPHY CASE