n8n · Async

Image Pipeline

Text and images in, finished assets out. Composed by one model, rendered by another, stored automatically.

n8nCloudflare R2OpenRouterReplicate
Image Pipeline interface
What changed

The same job,
minus the manual part

Switch between how the work ran before, and how it runs now.

  • A prompt written by hand for every asset
  • The render watched, then downloaded
  • The file uploaded to storage manually
The build

How it was
put together

In the order it was built, and why each part exists.

  1. 01

    Intake and upload

    Text and image inputs are received and assets uploaded to Cloudflare R2, so nothing depends on a temporary URL surviving the run.

  2. 02

    Prompt composition

    Claude Sonnet via OpenRouter composes the final generation prompt from the inputs, rather than passing raw user text to an image model.

  3. 03

    Render and poll

    Seedream on Replicate handles generation. The workflow polls for status rather than blocking, so a slow render never holds the pipeline open.

  4. 04

    Store and respond

    Finished images are written back to R2 and the result returned. Failed and processing states are handled explicitly, not treated as success.

The problem with image generation in a pipeline

Generation is slow and unreliable in a way that ordinary API calls are not. A synchronous design either blocks for minutes or gives up too early.

Treating it as an asynchronous job with explicit states is the difference between a demo and something you can run daily.

What we built

A modular workflow with clean node boundaries, environment-secured credentials, custom error handling and a README written for someone else to deploy.

Status checks return processing, failed or succeeded, and each is handled rather than assumed.

3

Services orchestrated as one job

Async

Polled, never blocking

~0.6s

Typical status check

Next

Want something
like this

The first call is a conversation about your process, not a pitch.

Next case studyVape BrothersShopify · Pakistan