DEV Community: Cloudinary

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

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

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

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

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

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

The one step agents couldn't do

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

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

That step is gone across this whole stack:

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

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

Cloudinary's version returns something like this:

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

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

Two properties matter for what follows:

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

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

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

What it built

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

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

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

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

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

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

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

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

Could it actually do the work?

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

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

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

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

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

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

Where the human went

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

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

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

Things that bit us

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

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

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

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

The IP lock surprises you at deploy time

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

e_preview can't generate on the fly

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

Cloudinary can't POST a webhook to localhost

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

Two settings still have no API

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

Try it

Point an agent at the repo:

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

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

cloudinary-devs / unshutter

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

unshutter

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

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

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

Three product shapes:

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

View on GitHub

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

Further reading: Claimable Cloud provisioning · Agents, start here

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

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

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

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

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

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

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

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

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

What we built and why

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

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

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

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

npx @cloudinary/cloud

Type that into your terminal to kick off the process.

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

Provisioning: Spin Up a Temporary Cloudinary Cloud

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

Watch & Transform: Auto-Crop for Each Social Platform

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

The image we want to resize

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

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

Render Results & Send to Client: Share a Claim URL

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

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

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

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

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

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

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

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

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

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

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

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

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

Up and Running with Cloudinary’s Next Starter Kit

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

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

Today we're releasing a sequel:

npx create-cloudinary-next

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

A quick demo of Cloudinary's Next Starter Kit

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

What Cloudinary's Next Starter Kit actually does

What does the Next Starter Kit actually do?

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

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

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

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

The Cloudinary Next.js skill

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

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

And you're off

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

npx create-cloudinary-next

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

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

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

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

Our last Mini-Hack started with a constraint.

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

For June, we tried the opposite.

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

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

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

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

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

That was exactly the point.

The Brief Was Almost No Brief

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

The instructions were deliberately simple:

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

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

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

Meet the Cloudinary Skills Pack

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

The pack included three skills:

`cloudinary-docs`

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

`cloudinary-transformations`

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

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

`cloudinary-react`

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

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

Our pitch to the community was simple:

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

Support Along the Way

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

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

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

Then came the final push.

Submissions officially closed on July 5.

Participants were competing for:

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

Five Projects, Five Completely Different Directions

Removing the theme did not make the projects feel disconnected.

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

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

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

CloudCanvas, by Joyston

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

That is the question behind CloudCanvas.

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

Its editing tools include:

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

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

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

Explore the project:

Try the live demo

Snap Optimizer AI, by Aashi

Some projects solve one media problem extremely well.

Snap Optimizer AI solves several.

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

Users can:

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

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

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

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

Explore the project:

Eirene, by Nivrithi

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

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

The platform helps mothers document and understand their recovery through:

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

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

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

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

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

Explore the project:

Try the live demo

CreatorPilot AI, by Ved Prakash Arya

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

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

CreatorPilot AI brings those experiences into one workspace.

The platform includes:

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

It supports workflows such as:

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

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

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

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

Explore the project:

Brandify, by Princess Bube

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

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

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

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

Brandify also includes a second workflow for technical content.

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

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

Explore the project:

View the GitHub repository

Taking the Projects Live

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

This was not just a slideshow of finished products.

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

The judges evaluated every project using four criteria:

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

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

Missed the session?

And the Winner Is…

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

This time, we chose one.

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

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

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

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

Aashi will receive:

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

Congratulations on an incredibly well-executed project.

What This Mini-Hack Proved

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

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

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

A consulting challenge became a branding assistant.

Too many documentation tabs became a developer copilot.

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

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

A deeply personal healthcare gap became a recovery journal.

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

That range is not a side effect of the challenge.

It is the strongest result.

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

What’s Next

You probably know how this section ends.

We are doing it again.

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

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

Stay Connected With the Cloudinary Creators Community

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

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

Learn more about the Cloudinary Creators program:

https://cloudinary.com/developers/community

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

https://discord.com/invite/D8ddQj6KnH

Work through the Cloudinary Creators curriculum:

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

Explore the Cloudinary Skills Pack:

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

The next challenge has not started yet.

Your next project can.

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

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

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

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

The game

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

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

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

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

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

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

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

Here's the whole flow on one diagram:

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

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

Why not just store the files?

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

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

Uploads that never touch my server

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

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

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

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

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

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

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

Sessions without signup

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

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

A whole trading card is one URL

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

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

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

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

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

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

A few things to watch for:

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

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

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

Moderation on upload

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

Every signed upload carries an AWS Rekognition moderation string:

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

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

Supabase: the right key for the right job

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

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

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

Live updates without polling

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

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

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

External service → Webhook → Postgres → Supabase Realtime → Browser

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

Building this with an agent

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

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

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

Run it

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

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

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

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

What carries over

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

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

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

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

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

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

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

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

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

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

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

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

Original image copyright © REUTERS/ABC Affiliate WABC

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

What you'll build

A Python script that can:

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

Prerequisites

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

Install the Python dependency:

pip install requests

Export your Cloudinary credentials:

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

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

Generate your first AI image

Run the script with a prompt:

python3 generate.py "A medieval monk"

This image was generated with the default Flux model

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

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

Then it calls the API using HTTP Basic Auth:

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

Choose an AI image model

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

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

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

Supported model families include:

flux
gpt-image
ideogram
recraft
nano-banana

This was the same prompt, done with Ideogram model

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

Save generated images as Cloudinary assets

The important part of the request is this:

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

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

After generation, the script prints something like:

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

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

Full usage examples

Generate a new image:

python3 generate.py "Marie de France playing pool"

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

Use a premium model:

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

Why this is useful

Most image generation APIs return an output.

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

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

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

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

Final thoughts

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

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

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

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

Your model returns a file. Production needs an asset.

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

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

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

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

Step zero: the output is built to disappear

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

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

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

Persistence alone isn't the finish line

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

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

Why autonomous agents make media persistence harder

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

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

What "production-ready" actually means

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

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

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

This is really an asset pipeline

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

Building the media pipeline yourself

The pattern everyone reaches for looks simple:

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

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

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

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

Two pipelines, one call

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

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

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

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

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

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

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

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

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

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

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

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

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

Or generate straight into your asset platform

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

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

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

The takeaway

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

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

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

I Stopped Choosing Image Models Manually

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

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

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

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

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

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

The problem with hardcoding models

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

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

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

My first attempt was simple

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

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

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

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

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

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

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

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

Why keyword matching isn't enough

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

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

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

Swapping in Claude

Replacing the keyword router with Claude is one function change:

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

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

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

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

What I actually learned

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

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

Why Cloudinary?

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

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

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

Try it yourself

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

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

To get started:

Where I think this is going

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

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

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

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

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