DEV Community: Cloudinary

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

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

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

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

What changed in this relaunch

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

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

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

and the generated e-card looks like this:

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

Here are a few of the gotchas I dealt with:

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

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

Refactoring the UI

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

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

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

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

Fixing the E-Card functionality

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

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

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

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

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

How to Win a Hackathon

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

A sponsor’s perspective

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

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

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

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

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

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

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

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

Who’s it for?

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

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

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

Power to the People

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

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

At your service at the booth!

Skill Up

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

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

Sponsormaxxing and platformmaxxing

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

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

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

Speaking of maxxing: AeroMaxx

Perfect the Pitch

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

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

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

Pitching can be intense!

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

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

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

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

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

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

What You'll Be Able to Build After This Curriculum

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

Why We Built This

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

The 6 Free Courses

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

Course 1: Media IQ for Developers

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

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

You'll learn to:

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

Course 2: Media IQ for Developers with Next.js

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

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

You'll learn to:

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

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

import { CldImage } from 'next-cloudinary';

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

Course 3: Media IQ for Developers with AI

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

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

You'll learn to:

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

Course 4: Media IQ for Developers with Video

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

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

You'll learn to:

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

Course 5: Media IQ for Developers with Python

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

You'll learn to:

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

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

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

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

You'll learn to:

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

Who's this for?

The C2C curriculum works for:

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

How to Enroll for Free

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

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

About the Cloudinary Creators Community

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

It includes:

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

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

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

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

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