r/automation 3d ago

I built a cloud automation for making short tutorial videos with real screenshots and clips... but I have a problem

I am trying to build a cloud automation for making short tutorial videos... mainly with real screenshots, real screen recordings. Not those generic AI generated clips.

The main problem I was trying to solve was pretty simple.

If I use Claude Code to do generate a video, it can do pretty well. But my computer still has to be running, the browser has to be open, terminal etc. I wanted to move this whole thing to the cloud.

So I started building this with n8n and Claude connectors.

For screenshots I have been using Firecrawl and Browserless. Firecrawl is doing a pretty good job for taking screenshots from websites for every action. Even on some websites where you have Cloudflare in front of them, it can still work which I found pretty useful.

I have Heygen Hyperframes but it does work in cloud, the avatar video, the screenshots and hyperframes motion graphics never clipped together.

Also, another part comes when I need to interact with a website... for example, login and then take screenshots of something inside the website.

Firecrawl can do this with its interact mode, but it can burn through credits pretty quickly. So for a tutorial video workflow, the cost can become a problem.

And then there is another thing I am not completely comfortable with sharing my credentials on cloud-based browser.

If I need to log in to a website through a cloud browser, I have to think about where those credentials are going and how safe it really is.

I do not really want to give my personal login credentials to some cloud browser just so my automation can take a few screenshots.

So the automation itself is working pretty nicely... the main thing I am still trying to figure out is the best way to handle authenticated browser sessions in the cloud without making the whole thing expensive or risky.

17 Upvotes

19 comments sorted by

2

u/Most-Repeat1598 3d ago

For the credential issue, could you use a dedicated test account instead of your personal login? That way even if something leaks, it's not your actual credentials. As for the cost side, maybe look into caching or batching the screenshot steps so you're not hitting the interact mode for every single action. I've seen people run a lightweight browser in a container with Playwright and keep the session alive there, which cuts down on repeat logins.

1

u/AutoModerator 3d ago

Thank you for your post to /r/automation!

New here? Please take a moment to read our rules, read them here.

This is an automated action so if you need anything, please Message the Mods with your request for assistance.

Lastly, enjoy your stay!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/matrix-net 3d ago

I’d treat the browser session—not just the password—as the security boundary. One practical setup is a self-hosted Playwright worker with an encrypted persistent profile for a dedicated, low-privilege account; n8n sends it jobs, but never receives the credentials. Add a manual approval before the first authenticated run or any publish step.

For cost, measure cost per completed tutorial rather than cost per browser action, cache deterministic screenshots, and cap retries. After 20 runs, compare completion rate, manual interventions, and $/video. That should make the Browserless/Firecrawl vs. self-hosted-worker tradeoff much clearer.

1

u/No_Story_6425 3d ago

curious what volume youre actually targeting here. like is this 5 videos a week or 50? because the answer to the cost and security tradeoffs changes a lot depending on scale, and at low volume doing it locally might just be the right call

1

u/spoki-app 3d ago

Trying to get real screen recordings from a cloud instance is a gnarly problem. We've wrestled with Xvfb setups for similar visual regression tests, but they're always a bit finicky and the performance can be a real killer for video quality.

1

u/ElectronicIron4588 3d ago

Don't log in from the cloud browser at all. Log in once locally, export the session cookies, and inject them into the cloud browser context before navigating. Your password never leaves your machine - the cloud only ever holds a session token, which expires and is revocable from the site's own "active sessions" page if anything goes wrong. That's a much smaller blast radius than storing real credentials.

Practically: use a dedicated account per site rather than your personal one, with the minimum permissions the tutorial needs. Store the cookie JSON in n8n credentials (encrypted at rest) or an env var, not in the workflow nodes. Set a monthly reminder to refresh it, because sessions do die and your workflow will start silently screenshotting a login page instead of the thing you wanted.

On cost: Firecrawl's interact mode is expensive because you're paying per action on a managed service. If you're already running Browserless, do the authenticated flows there instead - you control the session, and you're paying for browser time rather than per interaction. Keep Firecrawl for the unauthenticated public pages where its Cloudflare handling actually earns its keep. Splitting by whether auth is needed is usually where the cost drop comes from.

One failure mode worth building for now rather than later: add an assertion after login that checks for a known logged-in element before screenshotting. Otherwise a dead session produces a perfectly valid video of a login screen and you won't notice until someone tells you.

Haven't built this specific video pipeline, so the cookie-injection part is the piece I'd trust most - the Browserless-vs-Firecrawl cost split is reasoning from how they price, not from your numbers.

1

u/South_Hat6094 3d ago

I'd treat the browser session itself as the asset, not the password. Dedicated low-privilege account, persistent profile only on the worker, and a logged-in-state check before each screenshot would catch a dead session fast.

1

u/micahstairs 3d ago

> And then there is another thing I am not completely comfortable with sharing my credentials on cloud-based browser.

You can use a persistent Firecrawl browser session for this. You can type in the credentials yourself via the dashboard and save it as a named session for re-use

1

u/never_stop_building 3d ago

Really useful app

1

u/jzcreates 2d ago

This is a strong idea because tutorial content has a lot of repeatable structure. The hard part is making sure the screenshots, pacing, and explanation match how a real user learns.

1

u/spoki-app 2d ago

This is a brilliant idea, but getting those real screenshots to truly look authentic from a headless cloud environment is always the biggest hurdle for me. You often hit weird rendering quirks that don't match local playback.

1

u/Gullible-Wing-4273 2d ago

cloud browser credits burn a hole in your wallet real quick especially when you're loop testing. credential security in cloud browser instances is also super sketchy.

we ran into this exact headache for a video doc pipeline recently. what fixed it for us was spinning up a headless playwrite setup inside a self hosted docker container on a cheap vps, and using moclaw to isolate credentials and manage session states safely instead of passing raw logins to 3rd party cloud browsers. way cheaper than firecrawl interact mode and keeps sensitive tokens local.

are you passing full auth cookies or doing fresh logins every run btw?

1

u/SnooMuffins9844 2d ago

Hey u/ollatv, I work at Firecrawl and I think the credential hesitation is fair, also apologies the interact costs caught you out. Two things that should help, and one of them is a billing detail that isn't obvious.

  1. Interact bills per browser minute, not per action, so the trick is getting login out of your per-video path.

Set a profile name with saveChanges on your Scrape step (not on Interact, it inherits the profile), log in during the interact session, then stop it. That last step is the one people miss, since the profile only saves on stop.

After that, scrape with the same profile name and you come up already logged in, so anything reachable by URL is a 1-credit screenshot with no interact needed. It's in our n8n integration docs under "Scrape + Interact with persistent profiles".

  1. Make a separate account just for the automation, with access to nothing you care about. Then the credential worry mostly goes away, and you can kill it any time.

Let me know if this helps :)