Moving to the “Brain and Brawn” GCP Architecture - It's a win! Consistency is the only thing that matters in faceless YouTube. Let's be real, the market is competitive these days... The Why: So, my old Hostinger VPS (old haha, I only purchased it in June) setup was hitting a wall. Video rendering is resource-heavy if you didn't know. And when FFmpeg starts crunching a 240-minute ambient track, it eats every bit of RAM and CPU it can find. On a standard VPS, that’s how you get what's known as "Zombie Workflows"... processes that hang, crash, or worse, get stuck in a loop and burn $85 in API credits because of a silent timeout bug. Been there done that. The How: I’m migrating the entire Bot Brewery engine to a decoupled Google Cloud setup: 1. The Brain: n8n running on a lean instance, managing logic and webhooks. 2. The Brawn: Headless Cloud Run workers triggered only when it’s time to render. 3. The Advantage: FFmpeg and ImageMagick now have dedicated (and more importantly) scalable power that doesn't compete with the functioning brain. If a render fails, the Brain stays alive to log it, alert me via Telegram, and restart the job. The Challenges: Migration isn't just copy / paste. I had to learn how to set up a VM (virtual machine) on the google cloud developer console, run some commands I can only describe as "wizard magic" from my local machine and using an archaic system only cavemen know about called PuTTY... It's been a challenge. I've also had to rebuild a lot of the pipeline. This time designing for Idempotency - a term I didn't really understand until recently. But now that I really do, I can make sure that if a render is interrupted at 90%, the system knows exactly where to pick up without wasting credits or time. And it does so in a completely separate environment so the system itself can keep working even if 1 render fails. That's building for scale. Something most n8n users and YouTube 'gurus' don't discuss. So the Result...: The engine is now calm. I can scale from 1 channel to 100 without the infrastructure breaking a sweat.

So I’ll start this thread out with sharing a stupid mistake I made… This one actually hurt a bit. I have an automation that generates YouTube thumbnails. It takes a prompt, sends it to Imagen4, and if Imagen rejects the image (safety filter), I rephrase the prompt with Claude and try again. Then one prompt hit this: Unable to show generated images. All images were filtered out because they violated Google’s Responsible AI practices. Try rephrasing the prompt. (support code: 63429089) In theory the workflow is simple: Take an input prompt Build the Imagen4 payload Generate image Check if an image was returned If yes → extract it, write it to disk, return link If no → rewrite prompt with Claude, retry The workflow was “working”… with one massive, easy-to-miss flaw. The fatal bug: My IF check for “did we get an image back?” wasn’t strict enough. Imagen returns a predictions[0] object even when it blocks the image, and in that case you get raiFilteredReason instead of a usable gcsUri. So I had runs where: - no valid image came back - the workflow routed into the “rewrite prompt with Claude” path - and because the prompt going into Claude could be empty / invalid, it would still rewrite it into something... Which means the system kept looping. No crashes. No obvious red flags. Just lots of Claude calls. Oh by the way, this happened over Christmas so I didn't see it for a few days... I noticed after the fact because Claude usage spiked and I’d burned around $85. Fix #1 — correct “image exists” check I tightened the IF so it only counts as “success” if we have a real GCS path: {{ !!($json?.predictions?.[0]?.gcsUri) && String($json.predictions[0].gcsUri).startsWith('gs://') }} So: True branch = we have a real image to download False branch = filtered / missing output → go to Claude rewrite (And if raiFilteredReason exists, that’s basically a guaranteed false branch.) Fix #2 — cost guard / attempt limiter Even with correct logic, I do not want any expensive step to run forever.

I build done-for-you automation systems for creators and businesses. If you see something in this community and think: “I want this, but I don’t want to build it myself” You can DM me. No pressure. No funnels. If it makes sense, we’ll talk. If not, you’re still welcome to follow along here.

One of the biggest traps in automation is confusing workflows with systems. A workflow: - solves a single task - often works once - usually breaks under real usage A system: - accounts for failure - can be monitored - can be maintained - keeps running when you are not there Most people stall because they keep stacking workflows without designing the system around them. The difference is not tools. It’s thinking in terms of: - inputs - outputs - failure modes - recovery - long-term ownership This is the level I focus on when I build automation. I’ll unpack this more over time as I share real builds.

I’ve spent a long time building automation systems quietly. Pipelines, workflows, content engines, integrations... most of it invisible unless you were inside the project. I decided to open this community for one reason: Real systems are more convincing than explanations. Anyone can talk about automation. Very few people show what it looks like when: - things break - scale introduces new problems - workflows need to be refactored - systems have to run unattended This community is where I’ll document that process at a high level. Not tutorials. Not theory. Just real work, shared openly. I’ll post here when there’s something real to show.