DEV Community: Cloudinary

From Cloud to Crowd: Welcome to Cloudinary Creators Cohort 2

eugene musebe — Thu, 24 Sep 2026 15:34:32 +0000

When we launched the Cloudinary Creators Community (CCC), we set out on a clear philanthropic mission: bridging the gap between foundational learning and real-world professional application for early-career, career-changing, and underrepresented developers.

In close grassroots collaboration with our nonprofit partners including GirlScript Foundation, Developers in Vogue, Vets Who Code, Tampa Devs, and HackYourFuture we introduced a guiding vision coined by partner Jerome Hardaway: taking aspiring builders "From Cloud to Crowd." Through dedicated webinars, hands-on coaching, and the Cloudinary Academy, hundreds of talented learners stepped forward to build visual media literacy and take control of their technical journeys.

As our first cohort grew, one lesson emerged above all others: passing a curriculum gives you the foundation, but building, writing, and sharing in public is what transforms a learner into an industry-recognized creator.

Today, we are thrilled to officially unveil Cloudinary Creators: Cohort 2.

Cohort 2 honors our nonprofit roots while completely reimagining the creator journey. We are replacing passive course completion and complex annual point trackers with a transparent, merit-based pathway centered on real execution: Learn, Apply, Build or Write, Showcase, and Contribute.

Why Cohort 2? The Shift from Learner to Creator

In our initial phase, passing the Academy final assessment was treated as the finish line to enter the community. In Cohort 2, course completion is not the finish line. It is where your journey actually begins.

We designed Cohort 2 around four core principles:

Empowering Diverse Builders: Deepening our commitment to underrepresented talent and nonprofit cohorts by offering tangible portfolio-building opportunities rather than theoretical exercises.
Earning Your Stripes in Public: Full creator status, official credential badges, and swag are unlocked when you demonstrate your work in public.
Sustainable, High-Value Contributions: We replaced confusing annual point systems with straightforward, quarterly participation goals that fit busy lives.
Structured Cohort Capacity: Intentional intake caps ensure every single candidate receives direct access to DevRel mentorship, feedback, and career advocacy.

The New 4-Stage Creator Journey

The hallmark of Cohort 2 is a clear progression that guides you from a curious student to an established builder.

Stage 1: Learn + Apply

↓

Stage 2: Creator Candidate (Provisional Acceptance)

↓

Stage 3: Build or Write + Showcase (30-Day Milestone)

↓

Stage 4: Official Cloudinary Creator (Full Benefits & Quarterly Engagement)

Stage 1: Learn + Apply

Everything begins with media mastery. Learners from our partner communities and independent applicants complete the free Cloud to Crowd curriculum on Cloudinary Academy and pass the comprehensive assessment with a score of 80% or higher.

Passing the exam earns an official certification and makes you eligible to apply for an upcoming cohort. However, course completion alone no longer grants automatic membership. Applications are reviewed based on cohort capacity, goals, and alignment.

Stage 2: Become a Creator Candidate

Once accepted, you enter the community under our provisional status: Creator Candidate.

As a Candidate, you gain immediate access to our Discord community space to introduce yourself on the brag board, meet fellow builders, and access team office hours. Most importantly, your 30-day countdown begins to complete your official milestone.

Stage 3: The 30-Day Creator Milestone (Build or Write)

To move from Candidate to full Creator, you must demonstrate how you apply Cloudinary to solve a real-world problem within 30 days. Because developers communicate their expertise in different ways, you can choose between two tracks:

Option 1: Build & Share

Build a functional project solving a practical media challenge using Cloudinary. Share what you built, the media challenge you tackled, how Cloudinary solved it, key lessons learned, and links to your public repository or live demo.
Option 2: Write & Share

Prefer technical writing? Research, write, and publish an in-depth article on your personal blog, DEV Community (dev.to), or another public platform explaining how you solved a real-world media problem with Cloudinary.

Stage 4: Official Cloudinary Creator Status

Once your milestone is reviewed, confirmed, and shared with the community, you officially graduate to a Cloudinary Creator!

Unlocking Full Creator Benefits

In Cohort 2, premium perks are directly tied to completing your milestone and earning full Creator status:

Cloudinary Creators Plan Upgrade: Eligible creators receive a complimentary account upgrade with increased limits and features to host personal portfolio projects and experimental applications.
Exclusive Creator Swag Pack: Custom apparel, stickers, and creator gear delivered directly to your doorstep once your milestone is verified.
Official Badges & Industry Credentials: Digital badges commemorating your educational achievements, milestone delivery, and community contributions.
DevRel Mentorship & Technical Office Hours: Direct access to the Cloudinary Developer Relations team for architectural reviews, troubleshooting, and career advice.
Global Community Network: Direct collaboration with peers and mentors from international partner organizations including GirlScript Foundation, Developers in Vogue, Vets Who Code, and HackYourFuture.

Staying Active: The New Quarterly Model

We have eliminated confusing scoreboards and complicated point tallies. To keep your Creator status active in Cohort 2, members simply participate in at least 2 creator activities per quarter.

You choose the activities that best match your schedule and strengths:

Participate in a Mini-Hack: Join our community build challenges, either solo or with a partner. (1 qualifying mini-hack = 1 activity)
Write a Community Blog Post: Publish a technical guide, tutorial, or project breakdown. (1 qualifying post = 1 activity)
Help Organize a Local Community Event: Support local developer meetups through workshop facilitation, technical talks, meetup planning, or outreach. (1 qualifying event contribution = 1 activity)

Whether you choose two mini-hacks, one article and one event, or two community blog posts, staying active is about meaningful participation that enriches the wider developer ecosystem.

The Face of CCC: Celebrating Our Builders

We want to highlight our creators across the visual web. As part of the Cohort 2 onboarding flow, Creator Candidates and official Creators are invited to upload their professional headshots to Cloudinary and submit their Cloudinary asset URLs. Outstanding builders and milestone projects will be regularly spotlighted across Cloudinary social channels, newsletters, and community showcases. Check out some of our Creators at https://community.cloudinary.com .

How to Get Started

Ready to start your journey from Cloud to Crowd?

Take the Course: Complete the Cloud to Crowd Curriculum on Cloudinary Academy and pass your assessment.
Submit Your Interest: Fill out the CCC Interest Form with your Academy Certificate details.
Build or Write: Once accepted as a Candidate, complete your 30-day milestone and show the community what you can build.

Welcome to Cloudinary Creators: Cohort 2. Let us learn, build, share, and grow together.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

**Meet us onDiscord!

I Built an Agent That Does a Week of Work in One Command

Sharon Yelenik — Thu, 24 Sep 2026 11:43:32 +0000

Agents are here to make work more efficient, but not to take over taste and judgment. Finding the point where an agent can save real time without quietly taking the wheel is harder than it sounds.

The Product Launch Agent below is my attempt at that sweet spot. You can find it here, on GitHub.

It leans on trusted, deterministic tools and human-curated inputs to do a week of work in one command, without taking the wheel.

Build your own product launch agent

Clone the Product Launch Agent repository, connect a Cloudinary product environment, and generate a launch kit from your own approved assets.

In about 15 minutes, you can upload and tag a launch image, let the agent find it, and generate platform-specific image variations and launch content.

The build prompt

I used this prompt to describe the app I wanted to build.


Build a Node.js CLI using the Anthropic SDK and Cloudinary.

The CLI should accept a launch brief describing the product, its key benefits, target audience, campaign strategy, and messaging.

Use an agent to produce:

- Release notes, product documentation, and a blog post
- Social posts for four platforms, each with its own correctly cropped hero image
- An outreach plan and draft direct messages for a list of influencers

The agent should use approved launch assets uploaded to Cloudinary and tagged with a launch identifier. Find those assets, create platform-specific crops and an Open Graph image with a text overlay, and pass the resulting URLs to the content-generation tools.

Never invent or substitute an image when no suitable approved asset is available. Outreach messages must be drafts only and must never be sent automatically.

Save the complete launch kit as a polished HTML report in:

output/<launch-name>/report.html

Note: This prompt is separate from the system prompt that guides the agent at runtime.

The Product Launch Agent

A human team member tags and approves the images, selects the campaign strategy, and writes the messaging brief. The agent finds and formats what was approved. It does not decide what looks good or what the brand should say.

One command produces a blog post, release notes, a social campaign across four platforms, an outreach plan, and drafted DMs to a list of influencers, ready for review. Done manually, this could take a full week:

Your browser does not support the video tag.

The Cloudinary workflow

Before running the agent:

Upload approved launch assets to Cloudinary.
Tag the assets with a launch identifier, such as vesper-no-1.

Then the agent:

Searches for those assets by tag.
Generates platform-specific crops with crop: 'fill' and gravity: 'auto'.
Passes the resulting Cloudinary URLs to the content-generation tools.

Cloudinary handles asset storage, search, transformation, optimization, and delivery. The agent orchestrates the automated operations and assembles the launch kit.

Before you run the agent

Make sure you have:

A Cloudinary product environment and its API credentials.
At least one uploaded image with a launch tag, such as vesper-no-1. See Manage asset tags.
An Anthropic API key.

To try the agent quickly, use one of the sample images included in a new account. In the Media Library, select an asset and choose Metadata > Edit Tags to add the launch tag.

You’re ready when the agent can find your tagged asset and return at least one transformed image URL.

Similar agents you can create

The same pattern can support a real estate agent that formats listings, a support agent that summarizes logs, or an events agent that creates a highlight reel and recap gallery.

Here’s exactly how it works.

The architecture, in one breath

The repository separates the launch brief, agent loop, tools, and report generation:

index.js gets a launch brief from the interactive wizard or a pre-created file. It passes that brief to runProductLaunchAgent() in agent.js, along with Claude’s system prompt and the available tools.

The agent loop decides which tools to call and in what order. Content tools generate the launch materials, Cloudinary tools find and transform the approved assets, and report.js assembles the results into an HTML report.

The main files are:


src/
├── index.js                # entry point
├── wizard.js               # builds the launch brief
├── agent.js                # runs the agent loop
├── report.js               # creates the HTML report
└── tools/
    ├── tool-definitions.js # schemas and routing
    ├── content-tools.js    # content generation
    └── cloudinary-tools.js # Cloudinary operations

Tools give the agent capabilities

Claude can't access Cloudinary or generate content directly. The application gives it tools. Each tool has a name, a description, and a structured input schema that tells Claude what the tool does and what information it requires.

For example, this tool finds approved assets for a launch:


{
  name: 'find_launch_assets',
  description:
    'Find assets already uploaded and tagged for this launch. Call this first.',
  input_schema: {
    type: 'object',
    properties: {
      tag: { type: 'string' },
      resourceType: { type: 'string', enum: ['image', 'video'] },
    },
    required: ['tag'],
  },
}

The description is part of the agent’s instructions. “Call this first” helps Claude resolve the available imagery before requesting content that depends on it.

Creating platform-specific crops

The user uploads and tags the approved launch assets. The agent searches for them, then requests the required transformations from Cloudinary.

generateSocialCrops() applies platform-specific crop settings, so every platform gets a predictable output:


const CROP_PRESETS = {
  instagram_square: { width: 1080, height: 1080, crop: 'fill', gravity: 'auto' },
  x_post: { width: 1600, height: 900, crop: 'fill', gravity: 'auto' },
  linkedin_post: { width: 1200, height: 627, crop: 'fill', gravity: 'auto' },
};

const url = cloudinary.url(publicId, {
  transformation: [
    {
      ...CROP_PRESETS[platform],
      fetch_format: 'auto',
      quality: 'auto',
    },
  ],
  secure: true,
});

gravity: 'auto' helps Cloudinary keep the subject visible when the same source image is cropped into different shapes. fetch_format: 'auto' delivers an efficient format for the requesting browser, while quality: 'auto' balances visual quality and file size. The resulting optimized URLs are returned to Claude, which uses the appropriate image in each piece of launch content.

The agent loop

Claude decides which tool to call next. After a tool runs, its result is added to the conversation history, so Claude can use that result when making its next decision.


const messages = [{ role: 'user', content: brief }];

for (let turn = 0; turn < maxTurns; turn++) {
  const response = await anthropic.messages.create({
    model: MODEL,
    system: SYSTEM_PROMPT,
    tools: TOOLS,
    messages,
  });

  messages.push({ role: 'assistant', content: response.content });

  const toolUseBlocks = response.content.filter(
    (block) => block.type === 'tool_use',
  );

  if (toolUseBlocks.length === 0) break;

  const toolResults = [];
  for (const block of toolUseBlocks) {
    const output = await executeTool(block.name, block.input);
    toolResults.push({
      type: 'tool_result',
      tool_use_id: block.id,
      content: JSON.stringify(output),
    });
  }

  messages.push({ role: 'user', content: toolResults });
}

The two messages.push() calls serve different purposes. The first records Claude’s response. The second records the results of the tools Claude requested. Together, they give Claude the context it needs to choose the next step.

Claude can request several tools in one response. The application runs each one and matches every result to the original request with tool_use_id.

The loop stops when Claude returns a response without any tool_use blocks. That response is the completion signal: Claude has decided it has everything it needs for the launch kit.

Example run

Turn	Claude asks for	What comes back
1	`find_launch_assets`	The launch images
2	`generate_social_crops`, `generate_og_image`	Crop URLs and an Open Graph image URL
3	`generate_blog_draft`	The generated blog draft
4	Plain text; no tools	Final summary; the loop stops

The run that produced the report above made 12 tool calls within the 14-turn limit. The limit prevents the agent from continuing indefinitely if it gets stuck.

Code-Level Safeguards

Prompts guide the agent, but important rules are also enforced in code. For example, content that embeds media can't be generated until the application has attempted to find or upload a launch asset:


const ASSET_STEP_TOOLS = new Set([
  'find_launch_assets',
  'upload_launch_image',
]);
const MEDIA_DEPENDENT_TOOLS = new Set([
  'generate_blog_draft',
  'generate_social_posts',
]);

If no approved image is available, the agent stops rather than inventing one. As the system prompt puts it: “A fabricated image is worse than no image.” The code-level check makes that rule enforceable even if the model misinterprets the prompt.

This is the balance the application is designed to strike: Claude handles flexible orchestration, while the tools and application code control what the agent is allowed to do.

Take it beyond the demo: Elevating taste over execution

If you find the Product Launch Agent helpful, clone the repository and connect it to your own Cloudinary product environment. Start with one tagged image and one launch brief, then expand the workflow as you learn what your team wants to automate.

Try extending the agent

You can extend the same workflow to:

Search by structured metadata instead of tags.
Generate video variations as well as images.
Add automatic format and quality optimization.
Store generated launch assets in a dedicated folder.
Use webhooks to notify the team when a launch kit is ready.
Add an approval step before assets are published.

These extensions turn the demo into a reusable production workflow. Cloudinary handles the repeatable media operations, while the agent orchestrates the work and leaves creative decisions to your team.

Built your own launch agent?

Share what you generated or open an issue in the repository with your results. Tell us which Cloudinary operations you used and what you would like the agent to do next.

Search & discovery (keywords): AI agents Cloudinary; Claude tool use; Anthropic API agents; Cloudinary asset search; Cloudinary image transformations; dynamic image URLs; gravity: auto; crop: fill; agent orchestration; deterministic tools; human-in-the-loop AI; automated content workflows; product launch automation; JavaScript SDK; media asset management.

Cloudinary ❤️ developers
Ready to build an agent that turns approved media into a complete launch kit? Start using Cloudinary for free and automate your image search, transformations, and delivery workflows.
👉 Create your free account

What Does WebMCP Really Unlock?

Ebony Louis — Thu, 10 Sep 2026 17:57:51 +0000

I first started playing around with WebMCP back in March.

The idea immediately made sense to me: instead of forcing an AI agent to inspect a webpage, figure out what everything means, and interact with an interface built entirely for us, the website can expose structured tools that tell the agent what it can actually do.

Fast forward a few months and WebMCP is suddenly everywhere. I've seen demos of agents filling out forms, navigating pages, adding things to carts, and interacting with websites. They're cool demos, but I think there's a bigger idea hiding underneath them.

WebMCP isn't just a better way for an agent to operate a webpage. It gives the website a way to participate in the agent experience.

That means the agent can understand more than the actions available to it. The webpage can also expose the context of the experience we're already in: which product I've selected, which image I'm looking at, which part of the application I'm in, or whether there's a change waiting for my approval.

I wanted to build something that made that relationship visible. So I built a small merchant experience using WebMCP, Cloudinary, and Goose where I can work alongside my AI agent on the same product workflow.

The goal wasn't to see whether an agent could edit an image. We already know it can. I wanted to show what happens when the agent isn't just operating the webpage, but actually understands the experience we're already in.

The Demo

Watch the full workflow above: selecting a product, asking Goose what I'm looking at, searching the Media Library, previewing Cloudinary's edit, and applying it to the storefront.

The merchant workspace is intentionally simple. There are three products, a Media Library connected to my Cloudinary account, and a customer facing storefront.

The webpage exposes WebMCP tools for the things an agent might need to do inside that experience: list products, navigate between sections, understand which product I currently have selected, search my Media Library, select an asset, create an image preview, apply or discard that preview, and publish a new product image.

I started by asking Goose:

Open localhost:8002. Using the WebMCP tools exposed by this page, tell me what products are available.

Goose found all three products.

Then I clicked the Midnight Slip Dress myself. I didn't tell Goose what I clicked or give it a product ID. I simply asked:

What product am I looking at?

It knew.

That sounds like a small interaction, but it's one of the easiest ways to see what WebMCP changes. The agent and I are working against the same webpage and the same state.

From there, I asked:

Take me to the Media Library and find me some other black dress images.

The page navigated to the Media Library and searched my Cloudinary account for matching assets.

Then:

Use the best one. Make the dress blue, put the model in a bright luxury fashion studio, and prepare it for the product grid. Show me a preview, but don't apply it yet.

Cloudinary handled the media work:

Generative Recolor changed the dress from black to blue
Generative Background Replace created the new environment around the model
Cloudinary's transformation capabilities prepared the resulting image for the product grid

But the agent didn't immediately update the product. The page returned me to the product editor with an AI PREVIEW — NOT APPLIED state so I could review the result first.

Once I was happy with it, I told Goose:

Looks perfect. Apply it.

The blue dress was now published on my storefront.

The entire workflow looked something like this:

What's Actually Happening?

The interaction that starts this workflow is the one I find most useful for understanding WebMCP: I select a product myself and the agent knows what I'm referring to.

Normally, if I wanted an agent to modify a particular product, I'd need to give it enough information to figure out which product I meant. I could tell it the name, give it an ID, or, if it has browser access, let it inspect the page and try to determine what I'm interacting with.

WebMCP gives us another option. The page itself can expose that state.

Chrome's WebMCP Imperative API allows a site to register tools using document.modelContext. Each tool can define a name, description, input schema, and JavaScript implementation for an action the site knows how to perform.

In my demo, one of those tools is get_page_context:

await document.modelContext.registerTool({
  name: "get_page_context",
  title: "Get current merchant page context",
  description:
    "Returns the current section of this merchant webpage, " +
    "the product the human currently has selected, " +
    "the selected Cloudinary media asset, and whether " +
    "an unapplied image preview exists.",

  inputSchema: {
    type: "object",
    properties: {},
    additionalProperties: false,
  },

  execute: async () => ({
    currentView,
    selectedProduct: getSelectedProduct(),
    selectedMedia,
    hasPreview: Boolean(preview),
    preview,
  }),
});

When I ask, "What product am I looking at?" the agent doesn't have to infer what I mean from the interface. The website already knows which product I've selected and can expose that information through get_page_context.

The same idea applies to actions. The page can expose a search_media_library tool because it knows how media search works inside this application. It can expose edit_current_product_image because it knows how product image editing works, and apply_current_image_changes because it knows how an approved preview becomes the current product image.

At this point, it's also important to separate what WebMCP is doing from what Cloudinary is doing.

WebMCP provides the context and actions available within the merchant experience. Cloudinary provides the media capabilities behind some of those actions. When the agent searches for another black dress, the search runs against my Cloudinary Media Library. When I ask it to make the dress blue and move the model into a fashion studio, Cloudinary handles the Generative Recolor and Generative Background Replace transformations.

Goose sits between my intent and those capabilities. Instead of giving it a product ID, telling it which functions to call, constructing the Cloudinary transformations myself, and then telling it where to navigate next, I can describe the outcome I want and let the agent use the capabilities the page has exposed.

Technically, I could give an agent direct access to Cloudinary through an MCP server or API and ask it to transform an image. That would still be useful, but it wouldn't demonstrate what I wanted to show here. WebMCP connects those capabilities to the webpage I'm already using, including its current state and the actions that make sense within that experience.

Connecting Your Agent to WebMCP

Exposing WebMCP tools from the webpage is only half of the setup. Your agent also needs a way to discover and execute them.

For this demo, I used Goose as my agent and Chrome DevTools MCP to connect Goose to Chrome.

This part came with a few gotchas that are worth covering because simply connecting Chrome DevTools MCP to your agent doesn't automatically mean you're ready to use WebMCP.

When I built this demo, the configuration that got everything working was:

npx -y chrome-devtools-mcp@latest \
  --isolated \
  --categoryExperimentalWebmcp=true \
  --chromeArg=--enable-features=WebMCPTesting,DevToolsWebMCPSupport

There are a few pieces here worth understanding rather than just copying the command.

--categoryExperimentalWebmcp=true enables Chrome DevTools MCP's experimental WebMCP tooling. This is what gives the agent access to capabilities for discovering and executing the WebMCP tools registered by the active page.

The --chromeArg option passes feature flags to the Chrome instance being controlled by Chrome DevTools MCP. For the Chrome version I used while building this demo, I needed WebMCPTesting and DevToolsWebMCPSupport enabled for the browser side WebMCP integration.

Finally, --isolated isn't a WebMCP requirement. I added it after running into Chrome profile locking issues while repeatedly starting and stopping the demo. It launches Chrome with a temporary user data directory, which made repeated testing smoother.

Note: WebMCP is experimental and this setup is changing quickly. The flags above are the configuration I used for this demo. Check the current WebMCP documentation and Chrome DevTools MCP documentation for the version you're using before setting up your own project.

Once the connection was working, Goose could discover the ten tools exposed by my merchant page:

get_page_context
navigate_merchant_page
list_products_on_page
select_product
search_media_library
select_media_asset
edit_current_product_image
apply_current_image_changes
discard_current_image_changes
set_current_product_status

I intentionally exposed smaller capabilities rather than creating one tool that performed the entire workflow. That gives the agent room to compose actions based on my intent while leaving places for me to participate, like manually selecting a product or approving a generated preview.

One thing that tripped me up while testing: your agent successfully completing a task on your webpage doesn't necessarily mean it's using WebMCP.

In one of my first tests, I asked Goose what products were available and it correctly returned all three. But when I looked at the tool calls, Goose had taken a snapshot of the page and read the products from the interface instead of using the WebMCP tools I'd exposed.

Once everything was configured correctly, I could see Goose discovering and executing the tools registered by the webpage. So if your agent also has browser automation capabilities, don't test WebMCP based only on whether it gets the right result. Check the actual tool calls and make sure it's using the tools your page exposed.

What WebMCP Really Unlocks

Agents could already interact with websites using screenshots, DOM inspection, browser automation, and other approaches. WebMCP doesn't replace any of that. It adds another interaction model: instead of requiring an agent to infer everything about an experience from an interface that was built for us, the website can explicitly describe what it knows and what it can do.

I don't disappear from that workflow either. I select the product myself, let the agent handle the media work, review the result inside the same application, approve it, and let the agent continue.

Not just a website an agent can operate. A shared environment where I can work alongside the agent, both of us acting on the same page state.

If you want to experiment with this yourself, start with the WebMCP documentation, explore Cloudinary's Generative AI transformations, and check out Chrome DevTools MCP to connect an agent to Chrome.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

Automate Cloudinary Image-to-Video Workflows with n8n

Eitan Peer — Wed, 26 Aug 2026 18:44:16 +0000

This n8n workflow automates Cloudinary image-to-video generation from a tagged source image and a prompt. It gives media teams a repeatable no-code process that creates, tracks, and stores the finished video beside its source.

The upload: a 728×546 WebP, 26 KB.

The sentence: Slow cinematic push-in with subtle parallax and slight lateral drift.

The result: the subjects and framing are preserved; the camera does the work.

Watch the real MP4 in the Cloudinary Video Player

Eleven n8n nodes, with no code. The generation call is one HTTP request. The workflow defines which uploads qualify, where the prompt lives, how the asynchronous job is tracked, and how to find the video later.

What you'll build

Trigger Cloudinary image-to-video generation from an upload.
Control eligibility with tags and metadata.
Poll an asynchronous generation job safely.
Tag the source image and return an embeddable video URL.
Import and adapt the n8n workflow.

What decides that an upload becomes a video

Every rule below is a choice this example made, not a requirement of the API. All three live in a single Eligible? IF node, so swap them for whatever your own pipeline keys off: a folder path, an upload preset, a structured metadata field, a public ID prefix, or the uploading user. What matters is that the check happens once, in one place, and that everything failing it stops there.

Field	Condition	Why
`resource_type`	is `image`	Video uploads land in the same notification stream and would otherwise loop.
`tags`	contains `video_gen`	This is the opt-in.
`context.custom.prompt`	is not empty	This is the direction for the shot.

So the interface here is a tag plus a text field. Contextual metadata is editable in the Media Library, in the Upload API, and through the Admin API, so the prompt can come from a human, a spreadsheet, or another workflow. Nobody has to open n8n. If your prompts are house style rather than per-image direction, drop the context condition and hard-code the sentence in the next node instead.

The full prompt value on the image above, second sentence included:

Slow cinematic push-in with subtle parallax and slight lateral drift. Preserve the image exactly—no new objects or altered details.

Everything else is set once, in one node

The remaining parameters are fixed in the request body, so changing the house look for every future video is a single edit. resolution takes 720p or 1080p, duration takes 4, 6, or 8 seconds, and aspect_ratio takes auto, 16:9, or 9:16. The image-to-video API reference has the rest.

{
  "prompt": $json.context.custom.prompt,
  "image_asset_id": $json.asset_id,
  "duration": 4,
  "resolution": "720p",
  "aspect_ratio": "auto",
  "generate_audio": false,
  "enhance_prompt": true
}

How the n8n Cloudinary image-to-video workflow works

The poll loop is the long connector running back from Give Up? to Wait 15s. Everything above that line is the happy path.

Eleven nodes, front to back:

Webhook: Cloudinary POSTs here on every upload. Register the production URL as your notification endpoint once and forget it.
Get Asset: Fetches the full asset record by asset_id. The notification payload is thin; tags and context are read from here.
Eligible?: The three conditions above, combined with AND. The false branch is deliberately unwired; most uploads stop here.
Start Generation: POSTs the JSON above to the image-to-video endpoint and gets back a job_id. Generation is asynchronous.
Wait 15s: n8n suspends the execution rather than holding a worker open.
Poll Job: GETs the job by ID and reads data.status.
Completed?: On completed, go forward. Anything else goes to the give-up check.
Give Up?: Errors out on failed, or when $runIndex >= 20. Otherwise it loops back to Wait 15s.
Stop and Error: Fails the execution with the job ID and last-seen status, so the n8n execution log tells you which asset to retry.
Tag Source Image: Appends video_gen_done to the source image. This is the idempotency marker and the audit trail.
Video Player URL: Builds a Cloudinary Video Player embed URL for the finished asset, muted, looping, and fluid, ready to paste into a CMS.

Watch this line. $runIndex >= 20 in Give Up? is the only thing between you and an infinite poll loop. Twenty polls at 15 seconds is a five-minute ceiling. Raise it for longer clips; do not remove it.

Delivering the result

The generated MP4 is 1.25 MB at source. Adding f_auto and q_auto as the last two components of the delivery URL takes it to 436 KB and lets the CDN pick the codec per browser: AV1 or VP9 where supported, H.264 everywhere else.

# video
https://<cloud>.cloudinary.com/video/upload/c_limit,w_1280/f_auto/q_auto/v1787656854/image-to-video/i2v_9f3d....mp4

# source image
https://<cloud>.cloudinary.com/image/upload/c_limit,w_800/f_auto/q_auto/v1787656781/n8n-demo/couple-meme.webp

# poster frame, pulled from the video at t=0
https://<cloud>.cloudinary.com/video/upload/c_limit,w_1280/so_0/f_auto/q_auto/v1787656854/image-to-video/i2v_9f3d....jpg


MP4 at source	1.25 MB (1280×720, 4s)
With `q_auto`	436 KB, 65% smaller
Poll ceiling	5 min (20 × 15s)
Nodes	11, zero code nodes

c_limit caps the width without ever upscaling, so an asset smaller than the requested width is delivered untouched. Keep f_auto out of named and incoming transformations: format selection has to resolve per request, at the edge.

Or skip the URL building entirely

The last node returns a Video Player embed URL, with the playback options already folded in as query parameters. It is a page you can open, link, or drop straight into a CMS embed field; no <video> element or player script is needed.

https://player.cloudinary.com/embed/?cloud_name=<cloud>&public_id=image-to-video%2Fi2v_9f3d...&player[loop]=true&player[muted]=true&player[fluid]=true

The player[…] keys map one-to-one onto the node's playback and layout fields, so the muted, looping, fluid-width behaviour is configured in n8n rather than in your front end.

Import the n8n Cloudinary image-to-video workflow

Download the workflow JSON and import it through Workflows → Import from File.
Install the Cloudinary node for n8n: in a new n8n flow, search the nodes panel for Cloudinary, select the integration, and click Install node.
Create two credentials and re-select them on the nodes marked REPLACE_ME: a Cloudinary API credential for the three Cloudinary nodes, and an HTTP Basic Auth credential for the two HTTP Request nodes. Its username is your API key and its password is your API secret.
Replace YOUR_CLOUD_NAME in the URLs on Start Generation and Poll Job.
Open Eligible? and set the conditions to your own rules: the tag name, the metadata field, or whatever else decides that an upload should become a video.
Copy the production webhook URL and add it in the Cloudinary Console under Settings → Upload → Notification URL.
Press Cmd/Ctrl+S to save, then activate the workflow. An unsaved workflow will not fire.
Upload an image with the video_gen tag and a prompt context value.

Where to take it

Aspect-ratio presets by tag. Branch on video_gen_9x16 or video_gen_1x1 and set aspect_ratio per branch, so social formats come out of the same upload.
Write the result back. Add a node that stores the video's public ID in the source image's context. The pairing then survives outside n8n's execution log.
Structured metadata instead of context. A structured metadata field gives the prompt validation and a proper label in the Media Library UI.
Backfill. Point the Search API at tags=video_gen AND -tags=video_gen_done and feed the results into the same chain to catch everything tagged before the workflow existed.
Tell someone. A Slack node after Video Player URL posts the player link to the channel that asked for the video.

Get a cloud to run it on

Everything here works on a free account. Sign up, then find the cloud name, API key, and secret on your dashboard. If an agent is doing the setup, it can provision its own environment instead:

npx @cloudinary/cloud

The command writes working credentials to .env with no signup. Delivery is locked to the IP the command ran from, and the cloud expires in 24 hours unless someone claims it with an email address. At that point the same credentials become permanent. The agent quickstart covers the claim step and the IP flags.

Resources

Workflow JSON: Cloudinary — Image to Video (tag: video_gen), import-ready, credentials stripped.
n8n integration: Cloudinary node for n8n: installation, credentials, and supported operations.
API reference: Image-to-video API: every parameter the Start Generation node sends.
Docs: Video optimization · Upload notifications · Video Player embed
Free account: cloudinary.com/users/register_free
For agents: Claimable clouds: npx @cloudinary/cloud, no signup.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

My Agent Built a Paid Media Storefront Before I Signed Up for Anything

Nick Bradley — Wed, 12 Aug 2026 12:53:25 +0000

Here's a build log that would have been impossible a year ago.

I told an agent to clone unshutter and get it running.
It provisioned a Cloudinary Claimable Cloud, a Neon Postgres database and a Stripe sandbox, without me creating a single account.
It configured the media pipeline, then ran a real test purchase end to end: watermarked preview → Stripe Checkout → signed download of the original.
It handed me two claim URLs and stopped.

I claimed the environments the way you review a PR: after seeing the working result.

The storefront is just the demo. What I actually want to talk about is the provisioning.

The one step agents couldn't do

Agents don't evaluate a product the way we do. They don't read the landing page or compare the pricing table. They want to try it: spin something up, build against it, run the result, decide.

Until recently every platform had exactly one step that blocked that: creating the account. A signup form, an email confirmation, a dashboard to fish an API key out of. Ten minutes of human clicking standing in front of hours of autonomous work.

That step is gone across this whole stack:

npx @cloudinary/cloud        # Claimable Cloud → CLOUDINARY_URL in .env, claim URL, 24h
npx neon-new --yes           # Claimable Postgres → connection string, claim URL, 72h
stripe sandbox create        # anonymous sandbox → working test keys

Three commands, no signups, and each one returns working credentials plus a claim link.

Cloudinary's version returns something like this:

CLOUD_NAME=a1b2c3d4
API_KEY=123456789012345
API_SECRET=«redacted»
CLOUDINARY_URL=cloudinary://123456789012345:«redacted»@a1b2c3d4
EXPIRES_AT=2026-08-06T08:29:07Z
CLAIM_URL=https://cloudinary.com/users/agent_email_confirmation?token=«redacted»

It writes CLOUDINARY_URL straight into .env and the whole platform is live from that first call: uploads, transformations, AI add-ons, CDN delivery. There's no trial tier with a queue in front of it.

Two properties matter for what follows:

Unclaimed, it expires in 24 hours. Claiming it (email confirmation on that URL) converts it to a permanent free account, with the same cloud name, the same credentials and every uploaded asset intact.
Unclaimed, media delivery is locked to a public IP, by default the one the command ran from. You can name up to three at provisioning time by repeating --ip, which is enough for your laptop plus a preview host, but not enough for the open internet.

The second one is the interesting bit: the claim is the go-public switch.

The agent's build works from the IPs it was provisioned for. Claiming is the moment it can serve media to anyone, anywhere. That's why the agent stops at a working local site instead of deploying: deploy before claiming and you've published something that looks broken to every visitor but you. Claim, then deploy.

What it built

unshutter (v.: to open the shutters; to let the light in) is a stock-media storefront selling photos, videos and photosets. Next.js 16, Payload CMS, Neon, Stripe, Cloudinary, MIT-licensed. Every mechanic below links to the file that implements it, so you can check my work.

The paywall is enforced by the media layer, not by hiding URLs.

Originals upload as restricted assets, type: private for images and type: authenticated for video (uploadOriginal.ts). The CDN refuses to deliver them unsigned.
With Strict Transformations on, only allowlisted transformations resolve publicly (PreviewImage.tsx is the one component allowed to render them). There's no URL you can craft to get the un-watermarked variant, and what the public can see is deliberately degraded: watermark, q_auto:low, size-capped.
Paying mints a ~10-minute signed download URL (buildDownloadUrl.ts). Stripe's payment record is the entitlement, checked with one live API call per visit (verifySession.ts). No user table, no entitlement table.

Videos lean on e_preview for an AI-picked five-second clip plus six filmstrip stills (videoTransformations.ts). Photosets sell a folder as one product, delivered as a signed, expiring zip that generate_archive assembles on the fly (buildPhotosetZipUrl.ts, ingest script).

It's worth reading even if you never run it:

src/lib/cloudinary/README.md: the honest version of this section. Every named transformation with its exact recipe, why f_auto has to be chained outside the named transformation, and the trade-offs I accepted rather than solved. Every URL builder sits in src/lib/cloudinary/ with unit tests beside it.
docs/ARCHITECTURE.md: how Payload, Neon, Stripe and Cloudinary divide the work, plus src/collections/ for the CMS hooks that upload on save and destroy on delete.
src/site.config.ts and unshutter-tokens.css: rebranding it as your own storefront is those two files and no component edits.

Read the code: github.com/cloudinary-devs/unshutter

Every one of those mechanics is configuration that has to exist inside the media account: named transformations, strict-mode allowlists, delivery types, signed archives. That's the real test of an anonymously provisioned one.

Could it actually do the work?

Provisioning an empty environment is the easy half. The question is whether an agent can stand all that up in one:

It configured the pipeline. Four named transformations created over the Admin API (the watermark chain, OG images, the AI video preview, the filmstrip stills), each flagged allowed_for_strict: true. No console, no clicking.

It verified the security model instead of assuming it. Uploaded test media, then requested a raw original URL unsigned and confirmed the 401. That check matters: if Strict Transformations happens to be off, the watermark is bypassable and everything above is theatre. So the agent proves it and reports what it found.

It ran the money path. Browse → cart → Stripe Checkout with 4242 4242 4242 4242 → webhook → /download → signed URL → un-watermarked original on disk.

Then it stopped and told me what existed and what needed claiming.

All of it ran against live infrastructure rather than mocks. When it needed current facts rather than whatever was in its training data, it read Cloudinary's agent docs and machine-readable llms.txt, the same entry points any agent can load.

Where the human went

	Before	Now
Get three live environments	✋ three signup forms, dashboard key hunts	🤖 three commands, no accounts
Write the credentials into `.env`	✋ copy-paste	🤖
Configure the media pipeline	✋ console clicking	🤖 Admin API
Verify the paywall holds	✋ hope	🤖 tested, reported
Own the environments	✋ first, before a line of code ran	✋ last, confirm an email, ≤24h / ≤72h
Deploy it	✋	✋ your account, your call
Decide it's real money time	✋	✋

Read that middle row on its own: the email confirmation didn't disappear, it just stopped being step zero. Same click, opposite end of the process. By the time you make it, you're confirming something you've already watched work.

The human touches didn't only shrink, they moved to after the work, where they feel like decisions rather than chores. What's left is ownership, infrastructure and judgment, which is roughly what should need a person anyway.

Things that bit us

None of this was completely frictionless but the agent was able to route around it. Some things worth knowing before you try it:

Already have a Cloudinary account to use? You don't have to provision a Claimable Cloud (but you might want to)

Claimable Clouds make it easy to provision a working environment, but claiming one means confirming an email address. If that address already belongs to a Cloudinary account, the claim page rejects it. So a claimable cloud you provision for real work can't be folded into the account you already have.

If you're already a customer, just hand the agent credentials from your own account.

The IP lock surprises you at deploy time

An unclaimed cloud delivers media only to the IPs it was provisioned for, by default just the machine that ran the command. Locally everything is perfect; deploy it and the site is fine for you and broken for everyone else. You can allow up to three addresses at provisioning time by repeating --ip (handy for a laptop plus a preview host, and requester_ip is accepted as a literal), but going properly public means claiming, which lifts the restriction entirely. So: claim before you deploy, and if you're scripting this, have your agent report the claim URL loudly rather than burying it in a summary.

e_preview can't generate on the fly

Request it in a plain delivery URL and you get an HTTP 423 until the derived asset exists. It has to be eager-generated at upload with eager_async: true, plus a signature-verified webhook to flip a previewReady flag when Cloudinary finishes. Also: the source needs to be longer than the excerpt, so a 3-second clip fails silently.

Cloudinary can't POST a webhook to localhost

Which means the "preview ready" callback never lands during local development. Either tunnel (ngrok/cloudflared) or flip the flag manually; the repo does the latter as a documented dev fallback.

Two settings still have no API

Strict Transformations and the AI add-on registrations are account-posture settings you toggle in the console. The add-ons don't block anything: photo ingest retries without them and lands the image untagged. Strict mode does matter, which is why the agent tests for it rather than trusting it.

Try it

Point an agent at the repo:

Clone cloudinary-devs/unshutter and get it running locally, using claimable environments. Don't ask me for credentials, don't deploy anywhere. Give me the local URL and the claim URLs when you're done.

Or run the three commands yourself and follow the quick start.

cloudinary-devs / unshutter

Photography paywall storefront. An open-source showcase demonstrating Cloudinary in a modern full-stack app - Cloudinary + Next.js 16 + Payload CMS + Neon + Stripe + Vercel

unshutter

unshutter (v.): to open the shutters; to let the light in.

A stock-media storefront an AI agent can take from git clone to a running, verified store — media, database, payments — without a single human signup. Every platform in the stack provisions claim-later environments (npx @cloudinary/cloud, npx neon-new, stripe sandbox create), so the human touches move to where they belong: claiming something that already works. Paste the Agent quick start into your agent and watch.

Built on Next.js 16 + Payload CMS + Neon + Stripe + Vercel, with Cloudinary as the media layer. Sibling to kickoff-cards (Cloudinary + Supabase).

Three product shapes:

Photos — browse watermarked, heavily compressed Previews; paying unshutters the image with a time-limited signed link to the full-size Original
Videos — an AI-selected 5-second watermarked, low-res preview clip (Cloudinary e_preview) plus six auto-extracted watermarked stills; purchase…

View on GitHub

The repo ships the guardrails that made agent-building work on a stack this fiddly: AGENTS.md working agreements, a provisioning walkthrough with every human touch called out, and the verified platform facts the implementation rests on. Sibling project, same idea with Supabase: Kickoff Cards.

Further reading: Claimable Cloud provisioning · Agents, start here

Most of the media plumbing is the agent's job now. What was left for me was deciding whether to keep what it built.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

Resize One Image into 6 Social Media Formats Automatically Using Cloudinary Claimable Clouds

Jen Looper — Wed, 05 Aug 2026 21:30:34 +0000

Claimable Clouds are temporary Cloudinary environments for AI workflows that let AI Agents safely manage media with no signup required.

Imagine you're a busy designer, with many satisfied clients who depend on you to take their images and make them look great across social media. All that manual cropping and scaling, it's enough to make a body cry.

On top of that, you know that AI can give you a hand here, but managing the handoff between your AI, your own skilled hands and artistic taste and style, and your always-in-a-hurry client list is another big pain.

Enter the concept of the Cloudinary Claimable Cloud, just released today.

Take a look at the docs about these new temporary instances available now

What we built and why

Provision a disposable Cloudinary cloud with no signup, using npx @cloudinary/cloud
Auto-detect a dropped image and upload it to that temporary cloud
Auto-crop it into 6+ social formats (Instagram, LinkedIn, X, Facebook, Stories) using AI-based smart cropping
Generate a side-by-side gallery of results automatically
Hand off a Claim URL so a client can make the cloud permanent

Now, you can hand off the main pain points to AI - the resizing and reshaping of your images for the various social media platforms, while giving your clients a clean handoff via a temporary Cloud environment that they can use to create a Cloudinary account and start using these assets.

One side effect: this also nudges your whole client base toward the same toolset - Cloudinary. The bigger deal is working with an AI agent that makes your life easier but ALSO allows you to keep control of the output.

Let's walk through how this works! It all boils down to a new command:

npx @cloudinary/cloud

Type that into your terminal to kick off the process.

I built a small app around this concept to provide this AI agent with a simple harness, so let me show how that looks. The user experience is to drop any image you want resized into the /drop folder. Under the cover, there are a few more processes at work:

Provisioning: Spin Up a Temporary Cloudinary Cloud

On the first run, the app spins up a disposable Cloudinary "Claimable Cloud" via npx @cloudinary/cloud with temporary credentials, so no signup is required. The generated credentials are saved temporarily in a .env file locally. This gives the tool a live upload/delivery endpoint without any manual account setup. These credentials are refreshed when you start the app: npm i && npm start.

Watch & Transform: Auto-Crop for Each Social Platform

The app watches the drop folder for new images. When a high-resolution master image lands there, it's uploaded to this temporary Cloudinary instance.

The image we want to resize

Then it's run through a set of predefined social-media format specs (Instagram Square, Portrait, Story/Reels/TikTok, LinkedIn, X/Twitter, Facebook) using dynamic transformations like c_fill,g_auto for smart auto-cropping to each platform's exact aspect ratio and dimensions, focusing on the most important element. Control these formats and transformations in the src/formats.js file:

export const FORMATS = [
  {
    key: 'instagram-square',
    label: 'Instagram Square Post',
    ratio: '1:1',
    width: 1080,
    height: 1080,
    buildTransformation: subjectFill(1080, 1080),
  },
  {
    key: 'instagram-portrait',
    label: 'Instagram Feed Portrait',
    ratio: '4:5',
    width: 1080,
    height: 1350,
    buildTransformation: subjectFill(1080, 1350),
  },
  {
    key: 'instagram-story',
    label: 'Instagram Story / Reels / TikTok',
    ratio: '9:16',
    width: 1080,
    height: 1920,
    buildTransformation: padWithBlurredBackground(1080, 1920),
  },
  ...
];

Render Results & Send to Client: Share a Claim URL

The temporary Claimable Cloud is provisioned using the temporary credentials stored in .env:

// Ensures a usable CLOUDINARY_URL is in process.env, provisioning a disposable
// cloud on demand. Returns { claimUrl } (claimUrl is undefined when a cloud
// was already configured before this run).
export function ensureCloud() {
  loadEnv();

  if (process.env.CLOUDINARY_URL) {
    return { claimUrl: process.env.CLOUDINARY_CLOUD_CLAIM_URL, provisioned: false };
  }

  console.log('No Cloudinary cloud configured yet — provisioning a disposable one (no signup needed)...');

  let raw;
  try {
    raw = execFileSync(
      'npx',
      ['-y', '@cloudinary/cloud', 'create', '--no-agent-metadata'],
      { encoding: 'utf8' },
    );
  } catch (err) {
    const combined = `${err.stdout || ''}\n${err.stderr || ''}`.trim();
    throw new Error(redact(combined) || err.message);
  }

  const values = parseKeyValues(raw);
  loadEnv();

  if (!process.env.CLOUDINARY_URL) {
    throw new Error('Cloud provisioning did not produce a CLOUDINARY_URL.');
  }

  return { claimUrl: values.CLAIM_URL, provisioned: true };
}

Generated variant URLs are written to manifest.json and rendered into an auto-generated side-by-side HTML gallery, which opens automatically. The output also includes a Claim URL, letting the disposable cloud be handed off (e.g., to a client) and made permanent at any time.

The temporary link and generated gallery of images to pick from. Note the fancy Instagram one!

Now you can pass that Claim URL right on to your client and start the process of allowing them to claim the results and start working with them.

This is an early feature, with more agent-based tools coming from Cloudinary soon. Watch for more interesting work around AI agents in the near future!

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

Up and Running with Cloudinary’s Next Starter Kit

Eric Portis — Mon, 03 Aug 2026 22:17:13 +0000

Back in April, we released our React Starter Kit. The React Starter Kit allows you to type one command in the terminal, answer a few questions, and scaffold out a complete, Cloudinary-powered React application, hooked up to all of Cloudinary's latest and greatest tooling for agentic coding workflows.

Today we're releasing a sequel:

npx create-cloudinary-next

If you're spinning up a fresh, media-driven Next.js application, we think typing those 26 characters into your terminal and hitting return is the best way to start.

A quick demo of Cloudinary's Next Starter Kit

Here's a quick example of the kind of app this allows you to quickly prototype.

What Cloudinary's Next Starter Kit actually does

What does the Next Starter Kit actually do?

First, it asks you a few questions about your Cloudinary account and development environment. If you don't have the necessary prerequisites in place, it'll guide you through the process of creating them. Once you do, it records your answers in specific environment variables, configuring your app to work with your Cloudinary account.

Then, it runs create-next-app, installing Next.js and spinning up a working Next app using our starter template. The template includes our Next.js library and demonstrates use of our official Next.js components for upload and delivery, and suggests a handful of prompts to get you started building.

Last, depending which AI coding assistants you told the Starter Kit that you were using during setup, it configures and installs the relevant Cloudinary MCP servers and skills where your assistants can find them.

The end result is a running Next.js app that can upload and deliver media from your Cloudinary account using our official Next.js components, and a development environment primed for prompting.

The Cloudinary Next.js skill

The heart and soul of the agentic story here is our new Next.js skill. The skill is the result of a mountain of user research. Late last year, my colleague Raya Straus spent weeks talking to users, poring over support tickets and error logs, and soliciting reviews from internal experts. The result is a bunch of advice about how to be successful when using Cloudinary generally and our Next.js library specifically, distilled into an installable skill. When paired with our existing documentation and transformation skills, it helps agentic tooling succeed with Cloudinary and catch common errors.

We're excited to launch the skill alongside the Starter Kit, and to keep iterating on both based on automated evals and feedback from users like you.

And you're off

So! if you're prototyping or building a new media-driven Next.js app, start here:

npx create-cloudinary-next

And please, let us know what you think in the comments!

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

No Brief. No Limits. Five Builds Powered by the Cloudinary Skills Pack

eugene musebe — Sun, 26 Jul 2026 19:54:23 +0000

Our last Mini-Hack started with a constraint.

Build something that makes the web lighter, faster, and more sustainable.

For June, we tried the opposite.

No theme. No prescribed problem. No expectation that every submission should look or work the same.

We gave the Cloudinary Creators community a new toolkit, one simple requirement, and as much creative freedom as possible:

Use at least one skill from the Cloudinary Skills Pack and build something real.

Solo or with a partner. Small experiment or ambitious product. Developer tool, creative platform, healthcare app, media editor, or something we had never considered.

The result was five projects that went in five completely different directions.

That was exactly the point.

The Brief Was Almost No Brief

The challenge was called Open Innovation with the Cloudinary Skills Pack.

The instructions were deliberately simple:

Build anything you want.
Use at least one Cloudinary AI skill.
Focus on utility.
Keep the scope manageable.
Show the community what you made.

Creators could submit a live demo, public repository, project write-up, or walkthrough video.

There was no shared industry, audience, or use case. We wanted creators to start with problems they personally cared about, then explore how Cloudinary could help them solve those problems.

Meet the Cloudinary Skills Pack

The Mini-Hack centered on the newly launched Cloudinary Skills Pack, a collection of agent skills designed to help AI coding tools work more accurately with images, videos, transformations, and Cloudinary SDKs.

The pack included three skills:

`cloudinary-docs`

Grounds AI agents in Cloudinary documentation so they can provide more accurate implementation guidance instead of relying on outdated patterns or guessing.

`cloudinary-transformations`

Turns natural-language transformation requests into valid Cloudinary image and video transformation URLs.

Describe what you want, such as removing a background, resizing an image, generating a crop, or applying an effect, and the skill helps translate that request into a usable transformation.

`cloudinary-react`

Provides current Cloudinary React SDK guidance, including component patterns, package usage, and correct import paths.

Together, the skills give AI coding agents a better understanding of how media workflows should actually be built.

Our pitch to the community was simple:

Here is a toolkit for building AI experiences that understand media. Now show us a use case we have not thought of yet.

Support Along the Way

Open-ended challenges create freedom, but they can also create uncertainty.

To help creators move from ideas to finished projects, we hosted a live Office Hours session on Discord. Participants could bring Skills Pack questions, implementation problems, deployment issues, or unfinished ideas.

Community members and mentors worked through errors, discussed project scope, and helped builders polish their submissions before the deadline.

Then came the final push.

Submissions officially closed on July 5.

Participants were competing for:

A Cloudinary swag pack
AI credits for future projects
A featured place in the Cloudinary Community Showcase
Promotion across Cloudinary social channels

Five Projects, Five Completely Different Directions

Removing the theme did not make the projects feel disconnected.

Instead, it revealed what our creators were already interested in solving.

They built media editors, optimization platforms, recovery journals, developer copilots, and branding assistants.

The projects shared the same toolkit, but almost nothing else.

CloudCanvas, by Joyston

What would a Photoshop or Canva-style editor look like if Cloudinary powered the entire media workflow?

That is the question behind CloudCanvas.

CloudCanvas is an AI-powered image editor that runs directly in the browser. It uses a non-destructive, layer-based canvas, allowing users to upload images, generate new visuals, apply edits, and export optimized assets without leaving the application.

Its editing tools include:

Smart Expand
Object Removal
Background Removal
AI Restore
Artistic filters
AI image generation
Optimized media exports

Rather than demonstrating a single Cloudinary transformation, CloudCanvas combines several capabilities into one complete creative workflow.

It was also the first submission we received, setting a strong pace for the rest of the challenge.

Explore the project:

Try the live demo

Snap Optimizer AI, by Aashi

Some projects solve one media problem extremely well.

Snap Optimizer AI solves several.

Aashi built an all-in-one image optimization platform that brings enhancement, editing, compression, resizing, and asset creation into one interface.

Users can:

Enhance image quality using AI
Remove backgrounds
Compress large image files
Resize and crop images intelligently
Generate passport photos
Create profile pictures
Prepare assets for Instagram, YouTube, and LinkedIn
Enter prompts for custom transformations
Compare images before and after optimization

The platform was built with Python, Flask, Cloudinary AI, and the cloudinary-transformations skill.

The skill allows users to describe an intended result in natural language, then helps convert that request into a real Cloudinary transformation workflow.

Snap Optimizer AI stood out because it was not just a demonstration. It felt like a practical tool that creators, marketers, developers, and everyday users could immediately understand.

Explore the project:

Eirene, by Nivrithi

While the other submissions focused primarily on media creation and developer productivity, Eirene applied the technology to a deeply human problem.

Eirene is a postpartum recovery companion built around an often-overlooked reality: while the arrival of a baby is widely celebrated, the mother’s physical and emotional recovery can receive far less attention.

The platform helps mothers document and understand their recovery through:

Week-by-week recovery tracking
Mood tracking
Daily reflections
Personalized affirmations
Recovery milestones
A visual recovery timeline
Photo memories with calming effects

Cloudinary powers the image upload experience and visual effects, helping users preserve recovery memories inside the journal.

The project was built using HTML, CSS, JavaScript, and the Cloudinary transformations skill.

Eirene showed that media tools do not need to be limited to marketing, design, or developer workflows. They can also support reflection, memory, wellbeing, and personal storytelling.

The community response reflected that. As Jen Looper shared during the showcase, this project particularly resonated.

Explore the project:

Try the live demo

CreatorPilot AI, by Ved Prakash Arya

Ved Prakash Arya, founder of Snapforest, built CreatorPilot AI after repeatedly running into the same problem.

Learning and experimenting with Cloudinary often meant switching between documentation, transformation generators, SDK examples, media management tools, and several browser tabs.

CreatorPilot AI brings those experiences into one workspace.

The platform includes:

An AI Documentation Assistant
A Transformation Studio
A React SDK Playground
A Media Manager
An AI Image Generator

It supports workflows such as:

Background removal
Automatic image enhancement
Image upscaling
Generative fill
Background replacement
Object removal

CreatorPilot AI was the only submission to use all three skills from the Cloudinary Skills Pack.

It was built with React 19, TypeScript, Vite, Tailwind CSS, @cloudinary/react, and @cloudinary/url-gen.

The result is part learning environment, part experimentation platform, and part developer productivity tool.

Explore the project:

Brandify, by Princess Bube

Brandify started with a problem Princess had encountered during her consulting work.

Maintaining a consistent visual identity across dozens of images, formats, campaigns, and platforms is difficult, especially when every business has its own branding rules.

Brandify allows a user to upload a brand style guide alongside a collection of images. The platform then generates asset variations that follow the brand’s documented colors, visual direction, and presentation requirements.

Claude reads and interprets the brand guide, while Cloudinary generates the required image derivatives.

Brandify also includes a second workflow for technical content.

Users can upload a draft blog post, and the application scans the Cloudinary URLs embedded inside it. It identifies missing optimizations and rewrites the URLs using Cloudinary delivery best practices.

That combination makes Brandify both a creative branding assistant and a media optimization tool.

Explore the project:

View the GitHub repository

Taking the Projects Live

On July 10, our creators presented their projects during a live judging session streamed across LinkedIn and YouTube.

This was not just a slideshow of finished products.

Each creator walked through the problem they had chosen, how they approached it, where the Skills Pack helped, and what they had managed to build within the challenge window.

The judges evaluated every project using four criteria:

Creativity
Practical usefulness
Effective use of the Cloudinary Skills Pack
Overall execution

The live format gave the broader community an opportunity to watch the demos, ask questions, celebrate the builders, and see what the Skills Pack could enable beyond a standard tutorial.

Missed the session?

And the Winner Is…

For our previous Earth Month Mini-Hack, we celebrated every valid submission without selecting a single winner.

This time, we chose one.

Congratulations to Aashi, winner of the Cloudinary Creators June Mini-Hack for Snap Optimizer AI.

The project stood out for combining an impressive range of genuinely useful features into one polished and accessible experience.

It covered enhancement, compression, background removal, intelligent resizing, social media asset creation, passport photo generation, prompt-based transformations, and before-and-after comparisons.

Most importantly, the project demonstrated how the Cloudinary Transformations skill could move beyond a developer experiment and become part of an experience that real users could immediately understand.

Aashi will receive:

Cloudinary swag
AI credits
A featured place in the Community Showcase
Promotion across Cloudinary social channels

Congratulations on an incredibly well-executed project.

What This Mini-Hack Proved

Our Earth Month challenge showed what happens when you give developers a narrow problem and a clear constraint.

The June Mini-Hack showed what happens when you do the opposite.

Give creators a capable toolkit and enough freedom, and they do not necessarily scatter. They build around the problems they already understand.

A consulting challenge became a branding assistant.

Too many documentation tabs became a developer copilot.

An interest in creative editing became a browser-based media studio.

A need for simpler optimization became an all-in-one image platform.

A deeply personal healthcare gap became a recovery journal.

Five creators started with the same Skills Pack and arrived at five completely different products.

That range is not a side effect of the challenge.

It is the strongest result.

The best way to understand what a new developer tool can enable is often to release it into the hands of builders, step back, and see where they take it.

What’s Next

You probably know how this section ends.

We are doing it again.

The next Cloudinary Creators challenge is already taking shape, and we will share the full details with the community soon.

Until then, explore the projects, watch the judging session, and start thinking about what you might build when the next challenge opens.

Stay Connected With the Cloudinary Creators Community

Applications for the current Cloudinary Creators cohort are now closed, and our focus is on supporting the creators already participating in the program.

You can still follow what the community is building, explore the projects from this Mini-Hack, and stay updated on future challenges and opportunities.

Learn more about the Cloudinary Creators program:

https://cloudinary.com/developers/community

Join our Discord community to meet other builders, get project feedback, and hear about upcoming Mini-Hacks:

https://discord.com/invite/D8ddQj6KnH

Work through the Cloudinary Creators curriculum:

https://training.cloudinary.com/pages/c2c

Explore the Cloudinary Skills Pack:

https://github.com/cloudinary-devs/skills

The next challenge has not started yet.

Your next project can.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

Building a World Cup card battler that turns your selfie into a football card (Next.js, Cloudinary, Supabase, Vercel)

Nick Bradley — Tue, 14 Jul 2026 21:44:56 +0000

The World Cup is on, half my feed is football, and I wanted an excuse to build something. So I built Kickoff Cards: upload a selfie, pick your nation, and you become a playable football trading card that you battle other people's cards with to earn XP and climb a live leaderboard.

The game

The idea is simple: you turn yourself into a football trading card. Think of a Panini sticker or a FIFA Ultimate Team card, except the player on it is you.

You upload a selfie and pick a nation, and a few seconds later you get a card back: your face cut out and dropped into the frame in your nation's colours, with six stats down the side (pace, shooting, passing, and so on) that decide how it performs. There's no signup to get this far; you get an anonymous session on first load and the card belongs to you. Anything you upload is run through automated moderation before it appears in the public gallery.

Then you play it. You send your card into the battle arena, it's matched against another player's, and the two go head to head across those six stats. Winning earns XP, enough XP levels the card up, and a level-up nudges its stats and regenerates the card image to match. A leaderboard tracks who's ahead and updates in real time as battles resolve.

That's the whole loop: make a card, fight with it, level it up, climb the board. It's small, but it touches most of what a real user-media app has to deal with: uploads, AI image processing, moderation, live state, and public content.

The card game is the demo. What this post really focuses on is how the four tools it's built on fit together.

I deliberately chose tooling that works well with agentic development environments: current, trustworthy docs and MCP servers that let the agent check its work against the real project rather than guess from training data. Next.js, Cloudinary, Supabase and Vercel are leaders in this field, and that's a fair part of why this came together quickly. More on that later.

The split is clean: Next.js owns the app, Cloudinary owns media, Supabase owns data, and Vercel ships it, each handing off to the others through stable APIs. It's open source, runs entirely on free tiers. You can play it at kickoff-cards.vercel.app, and the code for you to fork and run yourself: github.com/cloudinary-devs/kickoff-cards

Here's the whole flow on one diagram:

Browser
  │
  ├─ GET page ──→ Next.js Server Component ──→ Supabase (RLS)
  │                                        └─→ Cloudinary URL builder
  │
  ├─ POST /api/sign-upload ──→ signed upload params
  │
  └─ Direct upload ─────────→ Cloudinary
                                  │
                          Async moderation
                                  │
                              Webhook ──→ Supabase update ──→ Realtime ──→ Browser

The rest of this post walks through the decisions behind that diagram.

Why not just store the files?

The first decision was what to do with the uploaded photos. The easy version is: save the file, serve it back, done. That holds up until you actually look at what a card needs: background removal, a face-aware crop, compositing onto the template, text overlays, modern formats, and moderation on anything a stranger uploads. Do it yourself and you're suddenly maintaining a transform pipeline, a CDN, and a moderation step.

I didn't want to build that, so the image work goes to Cloudinary: I describe the transformation I want, get a URL back, and it generates and caches the result on first request. The useful side effect is that a finished card ends up being a single URL with no server-side rendering, which I'll come back to.

Uploads that never touch my server

A lot of upload flows go browser → your server → storage, which means your server parses multipart bodies, buffers files, and streams them back out. Kickoff Cards skips that: the server signs a set of upload parameters, hands them to the browser, and the browser uploads straight to Cloudinary. The only thing my code produces is a signature.

export function getSignedUploadParams({ userId, kind }) {
  const timestamp = Math.round(Date.now() / 1000)

  const publicId =
    kind === "avatar"
      ? `kickoff/users/${userId}/avatar`
      : `kickoff/users/${userId}/uploads/${crypto.randomUUID()}`

  const signature = cloudinary.utils.api_sign_request(
    { timestamp, public_id: publicId, overwrite, moderation, notification_url },
    env.CLOUDINARY_API_SECRET,
  )

  return { signature, timestamp, apiKey, cloudName, publicId }
}

Because the signature covers every parameter, the client can't change the destination path, the moderation settings, the webhook URL, or the overwrite behaviour without invalidating it. You get direct uploads while the server keeps control of where files land.

This is deliberately not an upload preset. Presets work for static config, but they aren't user-aware: they can't carry the authenticated user's ID, a per-request destination, or a dynamic webhook. That gets generated server-side and signed; the browser submits it.

Sessions without signup

That userId in the upload path comes from Supabase. There's no login: Supabase Anonymous Auth gives each visitor a real authenticated session on first load, backed by a cookie and a stable user ID, and their cards, battles, and XP all hang off that ID. Uploads are scoped to it (kickoff/users/{userId}/...), so a card belongs to the right person without any extra plumbing.

It's a reasonable fit for a low-friction demo, and it isn't a dead end: if I later add OAuth or magic links, anonymous is just another provider and the data model doesn't change.

A whole trading card is one URL

The finished card (background removed, face cropped into the window, six stats printed at set coordinates, watermark on the bottom) isn't rendered on a server. No canvas, no image endpoint, nothing written to disk. It's a single Cloudinary URL.

const transformation = [
  { overlay: layerId },
  { effect: "background_removal" },
  { crop: "fill", gravity: "face", width: tmpl.photo.w, height: tmpl.photo.h },
  { flags: "layer_apply", gravity: tmpl.photo.gravity, x: tmpl.photo.x, y: tmpl.photo.y },

  // six stat overlays, one per attribute
  ...STAT_ATTRS.flatMap((attr) => [
    { overlay: { font_family: "Arial", font_size: 44, font_weight: "bold", text: String(stats[attr]) }, color: "black" },
    { flags: "layer_apply", gravity: "north", x: slot.x, y: slot.y },
  ]),

  { overlay: "kickoff:cloudinary-logo", width: 220, crop: "scale", opacity: 55 },
  { flags: "layer_apply", gravity: "south", y: 28 },
  { width: 800, crop: "limit" },
]

return cloudinary.url(`templates/${nation}`, {
  transformation,
  fetch_format: "auto",
  quality: "auto",
  secure: true,
})

Cloudinary runs that chain the first time the URL is requested, caches the result, and serves subsequent requests from the CDN. There's no image-processing server to run.

A few things to watch for:

Order matters. Background removal has to come before the crop. Flip them and Cloudinary crops the original first, then removes the background from that rectangle, which gives a worse result.
gravity: "face" matters. Without it, a full-body selfie tends to crop to the chest rather than the face.
Layer IDs use colons, not slashes. kickoff/users/abc/uploads/xyz becomes kickoff:users:abc:uploads:xyz. Small detail, easy to miss when debugging transformation URLs.
Cache busting is automatic. When a player levels up, I rebuild the URL with the new stats. A different URL is a different cache key, so Cloudinary renders the updated card on the next request, with no purge calls or CDN management.

Every browser-facing image ends with fetch_format: "auto" and quality: "auto", so Cloudinary serves WebP/AVIF where supported and picks a compression level, usually smaller files with no extra config.

One deliberate non-choice: I'm not using next-cloudinary. The card URLs are already complete transformation URLs stored in the database. Plain next/image with unoptimized handles layout, sizing, and lazy-loading, while Cloudinary stays responsible for the media. That's one fewer abstraction between the app and the transformation pipeline.

Moderation on upload

If you accept user images, you need moderation, because some fraction of "selfies" won't be selfies. The DIY version is a vision API plus a queue, retries, and another set of credentials. Cloudinary handles it as part of the upload instead.

Every signed upload carries an AWS Rekognition moderation string:

aws_rek:explicit_nudity:0.4:suggestive:0.4:violence:0.4

After the upload, Cloudinary runs moderation asynchronously and POSTs the verdict to my webhook, which verifies the signature, reads the status, updates the row in Supabase, and deletes anything rejected. The user watches their card flip from Pending to Approved (or get bounced) without refreshing, because that database write feeds a Realtime subscription. That's where Supabase comes in.

Supabase: the right key for the right job

I use three Supabase clients on purpose, and keeping them separate avoids a common class of security bug.

Client	Key	Job
`lib/supabase/server.ts`	Anon	Server Components, Route Handlers, Server Actions (RLS enforced)
`lib/supabase/client.ts`	Anon	Browser Realtime subscriptions only
`lib/supabase/admin.ts`	Service role	Webhooks and privileged server work (bypasses RLS)

The service-role key bypasses Row Level Security, so it lives in one server-only module. If it's accidentally imported into client code, the build fails rather than leaking the key. Two places use it intentionally: the moderation webhook you just saw (which has to delete any card) and battle resolution (the battles table has WITH CHECK (false) on insert, so results can't be written from the client). Everything else runs under normal RLS, which is easier to reason about than one client that's sometimes an admin and sometimes not.

Live updates without polling

Two bits of UI update live: the leaderboard and moderation status. Both use the same pattern: subscribe to a table and let Postgres changes push to the client.

const channel = supabase
  .channel("leaderboard")
  .on("postgres_changes", { event: "*", schema: "public", table: "profiles" }, () => {
    router.refresh()
  })
  .subscribe()

When a battle changes someone's XP, the leaderboard re-renders. When Cloudinary's webhook updates a card, the card page reacts. No polling and no WebSocket server to run yourself:

External service → Webhook → Postgres → Supabase Realtime → Browser

The same shape works for other async work: payments, AI jobs, background processing.

Building this with an agent

Here's the "more on that" from the intro. The reason the stack choice mattered is that all three of Cloudinary, Supabase and Vercel expose MCP servers, so the agent can query the actual project rather than rely on training data. It can browse uploaded assets and test a transformation in Cloudinary, check the live schema and RLS policies in Supabase, and read deployment logs in Vercel. For a media-heavy app that's the difference between the agent guessing and the agent checking: instead of hardcoding a URL and refreshing a tab to see if a transformation worked, it verifies the result directly.

The repo supports this with an AGENTS.md (architecture rules, conventions, and which dependencies move fast enough that it should fetch current docs) and vendored skills under .agents/skills/ for Supabase and Postgres, so it works from current guidance when writing migrations.

Nothing here is agent-specific, really. The same things that make the codebase easy for an agent to work in (clear boundaries, one place per concern, services it can query directly) are what make it easy for a person. The agent just makes it obvious when you've got those wrong.

Run it

git clone https://github.com/cloudinary-devs/kickoff-cards
cd kickoff-cards
pnpm install
cp .env.example .env.local
pnpm dev

You'll need a free Cloudinary account with the AWS Rekognition add-on enabled (the free quota is plenty), a Supabase project with anonymous auth on, and the schema from supabase/schema.sql. For local webhook testing, a Cloudflare tunnel does the job without an account:

cloudflared tunnel --url http://localhost:3000
# paste the HTTPS URL into CLOUDINARY_WEBHOOK_URL

Full walkthrough is in docs/getting-started.md.

What carries over

Aside from the football, these are the patterns that apply to most apps handling user media:

Signed direct uploads. The browser uploads to Cloudinary, the server only signs. The file never passes through your app.

One transformation builder. Keep the transform logic in a single function rather than scattered across components.

Separate Supabase clients. Anon, browser, and service-role as distinct responsibilities, so RLS isn't bypassed by accident.

Webhook + Realtime. External service → webhook → database → Realtime → browser. No polling, and it generalises to moderation, payments, and background jobs.

None of these are specific to a card game, or to this stack. They're just what fell out of giving each service one clear job and letting it do it.

If you want to poke at the code, most of it lives in lib/cloudinary/ and lib/supabase/. It's MIT-licensed, so take what's useful.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

Cloudinary's New Image Generation API: One API, Multiple AI Models, and Built-in Asset Management

Jen Looper — Wed, 08 Jul 2026 13:02:03 +0000

At conference booths, developers often ask whether we support image generation at Cloudinary, given our emphasis on media management. As of now, I can say "YES! yes, we do" - here's how!

Cloudinary's Image Generation API lets developers generate images from text prompts using multiple AI model families, then store the result as a managed Cloudinary asset for delivery, optimization, resizing, and transformation.

Original image copyright © REUTERS/ABC Affiliate WABC

In this tutorial, we'll use Python to call the API, generate an image, and save the final result to Cloudinary.

What you'll build

A Python script that can:

Generate an image from a text prompt
Choose a model family like flux, recraft, gpt-image, ideogram, or nano-banana
Save generated output as a managed Cloudinary asset
Print the final image URL, public ID, size, and file size

Prerequisites

First, follow the instructions on Cloudinary docs to install the image generation add-on to your account. While you're in the Cloudinary console, make note of your API key, secret and the cloud name where you want assets to be stored.

Install the Python dependency:

pip install requests

Export your Cloudinary credentials:

export CLOUDINARY_API_KEY="your-api-key"
export CLOUDINARY_API_SECRET="your-api-secret"
export CLOUDINARY_CLOUD_NAME="your-cloud-name"

Here's your script. Save it as 'generate.py'.

Generate your first AI image

Run the script with a prompt:

python3 generate.py "A medieval monk"

This image was generated with the default Flux model

The script sends a request to Cloudinary's Image Generation API:

payload = {
    "prompt": prompt,
    "model": {
        "family": model_family,
        "tier": tier
    },
    "target": {
        "target_type": "managed_asset",
        "public_id": public_id
    }
}

Then it calls the API using HTTP Basic Auth:

resp = requests.post(
    f"{IMAGE_GEN_BASE}/generate/{cloud_name}/text_to_image",
    auth=(
        os.environ["CLOUDINARY_API_KEY"],
        os.environ["CLOUDINARY_API_SECRET"]
    ),
    json=payload,
    timeout=90,
)

Choose an AI image model

This is the fun part. You can pick the image generation model that best suits your use case. For example, I find that nano-banana works well with images that include text.

You can switch model families without changing the rest of your application code:

python3 generate.py \
  "A futuristic Tokyo skyline at sunset" \
  --model flux \
  --tier premium

Supported model families include:

flux
gpt-image
ideogram
recraft
nano-banana

This was the same prompt, done with Ideogram model

That makes it easier to test different visual styles while keeping one integration path.

Save generated images as Cloudinary assets

The important part of the request is this:

"target": {
    "target_type": "managed_asset",
    "public_id": public_id
}

This tells Cloudinary to save the generated image as a managed asset on your account, instead of returning only a temporary output.

After generation, the script prints something like:

Image ready!
Public ID: generated/fox-hiking
URL: https://res.cloudinary.com/...
Size: 1024×1024 px
File size: 840 KB

Once the image is in Cloudinary, you can resize it, optimize it, crop it, transform it, and deliver it through Cloudinary's CDN. Wicked fast and easy!

Full usage examples

Generate a new image:

python3 generate.py "Marie de France playing pool"

I love this image! Marie de France was a 12th century author of some famous french literature that I particularly like. I don't think she ever played pool, though. Also this pool table is awesomely 'AI-pilled"

Use a premium model:

python3 generate.py \
  "A cinematic product photo of a sneaker floating over water" \
  --model flux \
  --tier premium

Why this is useful

Most image generation APIs return an output.

Cloudinary's Image Generation API returns an output that can immediately become part of your media pipeline.

That means developers can generate an image and then use the same platform to:

Store it
Transform it
Optimize it
Resize it
Deliver it
Reuse it across applications

For apps that already manage media with Cloudinary, AI image generation becomes part of the existing workflow instead of a separate one-off process. The pipeline just got way simplified for you!

Final thoughts

This Python script is small, but it covers the core production workflow:

Authenticate with Cloudinary
Send a prompt to the Image Generation API
Choose a model family and tier
Save the result as a managed asset
Return a usable image URL

If you're building developer tools, e-commerce workflows, campaign generators, or AI-powered creative apps, this approach gives you both image generation and image delivery in the same pipeline.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

Your model returns a file. Production needs an asset.

Nick Bradley — Mon, 06 Jul 2026 13:40:43 +0000

Your agent calls an AI image or video model (OpenAI, Google, Runway, fal) and, a few seconds later, gets back a URL or a blob of base64. Feels like the job is done. It isn't. That raw output will probably expire, it's the wrong size and format for wherever it's headed, it carries no record of what made it, and nobody has checked it against your brand. And because it's an agent, there's no human standing by to fix any of that.

The disappearing URL gets all the attention, but it's only the first of several steps between "the model responded" and "I can ship this." Here's the whole path.

What this covers: what happens when generated media expires across the major APIs, what "production-ready" actually requires (persist, transform, deliver, brand, find), and how to collapse that pipeline into one step.

Step zero: the output is built to disappear

Generated media is ephemeral by default, and the details vary more than you'd expect:

OpenAI: image models like gpt-image-2 return base64 bytes, no hosted URL at all, so you own storage from the first response. Sora video files last ~48 hours (download URLs ~1 hour), and the Sora video API is being sunset in September 2026.
Google: the current image models, Nano Banana 2 (Gemini 3.1 Flash Image) and Nano Banana Pro (Gemini 3 Pro Image), return bytes inline through the Gemini API. For video, Veo 3.1 output is kept two days behind the Files API, then deleted.
Runway: Gen-4 image and video output URLs expire in roughly 24–48 hours; the docs tell you plainly to download and self-host.

This isn't a bug. These are inference platforms, not asset hosts, and serving files forever is expensive. The trap is that "save it before it vanishes" quietly became your job, and most teams only find out when a link 404s in production.

Persistence alone isn't the finish line

The landscape is shifting, to be fair. fal.ai now offers fal Assets, where generations persist instead of expiring, and platforms like Leonardo keep outputs indefinitely. Even routing layers like OpenRouter's Unified Image API give you one endpoint across dozens of models, though as a router it stores nothing, so persistence is still yours to solve.

But solving expiry only solves step zero. A file that lives forever in one vendor's library is still unoptimised, unbranded, scattered across whichever providers you happen to use, and only as findable as that vendor's UI. The hard part was never just keeping the bytes.

Why autonomous agents make media persistence harder

When a person generates an image in a web UI, they're right there to download it, crop it, eyeball the brand, and drop it where it belongs. Agentic workflows delete that entire safety net.

An agent runs in the background. It calls a model, gets a result, and moves on: the output lands in a state object or a database row, and nobody looks until much later. Good agent-state design even says to store large artifacts as files and keep only the path in state. Sound advice, but it assumes the file is somewhere permanent and usable. A raw model URL is neither. So every step a human would have done by hand now has to happen automatically, at generation time. That's the actual job.

What "production-ready" actually means

Strip it back to what has to be true before generated media can ship:

Persisted: captured the instant it's created, so nothing depends on an expiring URL.
Optimised & transformed: the right format and size for each destination. A 4 MB PNG becomes a 40 KB WebP thumbnail, a social crop, an AVIF for modern browsers. Video is harder: transcoding to MP4/WebM, an adaptive HLS/DASH stream, a poster frame, often a trimmed cut, all from one master.
Delivered: served fast from a CDN, video streamed adaptively rather than shipped whole from one region.
On-brand: checked against brand rules before a customer sees it. An agent generating customer-facing media with no brand guardrail is a real risk, not a hypothetical.
Findable: stored with its metadata: prompt, model, use-case, tags, and for video things like duration and captions. An agent that can't search its own output regenerates the same thing twice.

Miss any one of these and you don't have an asset; you have a raw output and a to-do list.

This is really an asset pipeline

Every one of those requirements already exists in traditional media workflows. AI generation hasn't removed the pipeline, it has simply automated the first step. Agents make that more obvious because there's no human left to bridge the gap manually.

Building the media pipeline yourself

The pattern everyone reaches for looks simple:

generate → download the bytes → push to your object store → serve from there

The store is usually S3, Cloudflare R2, or Supabase, and the mechanics are well-trodden. But persisting the bytes is the easy ~60%. What's left on your plate:

Glue code on every generation path, with retries for when the URL expires mid-download (worse for large video files).
A transformation service (Lambda + sharp, imgix) and, for video, a transcoding pipeline (FFmpeg or managed) for streamable renditions and poster frames.
A CDN in front, with adaptive streaming for video.
A brand check, which most pipelines just skip.
A metadata store you build and maintain so assets stay findable.

You can absolutely assemble this, and if storage cost dominates and your transform needs are light, R2-plus-a-Worker is a sensible call. Just be honest that you're now operating a small media pipeline, not a bucket.

Two pipelines, one call

The model step is identical either way. What differs is everything after it.

The generation call below is deliberately abstracted: whether generateMedia() wraps OpenAI, Google, Runway, fal, or an OpenRouter route, you're left holding the same thing: an ephemeral URL you now have to productionise.

The DIY way: download, race the expiry, persist, then start the rest of the pipeline.

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({ region: process.env.AWS_REGION });

const modelOutputUrl = await generateMedia(prompt); // any provider; ephemeral

const res = await fetch(modelOutputUrl);            // race the clock
if (!res.ok) throw new Error(`Model URL expired: ${res.status}`);
const bytes = Buffer.from(await res.arrayBuffer());

await s3.send(new PutObjectCommand({
  Bucket: process.env.S3_BUCKET,
  Key: `generations/${Date.now()}.png`,
  Body: bytes,
  ContentType: "image/png",
}));

// Still TODO, separately: transform/transcode, CDN, brand check, metadata store…

The pluggable way: hand the same URL to a media pipeline and get a production asset back in one call. (This example uses Cloudinary, but the shape is what matters.)

import { v2 as cloudinary } from "cloudinary"; // configured from CLOUDINARY_URL

const asset = await cloudinary.uploader.upload(await generateMedia(prompt), {
  folder: "agent-generations",
  context: { prompt, model: modelName },            // searchable metadata
  eager: [{ width: 400, height: 400, crop: "fill",
            fetch_format: "auto", quality: "auto" }], // optimised derivative
});

asset.secure_url;          // permanent original, CDN-delivered
asset.eager[0].secure_url; // optimised WebP thumbnail

It fetches the bytes (no expiry race in your code), stores a permanent original, derives renditions on demand, and tags it with its metadata. Pass resource_type: "video" and the eager transforms become an adaptive stream and a poster frame instead of image crops. Same call for an image from one provider or a clip from another, and the agent ends up holding one stable, branded, findable URL, no per-model recipe required.

Or generate straight into your asset platform

If the generator and the asset platform are the same system, there's no ephemeral URL to rescue in the first place. That's the idea behind Cloudinary's new Image Generation API: a single text_to_image endpoint across best-in-class model families (FLUX.2, Nano Banana, GPT Image, Recraft, Ideogram), much like the routing layer from earlier, except the output lands as a managed asset rather than a disappearing link.

curl -X POST https://api.cloudinary.com/v2/generate/<CLOUD_NAME>/text_to_image \
  -u "<API_KEY>:<API_SECRET>" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "a golden retriever wearing a tiny astronaut helmet",
    "model":  { "family": "flux", "tier": "premium" },
    "target": { "target_type": "managed_asset" }
  }'

The response is a permanent secure_url plus the asset_id and public_id you use everywhere else in Cloudinary. The image is born persisted, optimisable, and ready to deliver; generation and production collapse into one step. (Omit model for the Nano Banana default; target defaults to a short-lived temporary asset if you'd rather not persist.)

The takeaway

The honest version: if all you need is the cheapest bucket, R2 wins on raw storage cost, and Supabase now bundles basic transforms and a CDN. Reach for a full media platform when the whole job matters (persist, transform, deliver, keep on-brand, organise) and you'd rather make one call than orchestrate five.

But the broader lesson outlives any product choice. In an agentic system, a generated file is an intermediate value, not a deliverable. The model is a component, not the finish line. Treat the path from raw output to production asset as a real pipeline (whether you build it from buckets, workers, transcoders and a metadata table, or hand it to something that does all five) and your agents stop storing links to nothing.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account

I Stopped Choosing Image Models Manually

Ebony Louis — Tue, 30 Jun 2026 16:40:40 +0000

Every few weeks there's a new image model everyone says you should be using: FLUX, Recraft, Ideogram, GPT Image. Each one has different strengths, different tradeoffs, and another decision for developers to make before they've even written a line of code.

So when I started experimenting with Cloudinary's new Image Generation API, I caught myself doing something familiar:

generate_image(
    prompt=prompt,
    model="flux"
)

Then I realized I shouldn't be choosing the model at all.

I've spent the last few years building AI agents that decide what actions to take based on context. They choose tools, call APIs, verify their own work. So I stopped making this decision myself.

The problem with hardcoding models

Most examples, including the ones you'll find in documentation, explicitly choose a model. That makes perfect sense for a quickstart, but production applications don't receive the same prompt over and over again.

One request might be "create a photorealistic product shot." Another might be "design a conference poster with large readable typography." Another might be "generate a hand drawn sketchnote from these lecture notes." You probably wouldn't use the same model for all three. Different models have genuinely different strengths. Some are better at photorealism, others produce stronger illustrations, others handle typography more effectively.

So instead of asking which model I should hardcode, I started asking whether my agent should decide instead.

My first attempt was simple

I wrote a choose_model() function that matches keywords in the prompt to model strengths:

def choose_model_simple(prompt: str) -> dict:
    prompt_lower = prompt.lower()

    if any(w in prompt_lower for w in ["text", "poster", "logo", "typography", "sign"]):
        return {"family": "ideogram", "tier": "standard", "reason": "Prompt likely needs strong text handling."}

    if any(w in prompt_lower for w in ["photo", "realistic", "portrait", "cinematic"]):
        return {"family": "flux", "tier": "premium", "reason": "Prompt is photorealistic, so Flux is a strong fit."}

    if any(w in prompt_lower for w in ["illustration", "sketchnote", "diagram", "vector"]):
        return {"family": "recraft", "tier": "standard", "reason": "Prompt sounds illustration-heavy."}

    return {"family": "nano-banana", "tier": "standard", "reason": "No specific requirement detected; using the default."}

It works for obvious cases. But it breaks the moment prompts get ambiguous, and prompts are almost always a little ambiguous.

The keyword router explains why it selected Ideogram before calling Cloudinary.

Why keyword matching isn't enough

Try this prompt: "A sketchnote of my lecture on photorealistic rendering techniques."

A keyword router sees "photorealistic" and picks Flux. But the output you actually want is an illustration. The word photorealistic describes the subject, not the style.

A keyword router matches words. Your agent understands intent. It understands that the output should be a sketchnote, not a photorealistic rendering.

Swapping in Claude

Replacing the keyword router with Claude is one function change:

def choose_model_claude(prompt: str) -> dict:
    client = anthropic.Anthropic()
    message = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=256,
        system="""You are a model router for an image generation pipeline.
Given a prompt, return ONLY a JSON object:
{"family": "...", "tier": "...", "reason": "One sentence."}
Available families: flux, ideogram, recraft, gpt-image, nano-banana.""",
        messages=[{"role": "user", "content": f'Prompt: "{prompt}"'}],
    )
    return json.loads(message.content[0].text.strip())

The keyword router makes a decision by matching keywords. Claude reasons about the intent of the request before choosing a model.

Notice what changed. The agent isn't generating the image, it isn't replacing Cloudinary. It's making a routing decision. Cloudinary remains the execution layer while the agent decides which model best fits the request. Because Cloudinary exposes multiple model families through the same API, the router only has to decide what to use, not how to call it.

This example uses a small routing script to make that decision explicit, but the same idea applies to larger agent workflows. If you're already building agents, model selection can become just another reasoning step before the API call. I wrote it as a standalone script because it's easier to understand, easier to experiment with, and easier to adapt to your own projects.

What I actually learned

The model choice matters more than I expected. The same prompt can produce very different results depending on which model you pick, and those differences aren't subtle. Text rendering in particular is still surprisingly hard. Generating a beautiful image is relatively easy, but generating a beautiful image with readable text is a different problem entirely.

What I found most interesting was that the routing decision itself was the interesting part, not the generation. Once you separate "which model should I use" from "call the API," that first question becomes something an agent can reason about rather than something you have to answer in advance every time.

Why Cloudinary?

I wasn't looking for another image model. I was looking for a consistent interface to multiple image models. Without that, swapping models means learning new APIs, new authentication, and new response shapes.

With Cloudinary's Image Generation API, the router just returns a family name. Everything else stays the same.

Generated images also land directly in Cloudinary as managed assets, immediately available for transformation and delivery without me needing to do any extra steps.

Try it yourself

If you'd like to experiment with this pattern, I've shared the complete routing script as a GitHub Gist.

The script uses Cloudinary's Image Generation API to select a model, generate the image, and save it as a managed asset.

To get started:

Where I think this is going

Every few weeks there's another model everyone says you should be using.

I don't think any of us will be choosing most of them manually.

We'll be spending more time teaching our agents how to choose instead.

Cloudinary ❤️ developers
Ready to level up your media workflow? Start using Cloudinary for free and build better visual experiences today.
👉 Create your free account