{"id":40209,"date":"2026-07-17T07:00:00","date_gmt":"2026-07-17T14:00:00","guid":{"rendered":"https:\/\/cloudinary.com\/blog\/?p=40209"},"modified":"2026-07-17T12:49:08","modified_gmt":"2026-07-17T19:49:08","slug":"world-cup-card-game-nextjs-cloudinary-supabase-vercel","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/world-cup-card-game-nextjs-cloudinary-supabase-vercel","title":{"rendered":"World Cup Card Battler: Turn Your Selfie Into a Football Card With Next.js, Cloudinary, Supabase, and Vercel"},"content":{"rendered":"\n

The World Cup is on, half my feed is football, and I wanted an excuse to build something. So I built Kickoff Cards<\/strong>: Upload a selfie, pick your nation, and get a playable football trading card. With it, you can battle other people’s cards, earn XP, and climb a live leaderboard.<\/p>\n\n\n\n

<\/a>The Game<\/h2>\n\n\n\n

The idea is simple: 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<\/em>.<\/p>\n\n\n\n

All you have to do is upload a selfie and pick a nation. After a few seconds, you get a card back: your face cut out and dropped into the frame in your nation’s colors, with six performance stats down the side (pace, shooting, passing, and so on). 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.<\/p>\n\n\n\n

Then you play it. Send your card into the battle arena, get matched against another player’s cards, and go head to head across your performance 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.<\/p>\n\n\n\n

That’s the whole loop. Make a card, fight with it, level it up, and 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.<\/p>\n\n\n\n

\"Generated<\/figure>\n\n\n\n

The card game is the demo. What this post really focuses on is how the four tools it’s built on fit together.<\/p>\n\n\n\n

I chose tooling that works well with agentic development environments \u2014 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.)<\/p>\n\n\n\n

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 and runs entirely on free tiers. You can play it at kickoff-cards.vercel.app<\/a><\/strong>, then fork the code and run yourself: github.com\/cloudinary-devs\/kickoff-cards<\/a><\/strong>.<\/p>\n\n\n\n

Here’s the whole flow on one diagram:<\/p>\n\n\n

Browser\n  \u2502\n  \u251c\u2500 GET page \u2500\u2500\u2192 Next.js Server Component \u2500\u2500\u2192 Supabase (RLS)\n  \u2502                                        \u2514\u2500\u2192 Cloudinary URL builder\n  \u2502\n  \u251c\u2500 POST \/api\/sign-upload \u2500\u2500\u2192 signed upload params\n  \u2502\n  \u2514\u2500 Direct upload \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 Cloudinary\n                                  \u2502\n                          Async moderation\n                                  \u2502\n                              Webhook \u2500\u2500\u2192 Supabase update \u2500\u2500\u2192 Realtime \u2500\u2500\u2192 Browser\n<\/code><\/span><\/pre>\n\n\n
The rest of this post walks through the decisions behind that diagram.<\/a><\/p>\n\n\n\n
Why Not Just Store the Files?<\/h2>\n\n\n\n
The first decision was what to do with the uploaded photos. The easy version: save the file, serve it back, done. That holds up until you actually look at what a card needs, e.g., background removal, a face-aware crop, compositing onto the template, text overlays, modern formats, and content moderation. Do it yourself and now you’re maintaining a transform pipeline, a CDN, and a moderation step.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
<\/a>Uploads That Never Touch My Server<\/h2>\n\n\n\n
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.<\/p>\n\n\n
export<\/span> function<\/span> getSignedUploadParams<\/span>({ userId, kind }<\/span>) <\/span>{\n  const<\/span> timestamp = Math<\/span>.round(Date<\/span>.now() \/ 1000<\/span>)\n\n  const<\/span> publicId =\n    kind === \"avatar\"<\/span>\n      ? `kickoff\/users\/${userId}<\/span>\/avatar`<\/span>\n      : `kickoff\/users\/${userId}<\/span>\/uploads\/${crypto.randomUUID()}<\/span>`<\/span>\n\n  const<\/span> signature = cloudinary.utils.api_sign_request(\n    { timestamp, public_id<\/span>: publicId, overwrite, moderation, notification_url },\n    env.CLOUDINARY_API_SECRET,\n  )\n\n  return<\/span> { signature, timestamp, apiKey, cloudName, publicId }\n}\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Because the signature covers every parameter, the client can’t change the destination path, moderation settings, webhook URL, or overwrite behavior without invalidating it. You get direct uploads while the server keeps control of where files land.<\/p>\n\n\n\n
This isn’t 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.<\/p>\n\n\n\n
<\/a>Sessions Without Signup<\/h2>\n\n\n\n
That userId<\/code> 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 of that ID. Uploads are scoped to it (kickoff\/users\/{userId}\/...<\/code>), so a card belongs to the right person without any extra plumbing.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
<\/a>A Whole Trading Card is One URL<\/h2>\n\n\n\n
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.<\/p>\n\n\n
const<\/span> transformation = [\n  { overlay<\/span>: layerId },\n  { effect<\/span>: \"background_removal\"<\/span> },\n  { crop<\/span>: \"fill\"<\/span>, gravity<\/span>: \"face\"<\/span>, width<\/span>: tmpl.photo.w, height<\/span>: tmpl.photo.h },\n  { flags<\/span>: \"layer_apply\"<\/span>, gravity<\/span>: tmpl.photo.gravity, x<\/span>: tmpl.photo.x, y<\/span>: tmpl.photo.y },\n\n  \/\/ six stat overlays, one per attribute<\/span>\n  ...STAT_ATTRS.flatMap((attr<\/span>) =><\/span> [\n    { overlay<\/span>: { font_family<\/span>: \"Arial\"<\/span>, font_size<\/span>: 44<\/span>, font_weight<\/span>: \"bold\"<\/span>, text<\/span>: String<\/span>(stats[attr]) }, color<\/span>: \"black\"<\/span> },\n    { flags<\/span>: \"layer_apply\"<\/span>, gravity<\/span>: \"north\"<\/span>, x<\/span>: slot.x, y<\/span>: slot.y },\n  ]),\n\n  { overlay<\/span>: \"kickoff:cloudinary-logo\"<\/span>, width<\/span>: 220<\/span>, crop<\/span>: \"scale\"<\/span>, opacity<\/span>: 55<\/span> },\n  { flags<\/span>: \"layer_apply\"<\/span>, gravity<\/span>: \"south\"<\/span>, y<\/span>: 28<\/span> },\n  { width<\/span>: 800<\/span>, crop<\/span>: \"limit\"<\/span> },\n]\n\nreturn<\/span> cloudinary.url(`templates\/${nation}<\/span>`<\/span>, {\n  transformation,\n  fetch_format<\/span>: \"auto\"<\/span>,\n  quality<\/span>: \"auto\"<\/span>,\n  secure<\/span>: true<\/span>,\n})\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
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.<\/p>\n\n\n\n
A few things to watch for:<\/p>\n\n\n\n