DEV Community: Cloudinary

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

Automate Your Media at Scale: 6 Cloudinary Workflows You Can Import Into n8n Today

Eitan Peer — Wed, 17 Jun 2026 12:58:22 +0000

Media is where automation pipelines quietly fall apart.

This post walks through six importable n8n workflows, built on the Cloudinary community node, that hand those media steps back to the pipeline.

You've wired up a beautiful no-code flow — a new product lands in your PIM, a webhook fires, records sync. Then someone has to resize the hero image for the storefront, cut the launch video into a square for the feed and a vertical for Reels, export a poster frame, and add captions for accessibility. So the "automated" pipeline stops and waits for a human with Photoshop and a video editor.

The Cloudinary community node for n8n just closed that gap. The latest release turns Cloudinary's transformation, delivery, and video player engine into native n8n steps, so media work becomes just another node in the flow.

Below are six ready-to-import example workflows — two clicks to load — designed to run on a free Cloudinary account, subject to usage limits (credits, video processing, and some add-ons count against your plan). Each one is self-describing (every workflow ships with a sticky-note README inside n8n) and contains no credentials — you add your own. Each one below links straight to its JSON.

💾 One-time setup gotcha worth knowing up front: after you import a workflow and pick your Cloudinary credential on the first node, press Cmd/Ctrl+S to save before running. That single save persists the credential to every Cloudinary node in the flow at once — so a full Execute Workflow run finds credentials everywhere. Skip the save and the run can fail node-after-node with "Node does not have any credentials set," even though the credential looks selected. (More in Add your Cloudinary credentials.)

What you'll build

One master video cut for every social platform
Uniform, AI-filled catalog images at scale
A paste-in responsive srcset
An embeddable, adaptive video player
An automated media-library governance audit
Accessible video with AI-generated captions

What's new in the Cloudinary n8n node

The release adds three things that matter for automation:

1. A Transform resource that builds delivery URLs — with no upload and no API call. Optimize, Resize and Crop with an additional conversion option for images and trimming and thumbnails for video. Each operation returns a finished secure_url and a reusable transformation string. Because they're pure URL construction, they're instant and free of round-trips.

2. Transformations that compose three ways.

Compose: Combine Transformations chains several steps (trim → crop → optimize) inside a single node.
Continue From Transformation chains steps across nodes — wire one node's transformation output into the next node's input and they compound into one URL.
And the same transformation string drops straight into the Video Player widget.

3. Advanced media features — no code required:

Generative Fill — extend an image to a new shape with AI-painted background instead of cropping.
Video Player widget — generate an embeddable player with HLS adaptive streaming (and an MP4 progressive fallback), a poster, picture-in-picture, and on-demand AI captions, transcripts, and chapters.
Asset Search — paginate through all matching assets, one n8n item per asset, for governance and audits.

Now let's put them to work.

1. One source video → a cut for every platform

The problem: marketing ships one master video. It needs a 9:16 for TikTok/Reels, a 1:1 for the feed, and a 16:9 for YouTube — each trimmed, each with a poster frame, each optimized. Today that's a manual export-fest.

The workflow: 01-social-video-variations.json

Upload the master once, then three Compose: Combine Transformations nodes each build a single delivery URL that trims → crops to the platform's aspect ratio (with auto-focus to keep the subject in frame) → auto-optimizes. A matching Video: Thumbnail generates each poster. A final Code node collects everything into a tidy list of {platform, video_url, poster_url}.

The win: one trigger produces every platform's asset, ready to hand to a social scheduler or CMS. Add a platform by copying a node and changing one aspect ratio.

2. Bulk product photos → uniform, AI-filled catalog images

The problem: product photography arrives in every shape and on every background. Your storefront wants identical, square, optimized product images for thousands of SKUs.

The workflow: 02-ecommerce-image-pipeline.json

For each product, the flow ingests the photo, then runs Image: Crop with Generative Fill — instead of cropping the product, Cloudinary extends the canvas to a perfect 1200×1200 square and paints a matching background with AI (guided by a prompt like "clean seamless studio background"). It then chains a Convert → WebP step onto that same transformation. Out comes one catalog-ready URL per product.

The win: consistent, optimized product imagery with zero designer time — and it scales to your whole catalog by swapping the input list for a Cloudinary Search or a PIM lookup.

Generative Fill is a generative-AI effect: it uses a special transformation count, is subject to your plan limits, and may render asynchronously on the first request. Create a free account to try it.

3. One image → a responsive srcset you can paste into any page

The problem: you're still hand-exporting @1x/@2x assets, and shipping desktop-sized images to phones.

The workflow: 03-responsive-srcset.json

Point it at one source image and a list of widths. It builds an Image: Resize URL per width (using Limit fit so it never upscales), chains Optimize (f_auto/q_auto) onto each so Cloudinary serves AVIF/WebP/JPEG per browser at the right quality, and assembles a ready-to-paste <img srcset=…> block.

The win: crisp Retina displays and lightweight mobile loads from a single asset — with the markup generated for you. Change a breakpoint by editing one array.

4. A source video → a polished, embeddable player

The problem: putting a real video player on a landing page or CMS usually means a JS build step and a streaming setup.

The workflow: 04-embeddable-video-player.json

The flow trims a preview cut, grabs a matching poster frame (chained onto the trim), and generates a Video Player embed with HLS adaptive streaming and an MP4 progressive fallback, picture-in-picture, playsinline, and muted autoplay-on-scroll. It outputs both an embed_url and a responsive <iframe> snippet.

The win: a production-grade, adaptive player as a paste-in snippet — no front-end code.

The workflow feeds the player the trim transformation, not an optimize one — adaptive streaming (HLS/DASH) can't be combined with a format-pinned transform (f_auto:video). Helpfully, the node catches that exact conflict and tells you how to fix it.

5. Audit and govern a sprawling library — automatically

The problem: at scale, media libraries rot. Untagged assets, oversized files, content nobody owns. Cleaning it up by hand doesn't happen.

The workflow: 05-asset-governance-audit.json

Asset → Search Assets with Return All paginates through all matching assets (it handles pagination and surfaces rate-limit errors clearly), emitting one n8n item per asset with its tags. The template is scoped to tags=n8n-blog so it's safe to run as-is — change or remove that expression (e.g. folder:products/*, or leave it empty) to scan more broadly, up to your whole library. A Code node applies your governance rules — here, flag anything untagged or over 1 MB. Flagged assets get a needs-review tag appended (existing tags preserved); everything rolls up into an audit report you can send to Slack or email.

The win: continuous, policy-driven hygiene that works identically on 50 assets or 50,000. Swap the tag action for structured-metadata updates or (carefully) deletes.

6. Accessible video with AI-generated captions — no .vtt files

The problem: captions are often required by accessibility standards and regulations (such as WCAG, the ADA, and the European Accessibility Act), and a global audience needs subtitles in several languages. Authoring caption files for every video, by hand, doesn't scale.

The workflow: 06-accessible-video-player.json

This is the workflow that shows what Cloudinary's video features can do. The Video Player node ships an accessibility-first config — keyboard controls on, no autoplay-with-sound, playsinline, chapters button visible — plus an AI-Generated Content section that's just a set of toggles:

Generate Captions → the player auto-generates a transcript and shows it as toggleable captions.
Generate Title / Description / Chapters → AI-generated metadata and chapter markers for navigation.

These are enabled by default on most accounts, so there's nothing to switch on. The player only generates content that doesn't already exist, returning a 202 while it works and caching the result. Nobody writes a caption file: no code is needed to generate captions — the workflow's Code node only formats the player embed snippet.

Need subtitles in other languages? Set Subtitle Languages (e.g. es, fr-FR) for auto-translated tracks. Translation uses the Google Translate add-on: register for it (free tier available) on the Cloudinary Add-ons page, then enable it under Settings → Security → Unsigned add-on transformations. The original-language captions above need no add-on.

The win: videos with dialogue can get captions, chapters, and optional translated tracks automatically — as part of the same flow that published them, with no caption files to author.

Auto-generation lives in the player's JS config (not iframe URL params), so this workflow outputs a player.source(...) snippet for the Cloudinary Video Player SDK. On most accounts the unsigned actions for generating video details, transcripts, and chapters are enabled by default — see the customization docs.

How to import these workflows

Every workflow is a single .json file — each section above links straight to it. Importing one takes a few seconds.

1. Install the Cloudinary node (once)

Follow these instructions to install the Cloudinary community node (n8n-nodes-cloudinary).

2. Import the workflow

Open the workflows list, click the ⋯ menu (top-right) → Import from File…, and select one of the .json files. (You can also drag the file onto the canvas.)

The workflow opens with its sticky-note README already on the canvas explaining what every node does.

3. Add your Cloudinary credentials

The templates contain no connection details — they're yours to add.

First, create the credential once: in the Credentials sidebar → Add Credential → Cloudinary API, and paste your Cloud name, API Key, and API Secret from the Cloudinary Console → API Keys. Save it. Now it's offered in the dropdown on every Cloudinary node, in this template and every one you import later.

Then, on the imported workflow, open the first Cloudinary node and pick that credential from the Credential dropdown. n8n back-fills the other nodes that share it — you'll see "Added this credential to N other node(s)."

💾 Then save before you run — this is the important bit. Press Cmd/Ctrl+S right after picking the credential. The save persists the binding to every Cloudinary node at once, so a full Execute Workflow run finds credentials everywhere.

If you don't save first, the full run can fail one node at a time with "Node does not have any credentials set" — even though the credential clearly looks selected on the node. (Tell-tale sign: running a node on its own with Execute step works, but Execute Workflow fails.) A save fixes it in one shot.

4. Run it

Click Test workflow. The first few workflows upload a public Cloudinary demo asset into your account so everything downstream resolves against your cloud — so they run out of the box, then become yours the moment you point them at your own media.

Where to take it next

These six are starting points, not end points. Because every Transform op emits a reusable transformation string and every node speaks plain n8n JSON, you can drop these media steps into any pipeline:

Trigger the social-variations flow from a webhook when a new video lands in your CMS.
Feed the e-commerce pipeline from a Google Sheet or your PIM.
Schedule the governance audit to run nightly and post the report to Slack.
Chain the player + AI-captions flow onto the end of any video upload.

Install the node, import a workflow, and let the media steps run themselves.

Which Cloudinary feature are you missing in the n8n integration? We're actively expanding the node — tell us what you'd build next by opening an issue on GitHub or reaching out through Cloudinary Support.

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

👉 Get the node: n8n-nodes-cloudinary on npm
👉 Request a feature / report a bug: GitHub issues
👉 How to import a workflow: n8n's import & export guide

What Makes An Agent Loop Useful?

Ebony Louis — Fri, 12 Jun 2026 19:32:34 +0000

Over the last few days, my feed has been filled with posts about agent loops.

The message is usually some variation of the same idea: stop prompting agents one step at a time and start designing systems that can act, evaluate their work, and continue toward a goal on their own. The future isn't us prompting agents all day. It's us designing loops that can keep making progress while we're doing something else, or even while we're asleep.

That's old news.

What I didn't understand was which parts of the loop actually mattered.

Was it the model? The tools? The memory? The trigger? The fact that it could run unattended?

Most of the examples I found explained the concept. Few explained how to think about designing one. And even fewer showed what happened when things went wrong.

So instead of reading another post about loops, I decided to build a simple one.

Using Claude Code, Cloudinary Skills, and Cloudinary MCP servers, I created a media optimization loop with a simple objective: reduce delivery weight for image assets by at least 20%.

There was only one question left to answer:

What Makes a Loop Useful?

Not every automation is a loop.

A useful loop needs a few things working together:

If one of those pieces is missing, the loop will start to break down.

Without a trigger, nothing starts. Without a goal, it doesn't know what success looks like. Without knowledge, the agent guesses. Without actions, it can only make recommendations. Without memory, every run starts from scratch. Without verification, it's very difficult to know whether the loop is actually making progress or simply producing output that looks reasonable.

That last point ended up becoming the most important lesson of the entire project. Of the eight pieces in that circle, one short chain running through the middle of it is what actually determines whether the loop succeeds. We'll dive more into that later.

The Goal Layer

Everything started with a simple goal:

Reduce image delivery weight by at least 20%

That objective determined what success looked like and ultimately drove every decision the loop made.

At first that sounds obvious. It wasn't. Later in the project I discovered that a surprisingly large amount of loop behavior comes down to how clearly you define the goal in the first place.

The Knowledge Layer

The agent needed both Cloudinary knowledge and knowledge about how the loop itself should operate.

I didn't want it guessing transformation syntax, trying to remember optimization best practices from training data, or inventing its own workflow every time it ran.

To solve that, I used Cloudinary Skills alongside a custom loop skill.

The Cloudinary Skills acted as the domain knowledge layer. In this case, the transformation focused skill provided guidance on optimization strategies, transformation syntax, and Cloudinary best practices so the agent could make informed decisions without relying on memory or assumptions.

The custom loop skill defined the workflow itself. It told the agent how to read the goal, inspect memory, evaluate results, update state, and decide whether the loop should continue or stop.

Instead of telling the agent exactly what to do at every step, I gave it both reusable Cloudinary knowledge and a reusable workflow. The loop could then reason about the problem, take action, evaluate the outcome, and decide what to do next.

The Action Layer

Knowledge alone isn't enough. If the loop is going to do real work, it needs the ability to interact with your environment. That's where Cloudinary MCP servers came in.

The Asset Management MCP server allowed the loop to discover image assets larger than 1 MB, inspect their metadata, and prioritize the biggest optimization opportunities first.

The Environment Configuration MCP server allowed the loop to create reusable named transformations when it identified optimization patterns that could be applied across multiple assets. Rather than repeatedly generating the same transformation logic, the loop could register and reuse optimization strategies across future runs.

Together, the Skills and MCP servers gave the loop both knowledge and action. The Skills helped the agent reason about what should happen. The MCP servers allowed it to actually do it.

What struck me most wasn't any individual MCP call. It was watching the loop move from reasoning to action. It wasn't simply recommending optimizations anymore. It could inspect my Cloudinary account, identify opportunities, and make changes based on what it found.

The Memory Layer

The loop also needed a way to remember what it had already done. I used a simple memory file that tracked:

Assets already evaluated
Previous run summaries
Named transformations that had been created
Current loop status

This allowed future runs to pick up where earlier runs left off rather than starting from scratch every time. The agent could see what had already been processed and focus only on remaining work.

With the goal, knowledge, action, and memory layers in place, the loop could do real work and remember what it had done. What it couldn't yet do was tell whether that work was any good.

The Evaluation Layer (Where I Got It Wrong)

The first version of the loop looked successful.

It analyzed assets, generated optimization strategies, and reported an average savings of nearly 68%. If I had stopped there, I probably would have considered the project finished.

The problem was that those savings were estimates. The loop wasn't actually verifying its work. It was looking at dimensions, formats, and known optimization patterns and making educated guesses about how much optimization should be possible. The numbers looked reasonable.

Here's what was actually going on. My original loop instructions told the agent to evaluate whether an optimization met the savings target, but never specified how. So the agent did what any reasonable agent would do when given an ambiguous instruction: it estimated. It knew the typical savings associated with common optimization strategies and used that knowledge to produce a confident sounding number.

The fix wasn't a smarter model. It was a more precise instruction.

I added one section to the loop command:

## Step 8 — Evaluate results

For each asset processed, determine:
- Estimated or measured optimized size (bytes)
- Percent savings = (original - optimized) / original × 100
- Did this asset meet the target savings threshold?
- Confidence level: high (measured), medium (estimated from known asset type),
  low (estimated with significant uncertainty)

That's it. I didn't tell the agent how to measure anything. I just told it that "estimated" and "measured" were different things, and that it needed to label which one it was giving me.

That single instruction changed the entire run. The agent started actually fetching the optimized URLs and comparing real byte sizes against the originals, because it now had to be honest about which category its number fell into.

Verification Changed Everything

Here's the same batch of assets, estimated savings versus measured savings, after I added the evaluation step:

Almost nothing landed where the estimate said it would.

The kitten GIF is the headline number: predicted at 70%, measured at 0%. I dug into it and found the test request wasn't negotiating WebP correctly, which caused Cloudinary's automatic format selection to fall back to GIF delivery. The optimization strategy wasn't wrong. The measurement exposed a gap between what should happen and what actually happened on that request.

But the GIF isn't the real story. Look at food/spices: estimated at 30%, measured at 61.3%. Look at breakfast: estimated at 53%, measured at 77.3%. These weren't close. The agent's estimates were off by 5 to 31 percentage points, in both directions, across almost every asset in the batch.

That's the part that actually changed how I think about this. The estimates weren't imprecise. They were unreliable, and not in a way you could correct for with a fudge factor, because sometimes the real number was way better than predicted and sometimes it was worse. Without verification, there was no way to know which assets fell into which bucket. The loop would have reported a single confident average and moved on, and I would have believed it.

With the Step 8 instruction in place, the loop now generates optimized Cloudinary URLs, requests the transformed assets, measures the actual delivered byte sizes, and compares those against the originals, flagging low confidence results so I know where to look first.

The Loop Was Right. I Was Wrong.

After the first run with real measurements, the loop reported that seven eligible assets still remained.

My first reaction was, why didn't it keep going?

I went back and looked at the goal. The goal wasn't:

Optimize every asset larger than 1MB.

It was:

Reduce delivery weight by 20%.

Those sound similar. They produce completely different behavior.

By the time the loop stopped, the measured average savings across the assets it had processed was already well past 20%. The goal had been met. From the loop's perspective, the work was done. Processing the remaining seven assets wouldn't have made the result any more true.

The loop wasn't confused. I was.

I had written down one goal and was carrying around a different one in my head. The loop followed the one that was actually written down, the one it could check against a real number. It stopped exactly when it was supposed to.

A loop will faithfully pursue the goal you define, not the goal you intended.

The Chain That Was Actually Doing the Work

Looking back, the GIF that measured 0% and the seven assets the loop left alone are the same lesson told twice.

Earlier I showed the eight pieces a useful loop needs: trigger, goal, knowledge, action, evaluation, memory, decision, repeat. That's the architecture, the parts you need to assemble. But it's not the part that actually drives progress toward the goal. That part is smaller:

If the eight pieces is the architecture, this is the engine. Everything else in this project, the trigger, the Skills, the MCP servers, the memory file, exists to support this chain. But this is the part that makes something a loop instead of a script that runs once and reports back.

A script can do the Action step. Only a loop can do Measure → Verify → Decide, and use the answer to decide whether to repeat. The measurement gave the loop a number in the same units as the goal. Verification was the comparison between that number and the target. Decision was what the loop did with the answer, stop, because the goal was met, even though work remained.

Take away the measurement, and the loop has nothing to verify. Take away verification, and the decision is just a guess wearing a confident tone. Take away the decision, and you have an agent that acts but never knows when to stop.

The Loop, In Practice

Stepping back, here's what each layer actually was in this project:

Trigger: a command I run manually in Claude Code
Goal: a markdown file stating the target savings percentage
Knowledge: Cloudinary Skills and a custom loop skill, so the agent didn't have to guess either Cloudinary best practices or the workflow itself
Action: Cloudinary MCP servers, so the agent could inspect and modify a real account
Memory: a JSON file tracking what's been done and what's left
Evaluation: a comparison between the original and optimized byte sizes, measured against the goal
Decision: the agent comparing the evaluation result to the goal and deciding to stop, continue, or flag for review

None of these layers are exotic. A markdown file, a JSON file, and two categories of tooling Cloudinary already publishes. What made it a loop wasn't the sophistication of any single piece, it was that each layer fed the next one something real, and that the chain in the middle, Measure → Verify → Decide, was actually wired up.

What I Didn't Build (Yet)

This is intentionally a small loop. It doesn't use subagents, worktrees, or orchestration frameworks.

Those things help loops scale, run faster, or handle more complexity, but they aren't what make something a loop in the first place.

The trigger is also still manual. I start the loop by running a command in Claude Code, and in a production version I'd likely replace that with a schedule or an event such as a new asset upload.

In other words, this isn't yet the "run while I sleep" version of a loop that many people are talking about. It's a deliberately small implementation designed to answer a simpler question:

What actually matters when you're designing a loop?

If you'd like to explore the implementation yourself, I've shared the files used in this experiment:

Closing Thoughts

Going into this project, I wanted to understand what actually matters when you're designing an agent loop.

I thought the answer might be the model, the tools, the memory layer, or the fact that the loop could run unattended.

What I learned was that those things matter, but mostly because they support something else.

A useful loop needs a clear goal, a way to measure progress against that goal, and a way to decide what to do next based on the result.

The GIF that measured 0% savings and the seven assets the loop left untouched both pointed to the same lesson: a loop is only as useful as its ability to determine whether it's actually making progress toward the objective it was given.

Everything else, including tools, MCP servers, Skills, subagents, and orchestration, helps a loop scale. What makes it useful is its ability to measure progress against a goal and use that information to decide what to do next.

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

5 Projects, 2 Weeks, 1 Goal: Building a More Sustainable Web

eugene musebe — Tue, 02 Jun 2026 11:59:23 +0000

Developers talk about sustainability all the time. They talk about it at conferences, in Twitter threads, and in GitHub issue comments. What they do less often is build something about it.

That's what we asked our Cloudinary Creators community to do.

April is widely celebrated as Earth Month, so it felt like the right moment to point that energy at something developers actually have control over: the weight of the web. Digital weight is a real problem, and optimization is still too often treated as an afterthought. We launched the Mini-Hack: Build a Mindful Digital Future, a two-week challenge centered on one idea: the web is heavier than it needs to be, and smarter media delivery is part of the fix.

We wanted to see how developers would use Cloudinary to make digital experiences faster, lighter, and more sustainable across real contexts. No grand prize. No months-long runway. Just two weeks, a focused build, and a Cloudinary swag pack for every valid submission.

The response was better than we expected. In just two weeks, creators built five projects around one shared goal: making digital experiences faster, lighter, and more mindful. A wardrobe. A marketing pipeline. A GitHub Action. An exam-week side project. That range mattered, and it proved the point of the Mini-Hack: sustainability becomes more useful when it shows up as working code.

What We Asked For

The brief was deliberately tight. Pick one focused idea. Build it. Show us what you've got.

Submissions could be a working build with a live demo or repo, a short walkthrough video, or a blog post featuring a specific Cloudinary use case. The theme areas were lighter delivery, asset reuse, sustainability, and storytelling around climate awareness. Earth Month, translated into things you can actually ship.

Two weeks. Simple as that.

What They Built

Five projects came in. All of them different. All of them more thoughtful than a standard hackathon entry tends to be.

EcoLens came from someone who was in the middle of exam week and still shipped. The idea started from something painfully relatable: vibe-coded apps full of unoptimized image.png files that make websites slow for no reason. EcoLens lets you paste a website URL or a GitHub repo link, and it scans for media assets, showing you original vs. optimized sizes, bandwidth savings, and CO₂ reduction estimates, all powered by Cloudinary. The really interesting part is the four ways it lets you act on those results: a one-script-tag SDK method, an npm package for local projects, a GitHub PR flow that opens a pull request with optimized changes, and an AI-guided flow that generates prompts for Cursor, Claude, or Copilot. Stack: Next.js, TypeScript, Supabase, Cloudinary AI transformations, and Vercel.

Check it out:

EcoCloset tackled the problem from an entirely different angle: your wardrobe. The insight is straightforward but easy to miss: most fast-fashion waste happens because people forget what they already own. EcoCloset uses Cloudinary AI to strip backgrounds from clothing photos and build a clean digital lookbook of what's already in your closet. The idea being that if you can actually see your wardrobe before you hit checkout, you buy less duplicate stuff. It's a sustainability tool that works by improving your own visibility into what you already have.

Check it out:

Live demo

Eco Image Optimizer kept things intentionally simple. Upload an image, run Cloudinary's f_auto and q_auto optimizations, and see the difference: original file size versus optimized, bandwidth savings, and estimated CO₂ reduction, side by side. No complex setup, no steep learning curve. Just a clear, practical demonstration that smarter media delivery has a measurable environmental impact, and that it doesn't have to be complicated to matter.

Check it out:

Green-pipe went in a completely different direction and built for the developer tooling layer. It's a CLI tool and GitHub Action that scans any repository for media assets, optimizes them through Cloudinary, and generates a pull request with the results alongside a bandwidth and carbon report. The builder tested it against multiple real repositories, including the Kubernetes repository, and the numbers made a point all on their own. The project doesn't have a UI. It doesn't need one. It lives where developers already are.

Check it out:

PromptForge AI approached the sustainability problem from the marketing workflow side. The premise: most marketing teams store the same asset in a dozen different formats and sizes, generating storage waste and carbon emissions for no real reason. PromptForge generates a complete marketing kit from a single prompt, then uses Cloudinary to dynamically transform one source asset into every required format. One file. Every format you need. None of the duplication you don't.

Check it out:

The Judging Session

On May 15th, we took it to LinkedIn Live.

Our Official Cloudinary Creators pitched their projects in a live 30-minute session, with Sanjay Sarathy, VP of Developer Experience & Self-Service at Cloudinary, sitting in as guest judge. It wasn't a polished product demo event. It was builders talking through real decisions, real tradeoffs, and real results. Jen Looper and other community members tuned in to watch.

We did not rank the projects or select a single winner. Each submission brought a different approach to the same challenge, and each one showed real thought, effort, and practical use of Cloudinary. For this Mini-Hack, recognition was less about choosing a first place and more about celebrating what every creator managed to build in just two weeks.

You can catch the recording here → Watch the judging session

What These Two Weeks Proved

A two-week mini-hack with a sustainability constraint produced a CLI tool that works on the Kubernetes repo, a wardrobe app that reframes consumption, a PR automation tool, a marketing asset optimizer, and an image audit platform with four distinct developer workflows.

That's a lot of ground to cover for a two-week community event with a swag pack as the prize.

The thread connecting all five projects is the same: digital weight is a real problem, optimization is often an afterthought, and Cloudinary is useful enough that people keep finding new contexts to apply it in. A wardrobe. A marketing pipeline. A GitHub Action. An exam-week side project. That range matters. And it's a fitting way to mark Earth Month: not with a pledge, but with working code.

What's Next

We're doing it again in June.

We're not ready to share all the details yet, but if these two weeks are any indication, it's going to be worth your time. Stay tuned, and if you want to make sure you don't miss the announcement, keep an eye on the community and our social channels.

The web is still heavier than it needs to be. There's more to build.

Want to Be a Creator?

Every project you just read about came from someone in our community who decided to build instead of just talk. You can be next.

Here's where to start.

Learn more about the Cloudinary Creators program and what it offers at https://cloudinary.com/developers/community.

Join the conversation, get build feedback, and hear about the next Mini-Hack first in our Discord community at https://discord.com/invite/D8ddQj6KnH.

When you're ready to go deeper, work through the Cloudinary Creators curriculum at https://training.cloudinary.com/pages/c2c.

Two weeks was all it took last time. See what you can build with yours.

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 AI Agent Knows Cloudinary. Sort Of.

Ebony Louis — Fri, 15 May 2026 17:01:40 +0000

AI agents are incredible right up until they confidently generate something completely wrong and move on like nothing happened.

What I Ran Into

Over the past year, I've spent a huge amount of time working with tools like Claude Code, Cursor, and Goose, and one pattern keeps showing up: the code looks correct until you actually run it.

That was one of the first things I ran into after joining Cloudinary.

I asked my agent to help me set up a simple Cloudinary integration in an application I was testing. The prompt itself was straightforward:

generate a transformation URL, optimize an image, resize it to 800px wide, and apply automatic quality and format optimization.

The output looked convincing enough that I almost trusted it. Which, honestly, was the problem. The transformation syntax wasn't following best practices, the SDK imports were outdated, and some delivery URL parameters would have behaved unpredictably in production. It didn't fail loudly. It failed quietly, which is worse.

That’s exactly why we built the Cloudinary Skills Pack.

What the Cloudinary Skills Pack Does

The Cloudinary Skills Pack turns your AI agent into a Cloudinary expert with up to date workflows, documentation context, and implementation patterns built in.

Instead of relying entirely on scattered examples pulled from docs, forums, blog posts, and old repositories, the agent can use skills that understand:

Cloudinary transformation syntax
current SDK usage patterns
delivery URL workflows
media optimization best practices
documentation-aware implementation guidance

The current Skills Pack includes three skills:

Skill	Purpose
`cloudinary-docs`	Pulls relevant documentation context directly from the latest Cloudinary docs
`cloudinary-transformations`	Converts natural language requests into valid Cloudinary image and video transformation URLs
`cloudinary-react`	Provides modern React SDK integration patterns and troubleshooting guidance

💡 The cloudinary-docs and cloudinary-transformations skills are framework and language agnostic. Whether you're working with React, Next.js, or Vue on the frontend, or Node.js, Python, PHP, Android, iOS, or React Native on the backend, these skills work across your entire stack. The React skill exists specifically for teams using the Cloudinary React SDK.

What Changed When I Tested It

After installing the Skills Pack, I reran the exact same prompts.

The difference was immediate.

Documentation Answers Became More Reliable

One of the biggest improvements was documentation accuracy.

Prompt: "How do I sign a Cloudinary delivery URL to make it secure?"

Without the skill:

With the skill:

Without the skill, my agent explained the concept of signing but missed the actual implementation. With the cloudinary-docs skill installed, it pulled context directly from the latest Cloudinary documentation and returned working Node.js code and a CLI command I could run immediately.

That distinction matters more than it sounds. Incorrect answers around delivery URLs and signing workflows often don't fail immediately. They become production issues later when security constraints start to matter.

Transformation URLs Became Production Ready

The clearest improvement showed up in transformation generation.

Prompt: "Write me a Cloudinary transformation URL that resizes an image to 800px wide, uses face aware cropping, and applies automatic format and quality optimization."

Without the skill:

With the skill:

Without the skill, my agent used c_thumb instead of c_fill for the crop mode. Technically the URL worked. Realistically it was one "why is this image cropped like that?" debugging session away from ruining my afternoon. With the cloudinary-transformations skill installed, it returned the correct crop mode, face aware gravity, and proper optimization parameters on the first attempt.

This is also where the framework agnostic nature of the Skills Pack becomes important. The transformation skill works independently of React and improves Cloudinary workflows no matter what frontend framework or backend stack you are using.

The React SDK Imports Were Correct

One of the workflows I tested used the Cloudinary React SDK, which is where the cloudinary-react skill came in.

Prompt: "Show me how to set up Cloudinary in a React app and display an optimized image using the Cloudinary React SDK."

Without the skill:

With the skill:

Without the skill, my agent recommended the deprecated cloudinary-react package. The code looked believable enough that I probably would have copied it directly into my project if my terminal hadn't immediately humbled me. With the skill installed, it recommended the correct @cloudinary/react and @cloudinary/url-gen packages and set up the right environment variables for Vite.

Instead of debugging the generated integration, I could immediately continue building.

MCP Servers and Skills Solve Different Problems

One thing became very clear while testing this.

There's a growing conversation around whether skills are necessary if you already have MCP servers configured for your coding agent. After spending the last year heavily working with agents and skills, I don't think these are competing ideas at all.

They solve different problems.

MCP Servers	Skills
Give agents tools and actions	Give agents workflows and implementation knowledge
Execute operations	Teach best practices and platform specific patterns
Help agents do something	Help agents do it correctly

A Cloudinary MCP server can help an agent create a named transformation in your account.

The skill helps the agent understand:

when named transformations are the better architectural choice
how transformation syntax should be structured
which optimization patterns are recommended
how to avoid common implementation mistakes

The two approaches complement each other. MCP servers extend what an agent can do, while skills improve how accurately the agent understands a platform.

That distinction clicked for me very quickly because I spent the last few years working on Goose, where skills are a core part of how agents learn reusable workflows. Once I started testing Cloudinary integrations through that same lens, the value became obvious almost immediately.

AI Agents Need Platform Context

The biggest shift happening right now is that AI agents are quickly becoming the interface developers use to interact with platforms.

That changes the responsibility for developer platforms too.

It's no longer enough to expose APIs and publish documentation. Platforms now need ways to teach agents:

platform specific syntax
implementation workflows
SDK patterns
optimization best practices
architectural recommendations

That's what skills enable.

Try It

# run in your terminal

npx skills add cloudinary-devs/skills

Full installation options, marketplace plugins, and setup instructions are available in the Cloudinary Skills Guide →

We're continuing to expand the Cloudinary Skills Pack with new skills and capabilities over time, so stay tuned for more. And if you have feedback or ideas you'd like to see supported, we'd love to hear from you in the GitHub repo.

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

Say It With Flowers: BouqAIs with the Tussie-Mussie Generator

Jen Looper — Sat, 09 May 2026 17:19:01 +0000

The Tussie-Mussie Generator is a web app for anyone who wants to send a meaningful floral e-card with an AI-generated "tussie mussie", a type of small nosegay. It uses the Victorian language of flowers to compose a bouquet, generates an image with Gemini, and sends it via Resend. This post covers
a Mother's Day relaunch: fixing a broken email integration and swapping the AI image model.

What changed in this relaunch

Migrated email sending from Mailgun to Resend, including a Cloudflare serverless function
Fixed DNS configuration across Porkbun, Netlify, and Resend for a custom subdomain
Replaced the previous image generator with Gemini for accurate tussie mussie generation
Refactored the UI with Astro + Vue and impeccable.style for AI-assisted critique

Have you ever wanted to build an e-card system that would allow you to send little ai-generated bouquets to your friends? No? Yes? Read on, gentle reader!

Last year, I onboarded to my new job by building this sample app that lets you use the Victorian language of flowers to compose a bouquet. An image-heavy app like this is a great candidate for hosting and optimizing via Cloudinary, so all the flower images are stored there. An image of the composed bouquet is generated by Gemini, and then sent via Resend to the recipient of your choice. The app looks like this:

and the generated e-card looks like this:

I launched this app a year ago, and it's had an interesting lifespan. I wanted to relaunch it for Mother's Day and realized there was some refactoring to do!

Here are a few of the gotchas I dealt with:

Keeping the core: The basis of this app is its dataset, which I created a while ago on Kaggle as a useful version of the Victorian "Language of Flowers", scraped from the Farmer's Almanac. Here's an example of what that looks like:

If your idea is centered around a solid dataset, you can't go wrong. Once I had the list, it took me a while to scrape images of the flowers in question and store them, optimized, on Cloudinary. But that work was done a year ago. So two things remained for the relaunch: refactoring the UI and fixing the bits that stopped working, namely the e-card generator.

Refactoring the UI

This app is built using my preferred stack, namely Astro + Vue. After a year, it was definitely time to upgrade, including fixing the tailwind integration which relied on an outdated package. Cursor made short work of that - it's one of the best uses of AI software agents.

Tip: periodically ask your AI to plan the removal of any redundant files or code while you complete refactors. There are usually vestiges that can be deleted.

I used a wildly useful AI skill to refactor my admittedly basic UI: impeccable.style. Install these skills on your machine and as you work with any AI generated UI suggestions, run /impeccable critique to reality-check your work for taste and style. I'm now using impeccable on all my UIs - it also helped me tidy my portfolio. The UI went from this:

...to the UI shown above. I like it a lot.

Fixing the E-Card functionality

This app caused me a horrible panic after launch last year, ruining an anniversary dinner, due to a kerfuffle with Mailgun, the original e-card sending mechanism. I was shocked by an enormous overage charge due to hacking of their systems, and I shut the entire thing down as fast as I could. To relaunch, I needed to find a new service to send email via API. Once again, Cursor to the rescue.

Enter Resend, a new email service that is much more solid than my previous choice. Let us hope that we have smooth sailing from now on! The integration includes a serverless function that you can host on Cloudflare, and works well as soon as you verify a domain. That last part took me the longest time - the gotcha is that since I bought the domain on Porkbun, I had to edit DNS records there to serve emails from a subdomain. The site is hosted on Netlify, so I had to build the subdomain there, and then the DNS verified on Resend. It's the kind of task that you don't do often, so it's easy to miss a step. But all is set now, and the emails are sending!

I also had to reconsider how to build the AI generated bouquets. I'm out of credits on the service I previously chose to generate the bouquets, and they were never quite right anyway (generated as standard bouquets rather than true tussie mussies which have a silver filigree holder). It's crazy to see how AI has evolved for this esoteric imagery over the past year - now Gemini can accurately compose a tussie mussie in its holder, given a specific prompt.

Enjoy these little bouquets! Send one to your Mom today!

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

How to Win a Hackathon

Jen Looper — Sun, 03 May 2026 03:43:08 +0000

A sponsor’s perspective

This blogpost is written on the heels of a few amazing weekends spent knee-deep in students in Toronto and Los Angeles at Hack Canada and LA Hacks, engaging almost 2000 students in person in total. Managing a sponsor track, I have some thoughts on good ways to present yourselves when angling your project towards a sponsor prize.

For those not as familiar with how student hackathons work, they are usually comprised of an organized weekend populated by college undergrads (or older, or younger! high schoolers are increasingly getting into the mix). Over about 36 hours, students form teams and try to build software that meets a need, solves a problem, or proves a point. Some hackathons focus on themes around social good, like Hack Canada which challenged students to build something of special interest to Canada. Others have several themes and a full roster of sponsored options.

Hackathons are a bastion of the cozy web! It’s a delight to see students embracing the freedom to create weird, useless, and wildly creative apps like AeroMaxx, a way to gauge influencers’ aerodynamic-maxxing (Taylor Swift is more aerodynamic than Clavicular, did you know?). LA Hacks even had a track embracing the “most questionable” hack, won by “Yes? Or Yes!”, a hack that had literal goldfish helping make decisions and trigger AI agents to do things like break up with a girl friend, quit a job, and post to social media. Great projects. Please keep building this kind of weird stuff.

a cozy interface for roommates to manage their shopping lists: MagByte

It’s a great moment to let your creativity run wild:

Yes? Or Yes! LA Hacks most unhinged hack winner - goldfish help you make decisions and then trigger agentic workflows. Good luck!

I’ve been working the hackathon circuit as a developer advocate for at least ten years, including the mess during COVID, and the major difference nowadays between the earlier events is, unsurprisingly, the heavy use of AI tooling that both speeds up delivery, polishes the final product, and gets more software shipped, way faster. Instead of watching demo videos, judges can actively interact with an almost production-ready app, shockingly quickly.

Still, there are some tips and tricks that I’d like to share based on a few recent observations of these very fun events. Here are five things to keep in mind as you go for a win!

Who’s it for?

A lot of folks are attracted to social-good type projects, and that’s very laudable. I love them, personally, and tend to mark them highly in my judging rubric. I just want to caution hackathon participants against going after this vector with a “tech savior complex”. It’s easy to think that tech can solve all the things. And tech has made great strides on devices such as most smart phones to help people with various accessibility issues such as those who are blind, color blind, experience hearing loss, or are mobility-challenged.

But if you are going to create a project for a given sector of users, it’s critical to come at these projects with an open mindset and humility, and to work with people who have these actual challenges. Working on an app for older people? Call your Grandma or Grandpa before you start building. It’s likely they can guide you to refining your app to make it much more useful.

At Hack Canada, teams succeeded who spent time talking to local security guards as they built, to ensure that their safety-oriented hack would be useful. It’s all about finding your customer and/or user, and building backwards from that.

Power to the People

Sponsors and mentors are often available to help you all the way through the event, so make use of them! Take some time before you start working to talk to sponsors and see if they can help you start to ideate. Learn about the various sponsors and what they are looking for. Some are looking for product feedback, some are hiring, others may have another agenda.

Maybe you’ll find a product that you never heard of and will make a nice professional connection. Get your LinkedIn app ready to scan codes! This is a great moment to network.

At your service at the booth!

Skill Up

The use of AI tools has accelerated the build phase of a hackathon almost beyond recognition. When I was judging hackathons around 2016 or so, the projects produced were super shaky - often the hacker created a video at the moment that the app worked, and showed that to a judge as it was highly unlikely they could ever get it working again! This has all changed when AI has become such an important build partner.

The use of AI, however, shifts the focus of a hackathon away from the software engineering tasks that now can be offloaded to agents (with supervision, of course!). Now, you need to spend a good amount of time getting set up to make your AI as successful and efficient as you can. Many vendors have created tools to help; we at Cloudinary produced a Skills Pack for this purpose: https://github.com/cloudinary-devs/skills. Using tools such as these will effectively give official context to your app, preventing hallucinations and other wasting of time.

Sponsormaxxing and platformmaxxing

There’s a trend towards “sponsormaxxing” - LA Hacks even had a track for this. The term refers to the incorporation of as many sponsors’ platforms as possible in a given hack. I think it’s a fun challenge, but there’s a risk: if you want to win a sponsor track, you’ll likely be judged on deep integration with their platform.

In our case at Cloudinary, I’m looking for not just the use of the platform as a place to dump images and video, but a deep use of the APIs, for example optimizing and transforming images in an AI pipeline with the goal of constructing videos (as you can do with our winning hack from LA Hacks, StudyO!). Going for a sponsor track prize? Focus on deep integrations.

Going deep, however, can also be risky! There’s the risk of “platformmaxxing” - using every bell and whistle of a platform to try it out. You may need to be a bit strategic here, as you might max out your credits by piling on as many platform aspects as you can. Watch out for signs of maxing out your credits and plan accordingly.

Speaking of maxxing: AeroMaxx

Perfect the Pitch

Judges have only a few minutes per team so you need to make your best impression right away. Come ready to demo with your storytelling skills well in hand. Do some trial runs prior, and get feedback on your presentation skills. Lead with the use case, show the demo, and field questions. A good strategy for a 2-3 minute hackathon pitch is to focus on the problem you see, the solution you propose, and the impact you predict.

Hook (15 seconds): Introduce yourself, state the problem you are solving, and share a relatable scenario or story.
Demo (60-90 seconds): Walk the audience through your core feature
Tech (30 seconds): Briefly explain the most impressive technical hurdle you overcame or the tech stack that powers the hack.

Tip: Consider recording a video of your demo just in case there’s a horrible glitch, and practice getting over a glitchy demo. You can do it!

Pitching can be intense!

Winning a hackathon is a great goal, but don’t forget that being accepted into some of these selective hackathons, participating, and building a piece of software that you can be proud of is very laudable as well. Wishing you the best of luck! And maybe we will see you there.

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

6 Free Cloudinary Courses That Teach You to Build Media-Optimized Apps

Jen Looper — Thu, 30 Apr 2026 18:33:51 +0000

The Cloud to Crowd (C2C) curriculum is Cloudinary's free 6-course learning suite for developers who want to build and ship applications with production-quality image and video handling. It covers everything from Cloudinary basics to AI-powered transformations paired with hands-on projects at every step and a free certificate when you complete each course.

Fun fact: community member Jerome Hardaway of Vets Who Code, one of our nonprofit partners in the Creators Community program, coined the "Cloud to Crowd" term!

What You'll Be Able to Build After This Curriculum

Upload, manage, and transform media assets using the Cloudinary API
Optimize images and video for performance in a Next.js app
Apply AI-powered features: background removal, generative fill, auto-tagging
Use the Python SDK to automate media workflows on the backend
Deliver video efficiently with format and quality auto-selection
Ship a real portfolio project that demonstrates all of the above
Earn a Cloudinary certificate and qualify for the Creators Community

Why We Built This

Getting images and video right in a production app is harder than most tutorials suggest. Resize, format, optimize, deliver — each step has tradeoffs, and most learning resources skip the messy middle. The C2C courses are designed to fill that gap: structured, project-driven, and free.

The 6 Free Courses

All courses are self-paced and free at https://training.cloudinary.com/pages/c2c.

Course 1: Media IQ for Developers

Enroll: https://training.cloudinary.com/learn/course/devrel-c2c-intro

The starting point for the first three courses in this suite. This course covers the core Cloudinary concepts: cloud name, API keys, the Media Library, and your first upload and transformation. No prior Cloudinary experience needed. By the end, you'll have a free account set up and understand how assets move through the Cloudinary pipeline.

You'll learn to:

Choose the right image formats for your use case, understanding when to use JPEG, PNG, WebP, AVIF, or SVG based on content type, browser support, and performance trade-offs
Apply strategic optimization techniques including responsive images with automatic format/quality selection and intelligent cropping with gravity detection

Course 2: Media IQ for Developers with Next.js

Enroll: https://training.cloudinary.com/learn/course/devrel-c2c-next

The flagship course of the C2C curriculum. You'll build a storefront application (the "CapZone" e-commerce store) using Next.js and the Cloudinary Next.js SDK, applying real-world image optimization patterns throughout.

You'll learn to:

Build an image-optimized web application using Cloudinary to upload, store, transform, and deliver images on-the-fly through URL-based transformations and CDN delivery
Apply strategic optimization techniques including responsive images with automatic format/quality selection and intelligent cropping with gravity detection
Create Next.js components that handle image uploading, display optimized images with overlays and watermarks, and serve different sizes for different contexts

The kind of component you'll be writing by the end of this course:

import { CldImage } from 'next-cloudinary';

export function ProductImage({ publicId, alt }: { publicId: string; alt: string }) {
  return (
    <CldImage
      src={publicId}
      width={600}
      height={400}
      crop="fill"
      gravity="auto"
      format="auto"
      quality="auto"
      alt={alt}
    />
  );
}

Course 3: Media IQ for Developers with AI

Enroll: https://training.cloudinary.com/learn/course/devrel-c2c-ai

Cloudinary's AI-powered transformation features are some of its most practical and useful. This course covers the tools that save the most time in real projects: background removal, generative fill, object-aware cropping, and auto-tagging. This course follows the Next.js course, building AI into the CapZone store by adding a color picker to colorize the hats.

You'll learn to:

Remove or replace backgrounds using e_background_removal
Use generative fill to extend or recompose images
Apply smart cropping with gravity: "auto" for face- and object-aware results
Auto-tag assets using AI analysis to make large libraries searchable

Course 4: Media IQ for Developers with Video

Enroll: https://training.cloudinary.com/learn/course/devrel-c2c-video

Video is a different beast from images; you manage larger files, adaptive bitrates, more delivery complexity. This course covers the Cloudinary video pipeline from upload to playback. It's the third and final part of the progressive enhancement of the CapZone e-commerce web app that you started prior. In this course you'll add a video to one of the products.

You'll learn to:

Upload and transcode video using the Cloudinary API
Apply video transformations: trim, resize, overlay, add subtitles
Build playlists and seekbars with subtitles

Course 5: Media IQ for Developers with Python

For less JavaScript-focused developers, this course covers Cloudinary's Python SDK: uploading, managing, and transforming assets from any Python environment.
Enroll: https://training.cloudinary.com/learn/course/devrel-c2c-python

You'll learn to:

Authenticate and configure the Python SDK
Upload and tag assets for organization
Build a small pet store app

Course 6: Building a Developer Portfolio with Cloudinary and Next.js

Enroll: https://training.cloudinary.com/learn/course/devrel-c2c-portfolio

The capstone course. You'll apply everything from the earlier modules: upload, transformation, optimization, and AI features — to build a complete portfolio site using React and TypeScript that demonstrates your Cloudinary skills to employers. Focus on your own skills and show them off to the world in a media-rich website.

You'll learn to:

Architect a media-rich portfolio app from scratch
Combine multiple Cloudinary transformations into a polished UI
Optimize for performance: lazy loading, responsive breakpoints, format auto-selection
Deploy a production-ready app you can link from your resume

Who's this for?

The C2C curriculum works for:

Early-career developers who want structured, project-based learning beyond "hello world" tutorials
Career changers building a portfolio they can point to during job interviews
Frontend developers who've used Cloudinary but want to understand the optimization and AI layers
Backend developers looking to add media handling to their Python projects
Bootcamp graduates who want to go from tutorial-follower to someone who can build production media pipelines

How to Enroll for Free

Go to training.cloudinary.com/pages/c2c
Create a free Cloudinary Academy account — you just need an email address
Start with Course 1 or jump to the course that matches your current skill level

All 6 courses are free. Each comes with a completion certificate. Finishing any course and passing its final assessment at 80%+ earns you a credential that qualifies you to apply to the Cloudinary Creators Community, a network with mentorship, Discord access, mini-hack events, and connections to developers worldwide.

About the Cloudinary Creators Community

The Cloudinary Creators Community (CCC) is a selective, cohort-based program for developers who've completed the C2C curriculum.

It includes:

Access to private Discord channels with Cloudinary's Developer Relations team
Monthly mini-hack challenges to apply and extend your skills
Peer review and mentorship from a global network of developers
Badges, certificates, and holopins with social media shout-outs

You can join the Discord server now and participate in community activities even while you're working through the curriculum.

Ready to start? → training.cloudinary.com/pages/c2c

This blogpost was crafted with the help of Claude. Banner image by Nano Banana.

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

Ship Your Next Great Web App in Record Time with create-cloudinary-react

Eric Portis — Tue, 07 Apr 2026 19:53:07 +0000

Over the past year or two, we've been having a lot of conversations about the future of Cloudinary's Libraries and SDKs. The conversations have been wide-ranging: the future of front-end frameworks, coding, and AI. It's all been a bit dizzying, and hard to wrap our heads around.

Late last year, my colleague Raya Straus brought us back down to earth with some good old-fashioned user research. By engaging users in conversations about their current day-to-day experiences, Raya got us to stop worrying about the future, and start thinking about ways we could make developers more successful with Cloudinary right now.

We released the first fruit of Raya's research last month: Cloudinary's React Starter Kit. If you're building a green-field, media-focused React app, and you're using LLM-powered development tools, we think npx create-cloudinary-react is the best way to get started.

Before we get into what it is, let's talk about how and why we built it.

What We Learned From React SDK User Research

We limited our research scope to two of our most popular SDKs: React and Next.js. We looked at every piece of user feedback for those two SDKs that we could find: support tickets, GitHub issues, chat transcripts, survey responses, and even a number of individual conversations held over email and Zoom, after we reached out to top SDK users.

Once we'd collected and digested it all, three things stuck out:

Many developers struggle to get started. The least fun part of any development project is setting up a working development environment; a handful of common config problems are tripping up many developers before they can take their first steps with Cloudinary.
Once set up, features that solve common use cases were straightforward and people were quickly successful. Cloudinary and our SDKs do a great job of solving common use cases with a minimum of fuss. Great!
But once use cases get more advanced, developers start to struggle again. Cloudinary is a mature product, and can do all sorts of things, but advanced features are more complicated to use. Niche functionality often has fiddlier syntax, less clear error messages, and trickier-to-find documentation. So even though the features are there, developers run into walls when trying to use them.

How the React Starter Kit Works

So, the question we ended up with, was: How can we help developers who are just getting started with Cloudinary, and folks with complex use cases?

We think we can address both with one new tool: npx create-cloudinary-react.

Type that into a terminal near you and you'll be led through a wizard, which will ask you a few questions about your environment. Then, it will spin up a working React project for you, using Vite as a build tool, and handle all of the configuration that people who are just starting to use Cloudinary with React so often get stuck on. The resulting project starts with a simple, one-page website that accepts and displays user-generated image uploads.

In addition to doing basic configuration, the wizard also installs Cloudinary's LLM-specific tools, and puts a bunch of rules and troubleshooting guidance to help LLMs with Cloudinary's APIs wherever your particular LLM-powered coding environment looks for context.

We derived these rules from our user research, by feeding all of the feedback we received about using Cloudinary's React SDK into an LLM and asking it to write rules to address that feedback. From there, we refined, added, and subtracted rules based on our experiences of using and helping other folks use Cloudinary.

Those rules, in addition to our other LLM-specific tools, significantly improve LLMs' results when prompted with complex tasks. To show off those capabilities, the initial built project offers a handful of example prompts which you can copy, paste into your agent, and hit the ground running.

With create-cloudinary-react, we believe we've built something that helps everyone get started, and also helps folks who have gone beyond common use cases use all of the nooks and crannies of Cloudinary's extensive feature set.

See the React Starter Kit in Action

Here's create-cloudinary-react in action:

How the React Starter Kit performed at Hack Canada 2026

After a few rounds of internal development and testing, we soft-launched the React Starter Kit a few weeks ago -- just before we participated as a sponsor in this year's Hack Canada.

A hackathon is a perfect environment for this kind of tool, and the results blew us away. Participants leveraged the Starter Kit to produce some truly incredible projects, and cited create-cloudinary-react as part of their success.

That was all the validation we needed to add a React Starter Kit walk through to our documentation and announce it in this very blog post.

So, go! Try it out! And tell us 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

Upload and Deliver Media in Flask with Cloudinary: Presets, Widget, and Search

Sharon Yelenik — Mon, 23 Mar 2026 19:07:00 +0000

Excerpt: Cloudinary is a media API for Python/Flask developers that uploads, transforms, and searches images and video without bloating your app or database. It cuts custom upload code and speeds delivery.

This post shows how to handle user uploads and delivery in a Flask app using Cloudinary’s Python SDK, upload presets, the Upload Widget, and search—without storing binaries in your database. The first sections cover setup; then we add client-side and server-side uploads.

If you need a moderate amount of UGC (portfolios, catalogs), you want uploads off your server, consistent transforms, and searchable metadata.

You’re building an app for a small business or website, maybe a portfolio site or boutique store, and you know high-quality visuals are key for attracting buyers and showcasing your work. But without a designer on the team, you’re responsible for handling all the images and videos yourself.

What you’ll do

Install and configure Cloudinary in Flask
Create an upload preset (transforms + auto-tagging)
Add the Upload Widget and a server-side upload route
Query assets by tag with the Search API
Deliver with transformations in templates (e.g. cloudinary_url)

Benefits of Streamlined Media Management

Before we get into the practical steps, here are some of the advantages of establishing a solid media management approach in your Flask application:

Less custom code and reduced storage complexity. Offloading large media files from your database or filesystem keeps your application simpler and avoids managing bulky binary data.
Reliable uploads that scale. A predictable upload flow prevents issues with file size limits, timeouts, or custom route handling, especially when users submit large images or videos.
Consistent, high-quality digital media. Automated tasks like resizing, compression, tagging, and background removal help keep your images and videos optimized without manual editing.
Optimized, searchable delivery. Well-structured metadata and scalable search make assets easier to find, while delivering the right size and format improves performance across devices.

By storing your digital media in Cloudinary instead of on your server or in your database, you can take advantage of these benefits immediately, while keeping your Flask codebase lightweight and focused on application logic.

Managing media files in Flask becomes much simpler with the steps we cover next (tap the icons to navigate to the related section):

Setup and Configuration

Before we dive into the specifics of media management with Python and Flask, you'll need to sign up for Cloudinary. It's quick and straightforward.

Installing and Configuring Cloudinary in Your Python/Flask App

To get started with Cloudinary in your Python/Flask app, follow these steps:

In your project virtualenv:

Install the Cloudinary Python library using pip install cloudinary.
Configure Cloudinary in your Flask application, typically inside app.py or a separate config.py file:

# config.py or app.py
import cloudinary
import cloudinary.uploader
import cloudinary.api

cloudinary.config(
    cloud_name="your_cloud_name",
    api_key="your_api_key",
    api_secret="your_api_secret"
)

Note: Replace your_cloud_name, your_api_key, and your_api_secret with your actual Cloudinary credentials, which you can find on the API keys page of the Console Settings.

If you're using a config.py, you'd load it in your Flask app like this:

from flask import Flask
import config  # or your preferred config structure

app = Flask(__name__)

With these steps, you've successfully integrated Cloudinary into your Flask project, and you're ready to use its media management capabilities (upload, transform, search, deliver).

Enhanced Media Processing With Upload Presets

Upload presets in Cloudinary help you automate your media workflow by applying transformations, metadata rules, and upload behaviors the moment a file arrives. This means less processing in your Flask routes and far more consistent results across all your media.

In this article, we’ll focus on two powerful capabilities you can unlock through presets: automated transformations and auto-tagging. You can explore many other preset options in Cloudinary’s documentation, but these two alone can dramatically simplify your media pipeline.

Automating Transformation Settings

Upload presets allow you to automatically apply transformations such as resizing, cropping, recoloring, background removal, and more, without writing additional code in Flask. For example, you can create presets that remove backgrounds from uploaded logos, ensure all portfolio images are a consistent size, or sharpen older or lower-quality photos.

Each preset applies its rules automatically when the file is uploaded.

Tip: By applying the g_auto AI-powered transformation, you can ensure that crops preserve the important parts of your images and keep the main subject of your videos in focus.

By defining these settings once, every uploaded media file stays consistent and optimized with no manual editing or external image processing tools required.

Leveraging Auto-Tagging

If you enable auto-tagging through Cloudinary’s categorization engines, images are automatically analyzed and tagged based on their content. These tags can support a variety of downstream tasks, including:

organizing assets
improving searchability
enabling content discovery
powering filters in your UI or internal tools

For example, an image of a woman on a city street using a smartphone and carrying a bag might receive tags such as “woman,” “bag,” “mobile phone,” “purse,” or “car,” depending on the AI model you use.

Important: To use auto-tagging, you’ll need to subscribe to one of Cloudinary’s auto-tagging add-ons. The examples in this blog use the Rekognition Auto Tagging add-on.

Red-haired woman in stylish outfit chatting on phone

Tip: Check out the Computer Vision Image Analysis for Your E-commerce Website demo to see Cloudinary in action, returning information about the content it identifies in your images.

Creating an Upload Preset

You can create an upload preset using the Cloudinary Admin API right from your Flask application or a setup script. Here’s an example using the Python SDK:

# Define the upload preset details
upload_preset_name = "my_preset"
upload_preset_options = {
    "unsigned": False,
    "folder": "my_folder",
    "tags": "my_tags",
    "transformation": [
        {"width": 500, "height": 500, "crop": "fill"},
        {"effect": "vignette"},
    ],
    "categorization": "aws_rek_tagging",
    "auto_tagging": 0.9
}

# Create the upload preset using the SDK
upload_preset = cloudinary.api.create_upload_preset(
    name=upload_preset_name,
    settings=upload_preset_options
)

# Check if the upload preset was created successfully
if upload_preset.get("name") == upload_preset_name:
    print("Upload preset created successfully.")
else:
    print("Failed to create upload preset.")

Once created, simply reference the preset name during upload, and all rules will apply automatically.

Uploading Media With Python and Flask

Uploading files is central to your Flask workflow, and Cloudinary provides two flexible methods: the Upload Widget for client-side uploads and server-side uploads from your Flask routes.

Let’s explore both.

Upload Widget

If your app accepts user-generated content (UGC), such as portfolio images from creators or product photos submitted by small business owners, the Cloudinary Upload Widget provides a smooth, reliable upload experience directly from the browser. You can attach any upload presets you’ve created so transformations, optimization, tagging, and other processing happen automatically on upload, without additional Flask code.

Tip: You can also create a preset that automatically moderates user-uploaded images and videos to help ensure that the content appearing on your site is appropriate.

Example: portfolio or catalog uploads

A portfolio gallery or a simple shop catalog where users can upload photos or videos is an ideal scenario for the Upload Widget. It handles the entire client-side upload flow, while your presets manage all media processing in the background.

How to Implement the Upload Widget in Flask

Create a route that renders the template:

# app.py
from flask import Flask, render_template

app = Flask(__name__)

@app.route("/upload-media")
def upload_media():
    return render_template("upload_media.html")

Create the template (templates/upload_media.html):

<!DOCTYPE html>
<html>
<head>
    <title>Media Upload</title>
</head>
<body>
    <button id="upload_widget" class="cloudinary-button">Upload files</button>

    <script src="https://upload-widget.cloudinary.com/global/all.js" type="text/javascript"></script>  

    <script type="text/javascript">  
        var myWidget = cloudinary.createUploadWidget({
            cloudName: 'my_cloud_name',
            uploadPreset: 'my_preset'
        }, (error, result) => {
            if (!error && result && result.event === "success") {
                const imageUrl = result.info.secure_url;
                console.log("Done! Here is the file info: ", result.info);

                // Optional: Send imageUrl to your Flask backend
                // fetch('/save-media', { method: 'POST', body: JSON.stringify({ url: imageUrl }) })
            }
        });

        document.getElementById("upload_widget").addEventListener("click", function() {
            myWidget.open();
        }, false);
    </script>
</body>
</html>

Add the URL rule (if not using decorators):

# app.py
app.add_url_rule("/upload-media", view_func=upload_media)

Test it by visiting:

http://localhost:5000/upload-media (with your dev server running)

You now have a complete client-side upload flow, with Cloudinary handling media processing automatically.

Server-Side Upload

Server-side uploads are perfect when you need automation or want to process files uploaded through a traditional

Example Use Case

News aggregators, podcast platforms, or content curation apps often automate large-scale ingestion:

analyze images

apply tags

create captions

run moderation

convert formats

Cloudinary can handle these tasks server-side with very little code.

Uploading From Flask

from flask import request
import cloudinary.uploader

@app.route("/upload", methods=["POST"])
def upload():
    file_to_upload = request.files["file"]
    result = cloudinary.uploader.upload(
        file_to_upload,
        upload_preset="my_upload_preset"
    )
    return {"url": result["secure_url"]}

And that’s it. Your media is uploaded, transformed, stored, and ready to deliver.

Searching Made Simple

Once your assets are stored in Cloudinary, especially with auto-tagging enabled, searching becomes incredibly fast.

Instead of digging through folders or writing custom queries, you can retrieve matching media with a single expression:

def search_media_by_tags(tags):
    return cloudinary.Search().expression(f"tags:{tags}").execute()

Example queries:

tags:portrait
tags:handmade
resource_type:video AND tags:nature

Use search to build quick admin dashboards, galleries, filters, or automated content workflows.

Delivering Your Media

With Cloudinary managing your media, delivery becomes as powerful as upload. You can apply on-the-fly transformations directly in the image or video URL with no processing required in Flask.

Example: Dynamic Image Sizing in a Flask Template

<img 
  src="{{ cloudinary_url(public_id, width=width, height=height, crop='fill') }}"
  alt="Your Image"
/>

Or, using the SDK:

from cloudinary.utils import cloudinary_url

url, options = cloudinary_url(
    public_id,
    width=400,
    height=300,
    crop="fill"
)

Why this beats DIY storage

You don’t store multiple versions of each image
Users automatically receive optimized formats (WebP, AVIF, MP4, etc.)
Dynamic resizing keeps your site lightweight and fast

For responsive layouts, check out:

Recap: Presets, Uploads, Search, and Delivery

In short, the features we’ve covered include upload presets, smart uploads, AI-powered search, and dynamic delivery. Apply these features to take managing media files in Flask from “painful but necessary” to “effortless and scalable.”

Instead of writing boilerplate logic for uploads, storage, and optimization, you can focus on building features your users care about.

Search & discovery (keywords): Flask file upload Cloudinary; Cloudinary upload preset Python; Cloudinary Search API tags; Cloudinary Upload Widget Flask; Flask image delivery and cloudinary_url transformations; Python SDK, user uploads, UGC.

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