Cloudinary converts all three into credits and subtracts them from one balance. When a small production app has a stable catalog and heavy traffic, it **burns bandwidth credits**. An app that generates many variants burns transformation credits. Two apps on the same plan can run out of credits at very different times, which is why the sticker price tells you so little. There's no separate bandwidth plan or storage plan to tune, because the pool covers everything. You can't buy more of one dimension cheaply. You buy more credits, or you pay for the overage.  ### The plan table, checked 2026-11-08 Read the table below, built from the pricing page at cloudinary.com/pricing, for what each plan pools and what sales negotiates: the self-serve tiers have a fixed fee, while the top tier doesn't. Dollar amounts and credit counts change, so take them from the live page rather than from a copy. | Plan | Monthly price (annual / monthly billing) | Included credits | Storage | Bandwidth | Transformation limits | Seats | Support level | |---|---|---|---|---|---|---|---| | Free | No charge | Small monthly allotment | Drawn from credits | Drawn from credits | Drawn from credits | Limited | Self-serve docs and community | | Plus | Fixed fee, cheaper rate on annual billing | Larger monthly pool | Drawn from credits | Drawn from credits | Drawn from credits | More than Free | Ticket-based | | Advanced | Fixed fee, cheaper rate on annual billing | Larger again | Drawn from credits | Drawn from credits | Drawn from credits | More than Plus | Broader than Plus | | Enterprise | Custom, quoted by sales | Negotiated | Negotiated | Negotiated | Negotiated | Negotiated | Account-level | Distrust the Enterprise row: you can't compare a price you only learn by talking to someone with anything else. Up to Advanced, you can do the math yourself. ### What changed since the last pricing revision I can't confirm a line-by-line diff against the previous revision, so I won't invent one. What matters is the date: the table reflects the page as checked on 2026-11-08. If you're comparing against a quote or an invoice from earlier, check the credit allotment first. That's where a revision changes your bill. ## Monthly bills at three realistic usage levels Everything lands in one credit pool: stored GB, delivered GB and transformations. Where a workload falls against that pool's limit, rather than the plan's sticker price, sets the bill. Each example below converts its usage into credits using the conversion rates in Cloudinary's documentation, then names the plan and checks whether overage beats upgrading. Look at the pattern in the table: bandwidth and transformations, not storage, decide which plan fits as traffic grows. | | Stored GB | Delivered GB | Transformations | Total credits | Plan chosen | Monthly bill | Overage vs next plan up | |---|---|---|---|---|---|---|---| | Side project | Small library | Light traffic | Few, cached after first request | Inside the free allowance | Free | Nothing | Not relevant, no overage | | Small production app | Moderate | Steady, grows with users | Moderate, mostly repeated sizes | Close to the paid plan's pool | First paid plan | Plan fee, with a small overage possible | Overage stays cheaper until usage clearly outgrows the pool | | Media-heavy store | Large catalog | Heavy, many images per page | Many variants per product | Over the first paid plan's pool | Next plan up | Higher plan fee, no overage | Overage costs more than the upgrade | Read across a row, not down a column. The plan follows from the total, and one column usually dominates the total. ### Side project on the free plan With a small library and light traffic, a side project fits inside the free allowance, so the monthly bill is nothing. The risk is a spike: one post that gets shared can pull delivered GB far above a normal month. On a free plan that's a limit to watch, so check usage in the dashboard before a launch rather than after. ### Small production app Somewhere in a small production app, the plan fee stops being the whole story. Storage barely moves month to month, but delivery grows with every new user, and each new image size adds transformations.  Overage is cheaper than upgrading only while the excess is small. The test is simple: add the overage you expect for the month to the current plan fee and compare it with the next plan's fee. If the first sum is close to the second, take the upgrade, because next month's traffic will probably be higher. ### Media-heavy store near the plan boundary When a store has a large catalog, several images per product page and many size variants per image, it burns credits on all three inputs at once. Here a plan's pool runs out partway through the month, and Cloudinary bills every unit past that point at the overage rate. Because Cloudinary sets overage rates above the effective per-credit rate inside a plan, the upgrade comes out cheaper. That's why this row ends on the next plan up. ## Hidden costs and limits beyond the plan Past the plan price, the bill grows in eight places. Most of them only show up once you count transformations, video minutes and limits that your dashboard totals don't flag. Your console's usage page breaks credits down by storage, bandwidth and transformations, so check it before assuming catalog size is the driver. ### Transformations and derived assets Every variant you request, such as a resize, crop or format conversion, is a derived asset that Cloudinary stores and transforms, and both draw from the same credit pool. Most images still need conversion, which is why this matters. [PageSpeed Matters](https://www.pagespeedmatters.com/resources/data-studies/image-formats-of-the-web) finds WebP on 16.6% of web images and AVIF on 4.3%, leaving 79.1% in other formats, which means these modern formats remain marginal on the web.  If your library looks like the web at large, **nearly four in five originals** are candidates for a conversion, and each new format or size multiplies the variants. Ten originals served in four widths and two formats is **80 derived assets, not 10**. ### Video and add-on charges Video is metered more heavily than images, because a single transcode or a minute of streaming consumes far more of the pool than a thumbnail. Treat any video-heavy workload as its own line in your estimate rather than folding it into an image average. Paid add-ons, such as third-party moderation or tagging, are priced separately from the plan, so their cost sits outside the credit math and you add it by hand. ### Cloudinary overage rules and account limits **Overage is where the arithmetic turns against you**. Once you exceed the pool you pay for usage beyond it, and **if that excess is recurring, the next plan up usually costs less than the same overage month after month.** Run that comparison on your last three months of usage, not your best one. Limits compound the problem, because they can force an upgrade even when credits are fine. The set to check: - derived assets and transformations - video - paid add-ons - overage - maximum file size (images 10, 20 and 40 MB; video 100 MB, 2 GB and 4 GB across the three tiers) - API rate limits - seats (3, 3 and 5) - search above 10 million assets Seats are the clearest example: the first two tiers both cap at three, so a fourth collaborator can mean a plan change with no change in traffic. On the entry tier, a 100 MB video ceiling rules out raw footage regardless of credits, and file size works the same way, so entry-tier creators face fixed per-file size limits even though usage limits are soft. Add these limits to your credit estimate, and the cheapest plan is the one that clears both. ## Cloudinary against ImageKit, Cloudflare Images and Imgix On sticker price alone, **none of the alternatives beats Cloudinary**. They win when their meter matches what your app does, because a meter that ignores your heaviest cost is the real discount.  ### Pricing models side by side I'm not printing plan prices here. They change often, and a stale figure in a cost comparison does more harm than none. Check each vendor's own pricing page before you commit, and don't trust a number that needs a sales call to confirm. What lasts is the unit each vendor charges for. The table shows that unit and what it means for a small production app, so you can see which line of your traffic each plan taxes. | Vendor | Metering unit | What grows a small app's bill | |---|---|---| | Cloudinary | Credits, one pool for storage, bandwidth and transformations | Any of the three; heavy use of one drains credits for the others | | ImageKit | Plans built mainly around bandwidth | Delivery traffic; storage and transformations matter less | | Cloudflare Images | Images stored, images delivered, and unique transformations | Library size and page views, each billed on its own line | | Imgix | Usage-based, tied to processing and delivered traffic | Delivery volume and how many variants you generate | Pooled credits make Cloudinary's bill hard to predict but flexible, since slack in one resource covers a spike in another. The other three split the charges or lean on one dominant meter, so you can work out the monthly cost from a single number, such as page views. What follows is that you must then watch that one number for the cliff, where the next tier costs less than overage. ### When ImageKit, Cloudflare or Imgix beats Cloudinary If delivery bandwidth is your main cost and your library is modest, ImageKit wins. Its plans center on the meter you actually pay on, so you're not buying transformation capacity you never use. When you can count your images and your views, Cloudflare Images wins, which suits a catalog that changes slowly. Separate lines for storage and delivery let you price each from your own analytics, and reused transformations aren't billed again as new work. If you already have images in your own storage and want a processing layer in front of them, Imgix wins. You pay for the work and the traffic, not for hosting a second copy. Cloudinary wins when your workload is varied: video, heavy transformation chains, and a media library your team manages. A single pool then absorbs the swings that would hit two or three separate meters elsewhere. If your traffic is one-dimensional, the pool is a convenience you're paying for. If it's mixed, the pool is the saving. ## A Cloudinary usage alert built in Activepieces You don't hire for this alert, you describe it. Tell the built-in chat in Activepieces to check Cloudinary credit use once a day and message you past 80%, and it publishes a live flow in your account, the same one a builder would have wired by hand, so you have time to act before you max out.  It runs under the same RBAC and audit logs as every other flow, human-built or not, and each daily check leaves a run trace your finance lead can read without any training. It takes about 15 minutes on a Monday and watches Cloudinary without replacing anything in it. Here's the whole build in order, so you can see the shape before the detail: 1. Create a new flow. 2. Add a Schedule trigger set to run daily. 3. Add an HTTP step that sends a GET to the Cloudinary Admin API usage endpoint with basic auth. 4. Add a condition: credits used divided by the credit limit is at least 80%, meaning users have consumed most of their allocation. 5. Add a Slack or email step on the true branch. 6. Test the flow, then publish it. The next three stages cover those steps in more depth. ### Stage 1: schedule the check Create the flow and pick Schedule as the trigger, with a daily interval. Daily is the right grain for a pooled-credit plan, because a traffic spike shows up in bandwidth and transformations within a day, and a weekly check can miss the spike entirely. Pick an hour when someone will see the message, such as the start of the working day, so the alert gets read and acted on the same morning. ### Stage 2: read usage from the Cloudinary API Add an HTTP step, set the method to GET, and point it at the Admin API usage endpoint under your cloud name. Choose basic authentication. Use your Cloudinary API key as the username and the API secret as the password, and store both as connection values rather than pasting them into the step. Run the step once and read the output. You need the credits used and the credit limit, and the test output shows their exact field names in your account. Check them there instead of assuming. This is also the step where you see which resource is eating the pool, since storage, bandwidth and transformations all appear in the same response. ### Stage 3: alert at the threshold Once the condition divides credits used by the limit, it should continue only when the result is 0.8 or higher. On the true branch, add a Slack message to a channel your team reads, or an email step if nobody lives in Slack.  Put the used credits, the limit and the percentage in the text, so the message tells you what to decide without a trip to the dashboard. Run the test, confirm the message arrives, and publish. The alert never changes your plan. It tells you the pool's filling while the plan upgrade is still cheaper than the overage. ## Frequently asked questions ### Is Cloudinary free to use? Yes, Cloudinary has a Free plan, and for a small app it can cover real production traffic. It draws on the same credit pool as every paid plan, so storage, bandwidth and transformations all count against one allowance. If one image-heavy page gets popular, a free account that looks idle can still run out quickly, so watch the pool, not the price. ### Does Cloudinary roll over unused credits? **Treat unused credits as gone**. Cloudinary's plans are built around a recurring allowance, not a prepaid balance you draw down over time, so a quiet month doesn't bank room for a busy one. For budgeting, that means sizing a plan to your typical month plus a margin for spikes. Don't count on a slow stretch to pay for a launch. ### What happens when I exceed my Cloudinary credits? It depends on the plan, and this is where the bill surprises people. On the Free plan, going over generally means Cloudinary asks you to upgrade, since its limits are soft limits. On paid plans, the choice is between paying for usage beyond the allowance and moving up a tier. Run both numbers before you decide. If you're regularly over, the next plan's included credits usually cost less than the same usage billed as overage. If the overage was a one-off spike, paying it is the cheaper path. ### Can I switch Cloudinary plans mid-billing cycle? From your account settings, you can change plans, and an upgrade is the move you'll most often want mid-cycle, when the pool is draining faster than expected. Don't assume the old and new allowances stack or that charges are prorated in your favor. Check the billing summary in your account before confirming, and compare the new plan's included credits against what you've already burned this cycle. Anything that needs a conversation with sales to explain should make you pause, and the self-serve tiers shouldn't need one. ### Does Cloudinary offer annual or startup discounts? Cloudinary has offered annual billing on its paid plans, which typically costs less per month than paying monthly in exchange for a longer commitment. It has also run a program aimed at early-stage startups. Terms and eligibility change, so confirm them on Cloudinary's current pricing and startup pages before you plan around either one. Commit annually only once your credit usage has been stable for a few cycles. Locking in a plan you're about to outgrow, or one far bigger than you need, turns a discount into a cost. ## Related reading - [Cohere Pricing 2026 for Trial, Production and Enterprise](https://www.activepieces.com/blog/cohere-pricing-2026-for-trial-production-and-enterprise) - [ADP Payroll Pricing for Small Businesses in 2026](https://www.activepieces.com/blog/adp-payroll-pricing-for-small-businesses-in-2026) - [DeepSeek Search API vs Exa Pricing for Small Teams (2026)](https://www.activepieces.com/blog/deepseek-search-api-vs-exa-pricing-for-small-teams-2026) ## References - [PageSpeed Matters](https://www.pagespeedmatters.com/resources/data-studies/image-formats-of-the-web)The cost of one image view is never a single line item.