DEV Community: Nayan Kyada

Prismic Pricing 2026: Free Tier Limits, Per-Seat Costs & When to Upgrade

Nayan Kyada — Sat, 26 Sep 2026 09:27:24 +0000

Prismic pricing is one of those topics where the official marketing page tells you almost nothing useful until you've already clicked through to checkout. This breakdown covers what the free tier actually gives you, where the per-seat model gets expensive, and when a competing tool like Sanity or Contentful makes more financial sense.

What the Prismic free tier actually includes

As of September 2026, Prismic's free plan is called Starter and is limited to one user (the owner), one repository, and unlimited document types. There is no time limit — it doesn't expire after 14 days. That's genuinely useful for a solo developer running a personal site or prototyping for a client pitch.

The ceiling that gets you first isn't documents — it's collaboration. The moment a content editor, a second developer, or a client needs access, you're off the free tier.

Plan	Monthly cost	Users included	Repositories	Custom types	Releases
Starter	$0	1	1	Unlimited	1
Small	$15	3	1	Unlimited	5
Medium	$100	10	3	Unlimited	15
Platinum	$500	25	10	Unlimited	Unlimited
Enterprise	Custom	Custom	Custom	Unlimited	Unlimited

Prices above are per-repository, billed monthly. Annual billing saves roughly 20% on each tier.

Where per-seat costs actually land

Prismic doesn't charge per seat the way Contentful or Storyblok do — instead it bundles users into tier thresholds. That can work in your favour (Small gives you 3 users for a flat $15/month) or against you (the jump from Small to Medium is $85/month for 7 extra users).

The realistic cost for a small agency project with one developer and two editors is $15/month on Small. For a marketing team with four editors and a developer you're already at $100/month on Medium, not $20.

Add a staging environment (separate repository) and you immediately need Medium or above — one repository per environment is the ceiling at Small.

Releases and scheduled publishing

"Releases" is Prismic's term for content staging sets — grouping document changes together and publishing them as a unit. The Starter plan gives you one release, which means no meaningful staging workflow. Small gets you five. If your client does scheduled campaign launches with content queued two weeks out, five releases will feel tight. Medium's 15 is adequate for most editorial teams.

This is a genuine functional gate, not just a vanity limit. Compare it to Sanity, where scheduled publishing is available on the free tier via the @sanity/scheduled-publishing plugin (though it requires a paid plan for full production use in newer versions), or Contentful, where scheduled publishing is locked behind paid tiers regardless.

Locale and internationalization costs

Prismic supports multiple locales on all paid plans — each locale is just a field variant in a document. There's no per-locale pricing. For a multilingual Next.js site using next-intl this is one area where Prismic is cleaner than Contentful (which counts locales toward environment limits) and roughly comparable to Sanity (which uses @sanity/document-internationalization at no extra cost).

The catch: Prismic's translation workflow is document-duplication based. You copy a master locale document and translate in place. For sites with 50+ content types in three locales, that gets unwieldy fast regardless of price.

What actually triggers an upgrade

In order of how often I see it happen in practice:

A client or editor needs repository access. Starter's single-user limit is the most common forcing function. Upgrade to Small immediately — $15/month is not a decision worth debating.
Staging environment required. One repository on Starter/Small means production is your only environment unless you pay for Medium or above.
More than five releases needed. High-volume editorial teams with campaign scheduling will hit this on Small.
Multiple projects on one account. Prismic repositories are per-project. An agency managing ten client sites needs either ten billed accounts or an Enterprise arrangement with multi-repository access.

How Prismic compares to Sanity and Contentful on cost

Scenario	Prismic	Sanity	Contentful
1 dev, personal site	$0	$0	$0
1 dev + 2 editors, 1 project	$15/mo	$0 (Free tier: 3 users)	$0 (Community: 5 users)
1 dev + 2 editors, staging env	$100/mo	$15/mo (Growth)	$0 if using branches
5 editors, 2 projects	$200/mo+	$15/mo (Growth, 1 project) + $15	$489/mo (Basic)
10 editors, 3 projects	$500/mo	$99/mo (Team)	$489/mo+

Sanity's Growth tier at $15/month covers a single project with up to 10 non-admin users and dataset-level staging via Sanity's dataset copy feature. That's the comparison that bites Prismic hardest: for most teams with 3–8 editors, Sanity undercuts Prismic on cost at every tier except the smallest.

Contentful remains more expensive than both past the free tier, but its environment model is more mature for multi-stage workflows than Prismic's releases concept.

Who Prismic actually makes sense for

Prismic's strongest case is a small content team — one developer, one or two editors — running a single marketing site. The Slice Machine workflow (visual component mapping between CMS and Next.js) is genuinely good for teams that don't want to write custom Portable Text renderers or build Sanity Studio previews from scratch. If that workflow fits, $15/month for Small is reasonable.

The pricing model becomes a liability when:

You manage multiple client repositories and want one billing relationship
Your team grows past 10 people (Medium's $100/month is fine; above that it escalates fast)
You need branching-style environments rather than the release queue model

For a Next.js agency billing clients per-project, Sanity's per-project pricing or Payload's self-hosted model will almost always be cheaper once you're past two or three active clients. Prismic's repository-per-project structure with no bulk pricing is its biggest commercial weakness compared to Sanity's organisation-level plan.

API access and rate limits

Prismic's API is REST-based (with a GraphQL beta). All paid plans get the same API access — there's no separate rate limit tier. CDN delivery is included. This is fine for most content sites built on Next.js with ISR; it's not a differentiating factor either way.

Webflow Pricing 2026: Free Tier Limits, CMS Costs & When to Upgrade

Nayan Kyada — Fri, 25 Sep 2026 09:43:23 +0000

Webflow pricing confuses most buyers because the plan structure splits across two separate billing axes — site plans and workspace plans — and the thresholds that force an upgrade are not always obvious until you hit them. This post maps out exactly what you get for free, where the real costs kick in, and when Webflow stops being cost-effective compared to a headless alternative.

How Webflow pricing is structured

Webflow bills on two dimensions simultaneously:

Workspace plans — cover how many editors and guests can collaborate inside the Designer and CMS panel. Free forever for one person; paid tiers unlock additional collaborators and roles.
Site plans — cover what a published site can do: custom domain, CMS item limits, form submissions, bandwidth, and e-commerce.

You pay both. A small marketing agency might have one workspace plan covering all their sites, plus individual site plans for every client property. That stacking is the first thing that surprises teams moving from WordPress or Squarespace, where there is one bill.

Free tier: what you actually get

Webflow's free tier is a staging environment, not a production option. Key limits as of September 2026:

Custom domain: not included — your site sits on a .webflow.io subdomain
CMS items: 50 across all collections
Form submissions: 50 per month
Bandwidth: 1 GB per month
Editors: 0 (no client-facing CMS editor access without a paid site plan)

You can prototype and hand off a preview URL, but the moment a client needs their own domain, real form volume, or more than a handful of blog posts, the free tier is gone.

Site plan pricing (2026)

Plan	Price/month (annual)	CMS items	Bandwidth	Guest editors	Forms/month
Basic	$14	— (no CMS)	50 GB	0	500
CMS	$23	2,000	50 GB	3	1,000
Business	$39	10,000	100 GB	10	2,500
Enterprise	Custom	Custom	Custom	Unlimited	Custom

Month-to-month prices run roughly 30–35% higher. The CMS plan is the default recommendation for content-driven sites, but 2,000 items sounds generous until you model a real content library — 800 blog posts, 400 product pages, 200 team bios, and a few hundred case studies gets you there faster than expected.

Workspace plan pricing (2026)

Plan	Price/month (annual)	Collaborators	Sites published
Starter	$0	1	2
Basic	$14	3	10
Core	$19	Unlimited seats billed per seat	Unlimited
Growth	$49/seat	Unlimited	Unlimited
Agency / Enterprise	Custom	Custom	Custom

The Core plan bills per-seat at $19/seat/month (annual). A three-person editorial team adds $57/month before any site plan costs. The Growth plan at $49/seat is aimed at teams that need advanced permissions and white-label client portals.

The real upgrade triggers

CMS item limit on the CMS plan (2,000 items). This is the most common reason teams escalate to Business. A multilingual site that uses one collection per language, or a site with a large product catalog, gets there quickly. There is no way to archive or soft-delete items to free up quota — items count whether they are published or draft.

Guest editor seats. The CMS plan allows 3 guest editors. A mid-size client with a marketing team of five needs the Business plan at $39/month just for seat headroom.

Bandwidth. 50 GB sounds reasonable, but image-heavy sites with meaningful traffic hit it. Webflow does not offer a CDN add-on — you either upgrade or implement a reverse proxy in front of the Webflow-hosted domain, which creates its own complexity.

Form submissions. 1,000/month on the CMS plan is enough for most marketing sites, but any site running paid campaigns with a lead-gen form will exceed this during a campaign sprint.

Logic and memberships. Webflow Logic (workflow automation) and Memberships are add-ons with their own per-action or per-member pricing. These are not included in any flat site plan.

Where Webflow pricing breaks down at scale

For a single marketing site with modest traffic and a small editorial team, Webflow's pricing is reasonable — $23–$39/month per site, plus workspace costs. The math gets uncomfortable in two scenarios:

Multiple client sites. An agency managing ten client sites pays ten separate site plan bills. At $23/month each, that is $230/month before any workspace costs. WordPress on shared hosting or a Sanity + Vercel stack looks significantly cheaper per-site at that volume.

High CMS volume with dynamic filtering. Webflow's CMS does not support server-side filtering or dynamic pagination beyond what its native collection lists allow. Sites that need faceted search, user-specific content, or CMS-driven data beyond the item limits must reach for Webflow's API and build custom front-ends — at which point you have most of the complexity of a headless setup but are still paying Webflow's hosting margins.

Webflow vs. headless: where the cost curve crosses

A comparable Sanity + Next.js + Vercel setup for a content-heavy marketing site runs roughly:

Sanity Growth plan: $15/month (up to 3 non-admin users included, 100k API CDN requests/day)
Vercel Pro: $20/month (covers one team, multiple projects)
Total: ~$35/month

For a single site with one development team, Webflow Business ($39/site/month) and the headless stack are close. Add a second site and the headless stack's costs barely move while Webflow doubles. Add five sites and the gap is significant.

The crossover for most agency or multi-site setups sits around three to four active client sites — beyond that, a shared Sanity organization and Vercel team deliver more CMS flexibility and lower per-site cost.

What you do not get regardless of plan

Git-based version control for code (Webflow's Designer outputs proprietary markup)
Component-level code customization without JavaScript embeds
Native support for ISR, SSR, or edge rendering
Structured data / JSON-LD injection without custom code embeds
TypeScript or any typed content layer

None of these are dealbreakers for a pure marketing site with a non-technical team. They matter the moment the site needs dynamic behavior, personalization, or a content model that outgrows Webflow's collection structure.

Ghost Pricing 2026: Free Self-Hosted Costs, Pro Plans & When to Upgrade

Nayan Kyada — Wed, 23 Sep 2026 09:25:25 +0000

Ghost pricing is genuinely confusing because the software is open-source but the managed hosting — Ghost Pro — runs on a separate billing model that catches people off guard. This post breaks down every tier, what you actually pay when self-hosting, and the thresholds that force an upgrade.

What Ghost actually costs to self-host

Ghost itself is MIT-licensed and free to download. The cost is entirely in the infrastructure you bolt around it.

A minimal self-hosted Ghost setup on a VPS in 2026 looks like this:

Component	Typical provider	Monthly cost
VPS (1 vCPU, 1 GB RAM)	Hetzner CX22, DigitalOcean Basic	$4–$6
Managed MySQL (optional)	PlanetScale Hobby / Supabase Free	$0–$10
Object storage for images	Cloudflare R2 (free up to 10 GB)	$0–$1
Transactional email	Mailgun Flex, Postmark	$0–$10
SSL / CDN	Cloudflare Free	$0
Total		$4–$27/month

That is a real production setup — not a toy. The catch is maintenance: OS patches, Node upgrades, Ghost CLI updates, and backup automation all land on you. Budget 2–4 hours a month if you are comfortable with Linux; more if you are not.

A 1 GB RAM VPS handles Ghost comfortably up to roughly 50,000 monthly page views, assuming you are not running computationally heavy newsletter sends at the same time. Above 100k views or 10,000 active email subscribers, you will want 2 GB RAM and a managed database to separate concerns.

Ghost Pro pricing in 2026

Ghost Pro is the official managed hosting product from Ghost Foundation. Pricing is tiered by the number of members (subscribers), not staff seats or sites.

Plan	Monthly (billed annually)	Monthly (month-to-month)	Member limit	Staff users	Custom domain
Starter	$9	$11	500	1	Yes
Creator	$25	$31	1,000	2	Yes
Team	$50	$63	10,000	5	Yes
Business	$199	$249	100,000	Unlimited	Yes
Enterprise	Custom	Custom	Unlimited	Unlimited	Yes

All plans include SSL, CDN, automated backups, Ghost theme hosting, and email newsletter delivery via their own sending infrastructure (Mailgun under the hood). There are no separate email sending costs until you hit Business tier volume.

The free trial is 14 days on any plan, no credit card required. After the trial, there is no permanent free tier on Ghost Pro — unlike Sanity, Contentful, or Strapi, Ghost Foundation does not offer a zero-cost hosted plan. If you want free, you self-host.

What triggers an upgrade

The member count is the only hard billing wall on Ghost Pro. Cross the limit for your plan and Ghost will prompt an upgrade before the next billing cycle — your site stays online, but new member signups are blocked until you upgrade or remove members.

Three real-world upgrade triggers:

Newsletter growth. A Creator plan at 1,000 members costs $25/month. Hit 1,001 members and you are looking at the Team plan at $50/month — a 100% price jump for one subscriber. That cliff is steeper than most people expect.

Staff account limits. Starter is a solo plan. If a second editor needs login access, you are on Creator minimum. Many teams discover this late in onboarding.

Email send volume on Business. Ghost Pro does not publish a hard monthly email send cap below Business, but heavy sending (multiple newsletters per week to a large list) can trigger conversations with their support about infrastructure costs. Above 100,000 members, you are in Enterprise territory where this is negotiated.

Ghost Pro vs self-hosted: total cost of ownership

Scenario	Ghost Pro (annual)	Self-hosted (annual, conservative)
Solo blog, 200 members	$108 (Starter)	$72 (Hetzner + email)
Newsletter, 800 members	$300 (Creator)	$144 (upgraded VPS)
Team, 5,000 members	$600 (Team)	$300–$480 (2 GB VPS + managed DB)
Scale, 50,000 members	$2,388 (Business)	$600–$900 (multi-node + SES)

Self-hosting is cheaper at every tier — sometimes by 3–4×. The trade-off is real: Ghost Pro absorbs all ops overhead, and their email deliverability is pre-warmed. If you are a developer comfortable with Linux and your time is worth less than the Ghost Pro premium, self-hosting makes financial sense. If you are a content-first team, the Pro managed experience is worth the delta up to Team tier.

Ghost vs Sanity for Next.js: which pricing model fits better

This comes up constantly because both are legitimate choices for a Next.js content site. Ghost is not a headless CMS in the traditional API-first sense — it has a built-in frontend and a Content API as an add-on. Sanity is API-first with no built-in frontend.

Sanity's free tier (Growth Developer plan) gives you unlimited API requests, 20 GB CDN bandwidth, and up to 3 users — enough for most small projects indefinitely. Ghost Pro has no free hosted tier. If your project needs content infrastructure without a built-in rendering layer, Sanity's free tier almost always wins on day-one cost. Ghost wins when you want native email newsletters, membership gating, and a working site without building a frontend at all.

Hidden costs worth knowing

Theme marketplace. Ghost's official marketplace has free and paid themes. Premium themes run $49–$199 one-time. Not a subscription cost, but a real line item for new sites.

Custom integrations. Ghost's Zapier integration and most native integrations are available on all plans. Webhooks — essential for triggering Next.js ISR revalidation — are available from Creator plan up, not Starter.

Migration. Ghost charges nothing for importing content, but if you are migrating from WordPress, you will likely spend 4–8 hours cleaning the import export. Factor that into the real first-month cost.

The single most important number to nail down before choosing a Ghost Pro plan is your projected 12-month member count. The member cliff at each tier makes the Starter-to-Creator jump the most painful in the lineup — plan ahead rather than being forced into a mid-cycle upgrade.

Cloudinary vs Sanity CDN for Next.js Images: An Honest Comparison

Nayan Kyada — Tue, 22 Sep 2026 09:25:11 +0000

Choosing between Cloudinary and Sanity's built-in CDN for image delivery in a Next.js project is not obvious. Both serve modern formats, both integrate with next/image, and both have free tiers that look generous until you hit a specific threshold. This comparison is based on production projects where I had to justify the choice to a client paying the bill.

What each system actually does

Sanity stores images in its asset pipeline and exposes them through cdn.sanity.io. Every image you upload gets a stable URL, and you append query parameters — ?w=800&h=600&fit=crop&auto=format — to transform it on the fly. The auto=format flag is what tells Sanity's CDN to serve WebP or AVIF depending on the Accept header. There is no separate transformation pipeline to configure; it's baked in.

Cloudinary is a dedicated media platform. It has its own SDK, its own URL structure, and a much wider transformation surface: AI-based background removal, generative fill, face detection cropping, named transformations you can version and reuse. For a Next.js project, you typically use next-cloudinary or construct URLs manually with the Cloudinary URL builder.

For a content site running on Sanity CMS, Sanity's CDN covers 90% of what you need. For a product or e-commerce site where you're doing complex image operations at scale, Cloudinary earns its seat.

Format support and transformation depth

Capability	Sanity CDN	Cloudinary
WebP delivery	✓ (`auto=format`)	✓ (`f_auto`)
AVIF delivery	✓	✓
Crop / resize	✓	✓
Focal-point crop (hotspot)	✓ (via `@sanity/image-url`)	✓ (face detect or manual)
Background removal	✗	✓ (AI, paid)
Generative fill / expand	✗	✓ (paid)
Named / versioned transforms	✗	✓
Video transcoding	✗	✓
Signed URLs	✓	✓
On-upload metadata (dominant colour, LQIP)	✓	Partial (requires fetch)

Sanity stores a palette and metadata block on every image asset at upload time. That means dominant colour is free at query time — no extra API call. Cloudinary can return metadata but only if you make a separate API request or use its analysis add-on.

Integration with next/image

Both work as next/image loaders. Here is the minimal Sanity loader:

// lib/sanity-image-loader.ts
import { SanityImageSource } from '@sanity/image-url/lib/types/types'
import imageUrlBuilder from '@sanity/image-url'
import { client } from './sanity.client'

const builder = imageUrlBuilder(client)

export function sanityLoader({
  src,
  width,
  quality,
}: {
  src: string
  width: number
  quality?: number
}) {
  // src is the raw Sanity image reference URL
  return builder
    .image(src)
    .width(width)
    .quality(quality ?? 80)
    .auto('format')
    .url()
}

And a comparable Cloudinary loader:

// lib/cloudinary-loader.ts
export function cloudinaryLoader({
  src,
  width,
  quality,
}: {
  src: string
  width: number
  quality?: number
}) {
  const params = [
    'f_auto',
    'c_limit',
    `w_${width}`,
    `q_${quality ?? 'auto'}`,
  ].join(',')
  // src is the Cloudinary public_id
  return `https://res.cloudinary.com/${process.env.NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME}/image/upload/${params}/${src}`
}

Both produce responsive URLs that next/image uses for its srcset. The difference is where the asset lives. If you're already on Sanity, uploading a second copy to Cloudinary for delivery is unnecessary overhead — both storage cost and upload latency during content entry.

Pricing gap at real traffic levels

This is where the decision often ends.

Plan	Sanity CDN	Cloudinary
Free bandwidth	Included in Sanity plan (unlimited via CDN)	25 GB / month
Free transformations	Unlimited (URL param based)	25 credits (~25k transforms)
First paid tier	Sanity Growth: $15/month (not CDN-gated)	Plus: ~$89/month
Transformation overage	N/A	$0.05 per credit beyond plan
Storage overage	Sanity assets count against project quota	$0.04/GB beyond 25 GB

Sanity's CDN does not charge per transformation. You pay for the Sanity plan, and image delivery is not the thing that pushes you up a tier — document count and seat count are. A marketing site with 500 posts and heavy image traffic will stay on the Sanity free or Growth plan without Cloudinary ever entering the equation.

Cloudinary's 25 credit limit sounds workable until you factor in that one f_auto,c_fill,w_800 transform on a new URL counts as one credit. A site that generates many URL variants (responsive widths × crops × quality) can hit 25k transforms in a week during a crawl or cache-warming run.

When to use Cloudinary alongside Sanity

There is a valid pattern: store originals in Sanity, sync or upload to Cloudinary for specific assets that need advanced transforms. I've done this for one client who needed AI background removal on product images. The Sanity webhook fires on publish, a route handler uploads the asset to Cloudinary, stores the Cloudinary public ID back on the Sanity document, and the frontend reads that ID for product images only.

That hybrid only makes sense if you have a genuine need for Cloudinary's AI layer. Running the full stack through Cloudinary when your assets already live in Sanity doubles your storage costs and complicates your content pipeline for no meaningful delivery improvement.

Sanity CDN vs Cloudinary: the honest pick

If your project is a Next.js + Sanity CMS content site — blog, marketing site, documentation, editorial — use Sanity's CDN with @sanity/image-url and the auto=format flag. You get WebP/AVIF, focal-point crops, dominant colour for placeholders, and zero extra cost. There is no CDN configuration to maintain.

If your project is a product catalogue, marketplace, or app where images need generative AI operations, face detection, or heavily versioned named transforms, Cloudinary is worth the $89/month starting point. Build the hybrid pattern only if Sanity is your source of truth and Cloudinary handles a specific transform layer.

The worst outcome is paying for Cloudinary's Plus plan on a content site that auto=format would have served just as well.

Cloudflare Images Pricing 2026: Storage Limits, Delivery Costs & When to Upgrade

Nayan Kyada — Mon, 21 Sep 2026 10:06:46 +0000

Cloudflare Images is not free — and the pricing structure is unusual enough that teams routinely underestimate the bill before they hit a threshold. This post breaks down exactly what you get at each tier, what triggers an upgrade, and how the costs stack up if you are serving images from a Sanity CMS project through a Next.js front-end.

How Cloudflare Images pricing actually works

Cloudflare Images is not bundled inside the free Cloudflare plan in any meaningful way. There is no perpetual free tier the way Cloudinary or Bunny Stream offer one. Instead, Cloudflare sells a flat-rate storage block and a separate delivery unit.

As of September 2026, the pricing looks like this:

Unit	Price
First 100,000 images stored	$5 / month
Each additional 100,000 images	$5 / month
Images delivered (variants)	$1 per 100,000 served
Free trial	None (credit card required at signup)
Flexible variants (custom resize on the fly)	Included
Max upload size per image	10 MB
Max output dimension	12,000 px on either side

The $5/month base buys you 100,000 stored originals and unlimited named variants off those originals — Cloudflare pre-generates nothing, it resizes on first request and then caches the result at the edge. Delivery is charged separately at $1 per 100,000 served images (across all variants). If you have 50,000 product images each served in three sizes to 10,000 monthly visitors, the math adds up quickly.

What counts as a stored image

Every original you upload via the API or the dashboard counts as one stored image against your 100,000 block. Variants — resized or cropped outputs — do not count toward storage; only the original does. Deleting an image removes it from the count immediately.

This matters for Sanity projects. Sanity stores its own originals in its asset pipeline. If you decide to also push those assets into Cloudflare Images (via a webhook or a migration script), you are paying for storage twice — once inside Sanity's plan and once inside Cloudflare's. That dual-storage pattern is only worth it if Cloudflare's edge delivery or transform speed genuinely outperforms what cdn.sanity.io delivers for your audience.

Delivery cost: when it becomes the dominant line item

The $5/month storage base is predictable. The $1/100,000 delivery unit is where high-traffic projects get surprised.

A marketing site doing 500,000 image requests per month (not unusual once you factor in retina variants, OG images, and mobile breakpoints) adds $5/month in delivery on top of the base $5. That is $10/month total — cheap. At 5 million requests, you are at $50/month for delivery alone. A mid-sized e-commerce catalogue with aggressive variant counts can push this well past $100/month without the team noticing until the invoice arrives.

Cloudflare does not offer a spending cap on Images — only on Workers. Budget alerts via the Cloudflare dashboard exist but require manual setup.

Cloudflare Images vs Cloudinary: cost comparison

Cloudinary's free tier gives you 25 credits/month (roughly 25,000 transformations or 25 GB of managed storage, depending on how you spend the credits) before charging. Cloudflare Images has no free tier — you pay from the first image.

Factor	Cloudflare Images	Cloudinary Free → Paid
Free tier	None	25 credits/month
Storage base	$5/100k images	Included up to limit
Delivery fee	$1/100k requests	Per-credit model
On-the-fly transforms	Yes (flexible variants)	Yes
AI background removal	No	Yes (paid feature)
Next.js loader available	Community loaders only	Official loader
Sanity integration	Manual / webhook	Official plugin

For a small blog or portfolio under 10,000 images and modest traffic, Cloudinary's free tier wins on pure cost. For large catalogues where you are already a Cloudflare customer and want edge delivery baked in, Cloudflare Images starts to make sense — especially if you are already using Cloudflare Workers or R2 and want a unified vendor bill.

Cloudflare Images vs Sanity's own CDN

Sanity's asset pipeline delivers images from cdn.sanity.io, which is a Fastly-backed CDN. You get GROQ-driven URL transforms (?w=800&auto=format), hotspot-aware crops, and palette extraction — all without a separate image service account. Sanity's CDN costs are included in your Sanity plan (free tier: 10 GB bandwidth, Growth: 1 TB).

For most Next.js + Sanity projects I work on, there is no reason to also route images through Cloudflare Images. The Sanity CDN handles WebP and AVIF (auto=format), width capping, and quality tuning at the URL level. Adding Cloudflare Images means a separate upload step, a second monthly bill, and a custom next/image loader to replace the Sanity one.

The one exception is teams that already operate inside a Cloudflare-first infrastructure — Workers for server logic, R2 for assets, Pages for hosting — and want images to live in the same ecosystem with a single invoice. That is a workflow preference more than a performance decision.

What actually triggers an upgrade

You exceed 100,000 stored originals (Cloudflare automatically bills the next $5 block).
Your monthly delivery volume climbs past the point where the per-100k charge becomes material against your margin.
You need Cloudflare Images Flexible Variants with custom aspect ratios that are not expressible in named variants — these require a plan with flexible variants enabled, which is included in the standard paid offering but not available on any "free" workaround.

Practical recommendation

If you are running a Next.js + Sanity project and looking for an image CDN, start with Sanity's built-in CDN and next/image configured with a Sanity loader. It is the lowest-friction path and the cost is already inside your Sanity subscription. Only consider Cloudflare Images if your infrastructure is already Cloudflare-native, you have an existing R2 bucket you want to connect, or you are running a catalogue large enough that the flat-rate $5/100k storage model is cheaper than per-transformation pricing from alternatives.

For projects with over 500,000 stored images, do the unit economics: Cloudflare's $5/100k storage scales linearly and predictably, which can beat Cloudinary's transformation-based model at scale — but only if delivery volume stays moderate relative to the stored count.

Vercel Blob Pricing 2026: Free Tier Limits, Storage Costs & When to Upgrade

Nayan Kyada — Sun, 20 Sep 2026 09:23:13 +0000

Vercel Blob is the managed object storage built into the Vercel platform, and its pricing model is easy to misread until your first bill arrives. This post breaks down exactly what you get on the free tier, what triggers an upgrade, and how the per-GB numbers compare once you are paying.

What Vercel Blob actually is

Vercel Blob stores unstructured files — images, PDFs, video clips, generated exports — behind Vercel's edge network. It is not a CDN wrapper around S3 you manage yourself; Vercel handles the bucket, the access tokens, and the edge cache. You upload from a route handler or server action and get back a public URL immediately.

For Next.js projects, the integration is tight. A put() call in a route handler uploads the file; the returned URL is already edge-cached and ready to pass to next/image or serve directly. There is no separate AWS console, no CORS policy to debug, no presigned URL dance for most use cases.

That convenience has a cost, and that cost is where buyers routinely underestimate spend.

Free tier limits in detail

As of September 2026, the Hobby plan includes:

Resource	Free allowance
Storage	500 MB total
Bandwidth (egress)	1 GB / month
Simple operations (GET, HEAD)	100,000 / month
Write operations (PUT, DELETE)	1,000 / month
Projects	1 (Hobby plan limit)

The 500 MB storage cap is cumulative, not monthly. Upload 100 MB of images in January and leave them there — you have 400 MB remaining forever, not reset on February 1. Bandwidth and operations reset monthly.

1,000 write operations sounds like a lot until you build a user-generated content feature, a PDF export pipeline, or anything that creates one blob per user action. A modest SaaS with 50 active users each uploading a few files per week will clear this in days.

Pro plan pricing

Moving to the Pro plan ($20/month per account) raises the included allowances and switches you to pay-as-you-go overages:

Resource	Pro included	Overage rate
Storage	5 GB	$0.023 / GB / month
Bandwidth (egress)	100 GB	$0.08 / GB
Simple operations	10,000,000 / month	$0.0004 / 1,000
Write operations	500,000 / month	$0.005 / 1,000

The storage rate of $0.023 per GB per month puts Vercel Blob notably above Cloudflare R2 ($0.015/GB, zero egress fees) and above standard S3 us-east-1 ($0.023/GB with egress on top). You are paying for the integration convenience and the edge caching, not raw storage economics.

Bandwidth at $0.08/GB is the line item most teams miss. A site serving 10,000 image downloads per month at an average of 400 KB each burns through 4 GB of egress. That is $0.32 in overages — negligible. Scale to 500,000 downloads and it is $16/month on top of the Pro base. At image-heavy traffic levels — think a marketplace or a media archive — egress becomes the dominant cost fast.

What actually triggers an upgrade from Hobby

Three real scenarios push teams off the free tier:

User file uploads. Any feature where end users submit files — avatars, documents, attachments — hits the 1,000 write limit within weeks on a live product. A form that auto-saves drafts as blobs will do it in days.

Automated exports or reports. If your app generates a PDF or CSV per user action and stores it in Blob, each generation is a write. A workflow automation tool or reporting dashboard can generate thousands of writes per day.

Storage accumulation. 500 MB runs out faster than developers expect when files are not pruned. Profile photos at 200 KB each cap out after 2,500 users. If you are not deleting old blobs, you will hit the ceiling.

Bandwidth alone rarely triggers a Hobby-to-Pro jump because 1 GB of monthly egress is a low bar — even a small portfolio site can exceed it if it serves full-resolution images without resizing.

Vercel Blob vs Cloudflare R2 vs Supabase Storage

	Vercel Blob (Pro)	Cloudflare R2	Supabase Storage (Pro)
Storage cost	$0.023/GB/mo	$0.015/GB/mo	$0.021/GB/mo
Egress cost	$0.08/GB	$0.00	$0.09/GB
Free storage	5 GB (included)	10 GB/mo	100 GB (included)
Free egress	100 GB (included)	Unlimited	Unlimited
Next.js integration	Native	Manual (S3-compatible)	SDK required
Edge cache	Yes (automatic)	Workers required	No

Cloudflare R2's zero egress fee changes the economics entirely at scale. If you are serving large files or high download volumes, R2 will cost significantly less even after accounting for setup effort. Supabase Storage makes sense if you are already on Supabase for Postgres — the 100 GB free storage included with the Pro plan is generous for most early-stage products.

Vercel Blob wins on integration speed and operational simplicity. If your team wants to upload a file in a route handler and never think about storage configuration again, the premium over R2 is often worth paying — up to a point.

When the economics flip

Run the numbers at scale: a product storing 50 GB and serving 1 TB of monthly downloads.

Vercel Blob Pro: storage overage (45 GB × $0.023) = $1.04 + bandwidth overage (900 GB × $0.08) = $72. Total overage: ~$73/month plus $20 base.
Cloudflare R2: storage (50 GB × $0.015) = $0.75. Egress: $0. Total: ~$1/month plus Cloudflare account.

At that volume, the $90+ monthly delta funds a lot of engineering hours to wire up R2 manually. The crossover point for most teams is somewhere around 200–300 GB of monthly egress — below that, the Vercel Blob convenience is worth the overhead; above it, R2 or a dedicated CDN pays for itself quickly.

Practical recommendations

Stay on Vercel Blob Hobby if you are prototyping or running an internal tool with low file volume. Move to Pro when you hit write limits or need multiple projects. Evaluate R2 or Supabase Storage when your monthly blob egress consistently exceeds 200 GB or your stored file count grows into the tens of thousands without regular pruning.

For Next.js + Sanity projects specifically: Sanity already handles your content images through its own CDN with auto-format and resize. Vercel Blob fills the gap for user-generated uploads, generated exports, and anything Sanity's asset pipeline is not designed for. In that pairing, Blob usage tends to stay low enough that the Pro included allowances cover most teams comfortably.

Sanity vs Ghost for Next.js in 2026: An Honest Comparison

Nayan Kyada — Sat, 19 Sep 2026 08:53:46 +0000

Sanity vs Ghost is a comparison that comes up more than you'd expect — usually from a team that started on Ghost for its built-in blog UX and is now asking whether they need something more structured as the project grows. Both can feed a Next.js App Router frontend over an API, but the fit is very different depending on who's editing content and how complex your data model gets.

What each tool is actually for

Ghost is a publishing platform first. It ships with its own frontend theme layer, a paid newsletter product, a membership/subscription system, and a clean editor optimised for long-form writing. The headless Content API was added later — it works, but it's clearly not the primary design goal. If you want to use Ghost purely as a headless CMS for Next.js, you're buying a platform that ships a lot of things you won't use.

Sanity is a content platform built API-first. There is no built-in frontend. Every content type, every field, every relationship is defined in code via schema files that you own and version. The Studio is a React app you deploy and customise. GROQ is the query language, and it's genuinely expressive — joins, projections, conditional fields, and array flattening are all first-class. There is no newsletter, no subscription billing, no built-in theme engine. That's the trade.

Content modelling flexibility

This is where the gap is largest. Ghost gives you posts, pages, tags, and authors. You can add custom fields via its custom_template patterns, but you cannot define arbitrary document types. If your site needs product pages, event listings, a structured FAQ, or any schema that isn't "article with tags", Ghost doesn't support it without bolting on a separate CMS.

Sanity's schema system is code-defined. You write a defineType call per document type, add fields, set validation rules, add custom input components, and ship it. A product catalogue, a multi-locale site structure, a video series with episode metadata — all of that is standard Sanity work. TypeGen generates TypeScript types from your schema so your Next.js components are fully typed end to end.

GROQ vs Ghost Content API

Ghost's Content API is a REST API. You can filter posts by tag, author, and date, paginate, and include related resources. It is predictable and well-documented. For a blog it is fine.

GROQ gives you relational queries in a single round-trip. You can join references, project only the fields you need, flatten nested arrays, and use conditional projections to keep payloads small. For a complex content model, GROQ means one query instead of four API calls.

// Sanity: fetch a post with its author, category, and only the image fields needed
*[_type == "post" && slug.current == $slug][0] {
  title,
  publishedAt,
  "author": author->{ name, "avatar": image.asset->url },
  "category": category->{ title, slug },
  body,
  mainImage {
    asset->{ url, metadata { lqip, dimensions } },
    hotspot,
    alt
  }
}

With Ghost you'd call /posts/{slug}/?include=authors,tags and get back every field on every related resource, then filter in JavaScript. Not the end of the world for a blog, but the payload is larger and you don't control the shape.

Editor experience

Ghost wins here for writers. The editor is clean, fast, Notion-like, and has bookmark cards, callout blocks, and image galleries built in. Editors don't need onboarding; they can sit down and publish. Membership management, email newsletters, and subscriber analytics are all inside the same dashboard. If your client is a solo writer or a small editorial team, that matters.

Sanity Studio is powerful but requires setup. Portable Text is flexible, but you need to define every custom block type. A well-configured Studio with correct ordering, grouping, and custom inputs is genuinely good — but it takes developer time to get there. The benefit is that you can make the Studio look exactly like the content model needs it to look. The downside is that a freshly scaffolded Studio with default settings can feel sparse compared to Ghost.

Pricing comparison

Feature	Ghost Pro (Creator)	Ghost Pro (Team)	Sanity Free	Sanity Growth
Monthly cost	$25	$50	$0	$15/project
Members/subscribers	500	1,000	N/A	N/A
API requests	Unlimited	Unlimited	Unlimited	Unlimited
Custom domains	1	1	Via own deploy	Via own deploy
Collaborators	1	5	Up to 3	Up to 25
Self-host option	Yes (open source)	Yes	Free tier	Growth+
Content history	Limited	Limited	Full	Full

Ghost is open source and self-hostable on a $6/mo VPS. The Ghost Pro pricing above is for managed hosting — and it bundles newsletter delivery, so if you need that, it's genuinely cheap. If you're using Ghost purely as a headless CMS, self-hosting makes more sense because you're not using the newsletter infrastructure you'd be paying for.

Sanity's free tier covers most small projects: three non-admin users, one dataset, unlimited API calls, 10 GB bandwidth, 20 GB assets. Growth at $15/project/month unlocks more collaborators and multiple datasets (useful for staging). If you're building for an agency client, Sanity's pricing scales by project rather than by member count — that's usually better.

When to pick Ghost

Choose Ghost if the site is primarily a publication — newsletter, paid memberships, long-form articles — and the editor experience has to be zero-friction from day one. If the client already has a Ghost audience and wants to port the frontend to Next.js while keeping Ghost's email and subscriber tooling, that's a legitimate headless Ghost use case.

When to pick Sanity

Choose Sanity if the content model goes beyond posts and pages, if you need typed queries, if you're building for a product or marketing team that needs custom document types, or if you're working inside an agency with multiple projects that share schema patterns. Sanity's TypeGen, GROQ, and structured schema approach are substantially better for anything that isn't a pure publishing workflow.

Mixing both

Some teams run Ghost for the editorial/newsletter side and Sanity for the marketing and product content. The Next.js frontend fetches from both APIs and merges the data at the RSC layer. It works, but it adds operational complexity — two CMS dashboards, two sets of webhooks, two deploy paths. Only worth it if you genuinely need Ghost's subscriber features and Sanity's modelling power in the same project.

For most Next.js projects I quote, Sanity is the right call. The schema flexibility and GROQ expressiveness pay off before the project is done. Ghost is the right call when the client is a writer who needs to send newsletters next week.

Sanity vs WordPress.com Pricing 2026: Real Costs at Every Scale

Nayan Kyada — Thu, 17 Sep 2026 09:34:13 +0000

Sanity CMS and WordPress.com are two of the most common recommendations developers pass to clients who ask 'what should I build on?' — and the pricing logic for each is almost completely different. Sanity charges per dataset bandwidth and API usage; WordPress.com charges per publishing feature and removes branding. Comparing them by headline plan price alone will mislead you.

What you actually get on the free tier

Sanity's free tier (Free plan) gives you three users, two datasets, 500k API CDN requests per month, 20GB bandwidth, and 5GB of asset storage. There is no watermark, no domain restriction, and no expiry. You can ship a real production site on the free plan if your traffic is modest.

WordPress.com's free tier gives you a yoursite.wordpress.com subdomain, 1 GB storage, WordPress ads served on your pages, and no custom plugins. It is not viable for a client-facing site without upgrading. The ads alone make it a no.

Feature	Sanity Free	WordPress.com Free
Custom domain	Yes (your own hosting)	No
Ads on your content	None	Yes (WP ads)
Plugin support	Full (it's an API)	None
Storage	5 GB assets	1 GB total
Users	3	1
API requests/month	500k CDN	N/A
Staging viable	Yes	No

Paid plan structure and where costs jump

Sanity has two named paid tiers: Growth ($15/month per project) and Enterprise (custom). Growth removes most free-tier limits — 25 users, 25 datasets, 1M API CDN requests, 100 GB bandwidth, 100 GB storage. Overages are metered: $0.017 per 1000 additional API CDN requests, $0.10/GB additional bandwidth, $0.06/GB additional storage.

WordPress.com has four paid tiers as of mid-2026:

Starter — $9/month (annual): custom domain, no ads, 6 GB storage. Still no plugins.
Explorer — $18/month: 50 GB storage, still no third-party plugins.
Creator — $40/month: unlimited plugins, Jetpack extras, ability to monetise.
Entrepreneur — $70/month: WooCommerce, premium themes, priority support.

Plan	Monthly cost	Plugins	Storage	Custom domain
Sanity Free	$0	N/A (API)	5 GB	Yes (self-host)
Sanity Growth	$15	N/A (API)	100 GB	Yes (self-host)
WP.com Free	$0	No	1 GB	No
WP.com Starter	$9	No	6 GB	Yes
WP.com Explorer	$18	No	50 GB	Yes
WP.com Creator	$40	Yes	Unlimited	Yes
WP.com Entrepreneur	$70	Yes + WooCommerce	Unlimited	Yes

The critical inflection point for WordPress.com is Creator at $40/month, because that is where plugins unlock. Below that, you cannot install ACF, Yoast, WooCommerce, custom contact forms, or any third-party plugin. Many buyers do not realise this until after they have committed to a cheaper plan.

Hosting cost is apples to oranges

WordPress.com includes hosting — that is the product. Sanity is a content API; you still need a front end hosted somewhere. For a Next.js project, that is typically Vercel (Hobby free or Pro at $20/month per member) or a VPS.

So a fair apples-to-apples comparison for a small client site:

Sanity Free + Vercel Hobby: $0/month. Legitimate production option for low-traffic sites with one developer.
Sanity Growth + Vercel Pro: $15 + $20 = $35/month before usage overages.
WordPress.com Creator: $40/month all-in, hosting included.

At that level they are roughly equivalent in price. But what you get is very different. Sanity + Next.js gives you a decoupled architecture, full control over rendering (SSR, ISR, PPR), and no platform lock-in on the front end. WordPress.com Creator gives you a managed monolith with the WordPress editor and plugin ecosystem — zero infrastructure overhead, but you cannot deploy your own rendering layer.

What actually triggers an upgrade on each platform

On Sanity, the triggers are almost always traffic-driven:

Exceeding 500k API CDN requests/month (this is easier to hit than it sounds if you are not caching GROQ responses at the edge)
Exceeding 20 GB bandwidth (large image libraries, un-optimised Sanity image URLs)
Needing a fourth collaborator in the Studio

On WordPress.com, the triggers are feature-driven:

Needing a custom plugin → Creator ($40)
Needing WooCommerce → Entrepreneur ($70)
Needing a custom domain without paying → Starter ($9)

WordPress.com's model gates capability behind price. Sanity's model gates capacity behind price. These are fundamentally different lock-in vectors.

Which one is actually cheaper over two years

For a content-only marketing site with a competent developer:

Sanity Free + Vercel Hobby → year one: $0. Year two: $0. Unless traffic grows past free-tier limits.
WordPress.com Creator → year one: $480. Year two: $480. Flat, predictable, no surprises.

For a site that needs plugins and is run by a non-technical editor without a developer on retainer, WordPress.com Creator's $40/month is genuinely good value. You are paying for managed infrastructure, automatic updates, and a familiar editing interface.

For a site being built by a developer who will own the front end, Sanity wins on total cost at every traffic level until you hit enterprise scale. The free tier is real, the Growth tier at $15 is cheaper than any plugin-capable WordPress.com plan, and you are not paying for hosting twice.

Egress and API costs at scale

This is where WordPress.com's pricing model actually becomes an advantage for some buyers. WordPress.com has no egress or API call charges — you pay a flat rate regardless of traffic. Sanity's Growth plan charges $0.10/GB over 100 GB bandwidth and $0.017 per 1000 API CDN requests over 1M/month.

If you are running a high-traffic editorial site with millions of monthly visitors, Sanity overage costs can accumulate. The fix is aggressive edge caching of GROQ responses and serving all images through next/image with a CDN prefix rather than direct Sanity CDN hits — but that requires developer time WordPress.com does not.

For non-developers or small teams without a developer on retainer, WordPress.com's flat pricing removes an entire category of infrastructure anxiety.

The honest recommendation

Choose Sanity if you have a developer, want a custom front end, and need full control over performance and rendering. The free tier is genuinely usable, Growth at $15 is cheaper than WordPress.com Creator, and the architecture will not paint you into a corner when requirements change.

Choose WordPress.com Creator or Entrepreneur if the buyer is non-technical, does not want a developer relationship, needs the WordPress plugin ecosystem, and values a single flat monthly bill with no infrastructure decisions.

Sanity vs Webflow for Next.js in 2026: An Honest Comparison

Nayan Kyada — Wed, 16 Sep 2026 09:24:25 +0000

Sanity vs Webflow comes up more often than you'd expect when clients are scoping a content site. Both can produce a fast, polished result — but they sit at completely opposite ends of the control spectrum, and choosing the wrong one creates real pain later. Here's how I think through the decision for Next.js projects.

What each tool actually is

Webflow is a visual website builder with a built-in CMS, hosting, and a designer-first editor. You draw layouts in a canvas, bind them to CMS fields, and publish — all inside Webflow's infrastructure. There's no separate deployment step unless you go headless (Webflow's API plan), and even then, you're working around a tool that was never designed as a pure API.

Sanity is a headless CMS and nothing else. It gives you a content API (GROQ over HTTP), a fully customisable Studio, and no opinions about your frontend. You bring the Next.js app, the hosting, the image CDN strategy, and the deployment pipeline. More moving parts, more control.

Editor experience

Webflow wins on day-one editor experience for non-technical teams. The CMS editor is visually tied to the design — editors see roughly what they'll publish. There's nothing to install, and Webflow University covers most questions.

Sanity's Studio is excellent once configured, but it needs configuration. Out of the box, editors see fields, not pages. You need Portable Text components, custom previews, and Presentation mode wired up before it feels as intuitive as Webflow. For a team of two editors running a blog, Webflow has a lower onboarding cost. For a team managing 10 content types, 4 locales, and document relationships, Sanity's structured model scales better.

Developer control and Next.js integration

Webflow's native hosting can't run Next.js at all. If you want App Router, RSC, or ISR, you must use Webflow's CMS API (available on Business plan and above, $39/month minimum). The API is REST-only, rate-limited, and the data model reflects Webflow's visual metaphors rather than your own schema. Querying nested references involves multiple round-trips — there's no GROQ equivalent.

Sanity integrates with Next.js natively. GROQ projections let you fetch exactly the shape you need in a single request, refs are resolved in the query, and next-sanity gives you typed fetchers with built-in draft mode and live preview. TypeGen produces TypeScript types from your schemas, so your RSC components stay type-safe end to end.

// app/posts/[slug]/page.tsx — Sanity GROQ fetch, typed
import { sanityFetch } from '@/lib/sanity/client'
import type { PostQueryResult } from '@/sanity.types'

const POST_QUERY = `*[_type == "post" && slug.current == $slug][0]{
  title,
  body,
  "lqip": mainImage.asset->metadata.lqip,
  "dimensions": mainImage.asset->metadata.dimensions
}`

export default async function PostPage({ params }: { params: { slug: string } }) {
  const post = await sanityFetch<PostQueryResult>({ query: POST_QUERY, params })
  // ...
}

You can't write anything equivalent with Webflow's API without chaining multiple REST calls and manually assembling the shape yourself.

Pricing side-by-side

Feature	Webflow	Sanity
Free tier	2 pages, no custom domain, 50 CMS items	3 users, 10 k CDN req/month, 3 datasets
Entry paid plan	Starter $14/mo (2 locales, 100 CMS items)	Growth $15/mo (20 users, 25 k CDN req/month)
Custom code / API access	Business $39/mo	All plans (REST + GROQ)
CMS API (headless)	Business $39/mo minimum	Included on free tier
Localisation	Add-on, $9/mo per locale	Plugin, included in Growth
Editor seats	Included in plan	Priced at Growth tier
Bandwidth	50 GB on Business	Sanity CDN; Next.js host bills separately
Image transforms	Included, Webflow CDN	Included via Sanity image pipeline

For a simple marketing site with five pages, Webflow's Starter is cheaper and requires no developer time after launch. For anything that hits the API, you're on Business ($39/month) and the cost math changes. Add localisation ($9 per locale), and a three-language site costs $66/month from Webflow before hosting. Sanity Growth at $15/month covers 20 users and plugin-based i18n with no per-locale charge.

The real cost difference is developer time. A Webflow site can go live with zero custom code. A Sanity + Next.js site needs a developer who can build and maintain the frontend. For content-heavy products where that developer exists anyway (or is you), Sanity's monthly cost is lower and the capability ceiling is much higher.

SEO and Core Web Vitals

Webflow's hosted output is server-rendered HTML, which is fine for basic SEO. The problem is you can't control rendering strategy. There's no ISR, no PPR, no edge caching granularity. JSON-LD can be injected via custom code embeds, but it's brittle.

With Sanity + Next.js, you own the full metadata pipeline — generateMetadata, per-route JSON-LD components, and image optimisation via next/image with LQIP from Sanity's metadata palette. LCP is a known quantity you can instrument and tune. Webflow sites regularly score well on Lighthouse until they accumulate designer-added animations, third-party embeds, and large hero images without proper sizes attributes.

When to pick Webflow

The client owns and updates the site themselves, no developer on retainer
The design needs to stay editable visually by non-technical staff
Budget doesn't support ongoing Next.js frontend maintenance
The site is a brochure with fewer than 50 CMS items and no complex data relationships

When to pick Sanity + Next.js

Content has relationships: authors, categories, tags, referenced media
Multiple locales with structured field-level translation
Performance requirements are contractual — you need measurable LCP and CLS targets
The product is the content: a publication, a docs site, or an app that blurs the CMS line
A developer will be involved long-term anyway

The edge case: Webflow as design, Sanity as CMS

Some teams try to export Webflow HTML and run it inside a Next.js app. It rarely ends well — the output is tightly coupled to Webflow's class conventions and JavaScript. The cleaner split is to use Webflow for design prototyping and hand the final designs to a developer who implements them in Next.js against Sanity. You get Webflow's visual design speed without locking your production app into Webflow's runtime.

Sanity vs WordPress Headless vs Webflow: Three-Way CMS Comparison for Next.js

Nayan Kyada — Tue, 15 Sep 2026 09:31:35 +0000

Choosing between Sanity, headless WordPress, and Webflow for a Next.js project is one of the most common scoping questions I get from agency owners and founders. Each platform has a real use case — and each has failure modes that are predictable if you know what to look for. This post lays out the three-way comparison honestly, with concrete numbers where they exist.

Why these three specifically

These are the three options that show up in almost every proposal I write or review. WordPress because a client already has ten years of content in it. Webflow because a designer put together a prototype that looked great. Sanity because a developer on their team heard about it on a podcast. None of those are bad reasons to start a conversation — but they're not reasons to commit, either.

Headless WordPress means keeping WP as a content backend, exposing content via WPGraphQL or the REST API, and building the front-end in Next.js. Webflow's CMS can be queried via its API and used similarly. Sanity is purpose-built as an API-first headless CMS with a hosted Studio and strong TypeScript tooling.

Developer experience compared

Sanity wins here, and it's not especially close. GROQ is expressive and fast, TypeGen generates fully typed query results with one command, and the schema is plain TypeScript objects you version-control alongside your app. When a junior developer on your team touches the schema, TypeScript yells at them before production does.

Headless WordPress is a different story. WPGraphQL is a solid library, but WordPress was not designed to be an API backend. Custom post types, ACF, and Yoast all add friction. Every plugin you add to the WP install is a potential REST or GraphQL surface that breaks unexpectedly, and local dev with a MySQL database is significantly heavier than sanity dev spinning up in five seconds.

Webflow's API is a REST-only JSON API with per-collection rate limits (100 requests per minute on the Lite and CMS plans, 120 on Business). It has no GraphQL option, no SDK worth using in production, and the response shapes change if an editor renames a field in the Webflow designer. That last point has broken production builds for clients without warning.

Editor experience compared

This is where the ranking changes. Webflow's editor is the most polished for non-technical users — visual layout controls, inline editing on the canvas, and designer-friendly UI that marketing teams understand on day one. The trade-off is that editors are editing inside Webflow's layout constraints, which limits what you can do on the Next.js front-end.

WordPress's editor (Gutenberg) is familiar to a huge slice of the web. If your client's content team has been in WordPress for a decade, retraining cost is real and should not be hand-waved away in a proposal. Headless WordPress lets you preserve that familiarity while modernising the front-end.

Sanity Studio is powerful but requires onboarding. The Portable Text editor is excellent once editors understand it, and custom input components let you tailor the Studio to your content model precisely. I've found that editors who use Studio for three weeks stop asking for WordPress back — but the first week requires guidance.

Pricing at real project scale

Plan tier	Sanity	Headless WordPress	Webflow CMS
Free / entry	Free (3 users, 10k API req/day, 10 GB bandwidth)	Free (self-host on any VPS, ~$6–12/mo infra)	Lite: $18/mo, 50 CMS items
Mid-tier	Growth: $15/mo per project (20 users, 1M API req/day)	Managed WP (Kinsta, WP Engine): $35–100/mo	CMS: $29/mo, 2,000 items
Team / agency	~$50–200/mo depending on bandwidth and API usage	$100–300/mo for managed, reliable infra	Business: $74/mo, 10,000 items
Enterprise	Custom (audit logs, SSO, SLA)	Custom (VIP, Pantheon)	Enterprise: custom
CMS item / record limit	Unlimited documents on all plans	Unlimited posts	Hard cap per plan
Bandwidth overages	$0.10/GB above plan limit	Depends on host	Included in plan; API has rate limits

Webflow's per-item caps are the most painful constraint in practice. A site with a large product catalogue or archive will outgrow the CMS plan quickly, and jumping to Business at $74/mo just to get 10k items is a hard conversation to have after launch.

Sanity's Growth plan at $15/mo covers the majority of mid-size editorial sites. The cost driver on Sanity at scale is bandwidth for asset delivery and API request volume — both predictable and visible in the dashboard.

Headless WordPress infrastructure cost is the most variable. A poorly cached, auto-scaled WP install on WP Engine or Kinsta for a traffic-heavy site can easily run $200+/month. With aggressive page caching and a static front-end, the WP API layer barely moves — so Next.js ISR or full static export can keep costs near the floor.

Next.js integration depth

Sanity has first-class Next.js integration: @sanity/next-sanity, the Presentation plugin with live preview over draft content, GROQ-powered ISR tag revalidation via webhooks, and image URLs with auto=format for WebP/AVIF delivery via next/image. Structured data, sitemap generation, and metadata are all straightforward because query results are typed and predictable.

Headless WordPress works with Next.js but requires more wiring. WPGraphQL with Incremental Static Regeneration is a common pattern, but tag-based revalidation requires custom webhook logic. Image optimisation is less clean: WordPress serves images from its media library, which means either proxying through next/image with an allowed domain config or pulling URLs through Cloudinary/Imgix separately.

Webflow's API is not built for ISR. Polling or time-based revalidation is the typical approach because Webflow doesn't offer webhook-based cache invalidation for content changes at the CMS tier. Building a Webflow-backed Next.js site with real-time-ish content freshness is awkward.

Decision table

Factor	Choose Sanity	Choose Headless WP	Choose Webflow
Developer ergonomics	✓ Best in class	Acceptable	Limited
Editor familiarity (existing WP team)	Needs onboarding	✓ No retraining	Moderate
Visual page builder for marketing	Studio + custom inputs	Gutenberg	✓ Native canvas
Next.js ISR + typed queries	✓ First-class	Possible, more work	Awkward
Predictable pricing at scale	✓ Yes	Infra-dependent	Hard item caps
CMS item limits	None	None	2k–10k by plan
Local dev speed	✓ Fast	Slow (MySQL)	API-only, no local

Which one I actually recommend

For greenfield Next.js projects with a modern content team: Sanity. The TypeScript integration alone saves hours per week on mid-size engagements, and Growth pricing is reasonable.

For clients with an entrenched WordPress editorial workflow and five years of posts they don't want to migrate: headless WordPress. Budget for proper caching infrastructure. Don't run it on a $10 shared host and wonder why TTFB is 800ms.

For marketing teams that want to control layout without developer involvement — and have a small, bounded content set: Webflow CMS, but not as a headless backend for Next.js. Webflow works best as its own front-end, not as a content API for someone else's renderer. Mixing the two adds complexity without much gain over picking one primary tool.

Sanity vs Hashnode vs Dev.to: Headless Blog Platform Comparison 2026

Nayan Kyada — Mon, 14 Sep 2026 10:01:45 +0000

Choosing a platform for a developer blog in 2026 means picking between three very different mental models: a fully programmable headless CMS (Sanity), a managed developer blogging network (Hashnode), and an open community platform (Dev.to). The right answer depends on how much you value SEO control, Next.js integration depth, and long-term data portability over time-to-first-post.

What each platform actually is

Sanity is a headless CMS with a hosted content lake, a React-based Studio you deploy yourself, and a GROQ query API. You own the schema, the frontend, and the rendering pipeline. Nothing is opinionated about how your blog looks or where it lives.

Hashnode is a managed blogging platform aimed at developers. You write in Markdown, posts live on a Hashnode subdomain by default, but you can map a custom domain. There is a GraphQL API and, as of 2025, a headless mode that lets you pull content into your own Next.js frontend.

Dev.to (Forem) is a community publishing platform. Content lives on dev.to under their domain. There is a public REST API. You cannot meaningfully run Dev.to headless in the same way — it is primarily a distribution channel, not a CMS.

Feature comparison

Feature	Sanity	Hashnode	Dev.to
Custom domain (SEO authority)	Yes — your domain	Yes (custom domain on paid plan)	No — dev.to domain only
Headless / API-first	Yes — GROQ + CDN	Yes — GraphQL Headless API	Partial — REST API, no real headless mode
Next.js integration	First-class (official SDK, TypeGen)	Usable (community adapters)	Manual REST calls only
Schema control	Full TypeScript schemas	Fixed article model	Fixed article model
Structured data / JSON-LD	You implement it	Limited, platform-generated	Platform-generated, minimal
Draft / preview workflow	Full draft mode + Presentation	Basic draft	Basic draft
Image CDN	Sanity CDN (auto WebP/AVIF)	Hashnode CDN	Dev.to CDN
Free tier	2 datasets, 10 GB bandwidth	Free (subdomain), $19/mo custom domain	Free
Paid tier entry	$15/mo (Growth)	$19/mo (Pro)	$9.99/mo (Pro, no headless unlock)
Data portability	Full JSON export any time	Markdown export	Markdown export
Community reach	None (you build it)	Built-in Hashnode feed	Large built-in audience

SEO and domain authority

This is where the platforms diverge most sharply. With Sanity and a self-hosted Next.js frontend, every post lives on your domain. Internal linking, canonical tags, structured data, and sitemap generation are entirely in your hands — which matters for compounding domain authority over years.

Hashnode with a custom domain is a legitimate middle ground. Posts on blog.yourdomain.com accumulate PageRank on your domain, not Hashnode's. The trade-off is that your structured data options are limited to what Hashnode's renderer emits, and you cannot add custom JSON-LD per post without the headless mode.

Dev.to is a distribution play, not an SEO play. Posts live on dev.to/yourhandle. You can set a canonical URL pointing back to your own site, which is the correct pattern if you cross-post — but many people don't, and those posts build dev.to's authority, not yours.

Next.js integration depth

Sanity's next-sanity package gives you ISR revalidation via webhooks, typed GROQ queries through TypeGen, draft mode via Presentation, and a live preview overlay. It is the most production-ready pairing covered here.

Hashnode's headless mode exposes a GraphQL API. You can fetch posts in a Next.js route handler or server component, but there is no official Next.js SDK. A minimal fetch looks like this:

// app/blog/page.tsx — fetching Hashnode posts in a RSC
const HASHNODE_ENDPOINT = 'https://gql.hashnode.com';

async function getPosts() {
  const res = await fetch(HASHNODE_ENDPOINT, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `{
        publication(host: "blog.yourdomain.com") {
          posts(first: 10) {
            edges {
              node { title slug publishedAt brief }
            }
          }
        }
      }`,
    }),
    next: { revalidate: 3600 }, // ISR — no webhook revalidation available
  });
  const { data } = await res.json();
  return data.publication.posts.edges.map((e: { node: unknown }) => e.node);
}

Note the revalidate: 3600 — Hashnode does not send webhook payloads to your Next.js revalidation endpoint. You are on time-based ISR, which means stale content for up to an hour after a publish. Sanity + HMAC webhooks gives you on-demand revalidation within seconds.

Dev.to integration is just a REST fetch. There is no GraphQL, no revalidation hook, and no schema control.

Real running costs

For a solo developer blog publishing one to four posts a month:

Sanity free tier covers 10 GB CDN bandwidth and two datasets. For a blog with under a few thousand monthly readers, you stay free indefinitely. Growth plan at $15/mo adds 1 TB bandwidth and more API calls.
Hashnode free works if you accept the hashnode.dev subdomain. The $19/mo Pro plan unlocks a custom domain, which is the only tier worth using for SEO purposes. No infrastructure to manage.
Dev.to is free and stays free. No custom domain, no infrastructure cost, but also no accumulated domain authority.

For an agency or product team running a content marketing blog at scale (50k+ monthly readers, 200+ posts), Sanity's Growth plan at $15/mo plus Vercel hosting (roughly $20/mo on the Pro plan) is still cheaper than Hashnode Pro once you factor in what you get: full schema control, webhook revalidation, TypeGen, and an image pipeline that serves AVIF from the same CDN URL.

When each platform makes sense

Choose Sanity when SEO is a revenue driver, you want full schema control, your blog is part of a larger Next.js site, or you need structured data, custom fields, and a content team workflow. The setup overhead is real but amortised over years of compounding authority.

Choose Hashnode headless when you want faster time to first post, do not want to manage a Sanity Studio deployment, and are comfortable with a fixed content model. The GraphQL API is clean and the custom domain option makes it a legitimate SEO choice.

Use Dev.to as a cross-posting distribution channel alongside your canonical source — not as your primary CMS. Set canonical URLs on every Dev.to post pointing back to your domain. Never let Dev.to be the only place a post lives if organic search matters to you.

Cloudflare R2 Pricing 2026: Free Tier Limits, Egress Costs & When to Upgrade

Nayan Kyada — Sun, 13 Sep 2026 09:39:09 +0000

Cloudflare R2 keeps coming up as an asset storage option for Next.js and Sanity projects, mostly because of one selling point: zero egress fees. But the free tier has real limits, and the per-operation pricing model trips people up. This post breaks down exactly what R2 costs in 2026, where the free tier runs out, and whether it makes sense over S3 or Cloudinary for a content-heavy site.

What the R2 free tier actually includes

R2's free tier resets monthly and covers three distinct cost axes: storage, Class A operations (writes, lists, deletes), and Class B operations (reads/downloads). The headline numbers as of September 2026:

Resource	Free monthly allowance
Storage	10 GB
Class A operations (PUT, POST, DELETE, LIST)	1,000,000
Class B operations (GET, HEAD)	10,000,000
Egress (data transfer out)	Unlimited — $0.00

Egress being free is the actual differentiator. S3 charges $0.09/GB out to the internet. On a content site serving 20 GB/month of images, that's $1.80 per month from S3 before you touch operations — not catastrophic, but it compounds. Cloudinary's free tier caps at 25 GB of storage and bandwidth combined, so a busy month can knock you into a paid plan without warning.

For a Sanity project where image binaries live in Sanity's CDN and R2 is handling build artifacts, uploaded PDFs, or video segments, the free tier is rarely the bottleneck. Where it gets uncomfortable is when you start routing all your media through R2 — or when you lean on Workers to transform images at the edge.

Paid tier pricing

Once you exceed the free allowances, costs are straightforward but easy to under-estimate if you're only looking at storage:

Billable item	Price (2026)
Storage beyond 10 GB	$0.015 / GB / month
Class A operations beyond 1M	$4.50 per million
Class B operations beyond 10M	$0.36 per million
Egress	$0.00 (always)
R2 Super Slurper ingress from S3	$0.00

Storage pricing is competitive — AWS S3 Standard costs $0.023/GB, so R2 is roughly 35% cheaper per gigabyte. But R2's Class A operation cost is higher: S3 PUT requests run $0.005 per thousand ($5 per million) versus R2's $4.50. Close enough that it won't swing a decision.

The number that catches teams out is Class A operations during CMS-driven publishing workflows. Every time a Sanity webhook fires and your Next.js route handler writes a revalidated JSON blob or a pre-generated OG image back to R2, that's a Class A op. On a busy editorial day with 500 publishes, each triggering a cache-busted PUT, you're at 500 operations — nothing near the limit. But if you're also listing bucket contents for a sitemap job or running bulk migrations, the counter rises faster.

R2 vs S3 vs Cloudinary: cost comparison for a content site

Assumptions: 50 GB stored, 100 GB egress per month, 5 million Class A ops, 50 million Class B ops — roughly a mid-size marketing site with a lot of image variants.

Provider	Storage	Egress	Operations	Monthly total (approx.)
Cloudflare R2	$0.60	$0.00	$22.50 A + $14.40 B	~$37.50
AWS S3 Standard	$1.15	$9.00	$25.00 A + $20.00 B	~$55.15
Cloudinary (Growth)	$149/month flat (includes transforms)	included	included	~$149

Cloudinary is only worth the premium if you need on-the-fly image transformations — resizing, format conversion, face-detect cropping — without writing any code. If you're already handling image optimisation through next/image and serving pre-processed assets, you're paying for features you don't use.

R2 wins on egress-heavy workloads. S3 wins if you're already deep in the AWS ecosystem and want Lambda@Edge, SQS triggers, or tight IAM integration.

What triggers an R2 upgrade on a real Next.js project

Three scenarios push a project out of the free tier faster than expected:

1. Storing pre-generated Open Graph images. If you're generating OG images at build time or on-demand via a route handler and caching them in R2, every unique URL is a PUT. A blog with 2,000 posts means 2,000 Class A ops minimum — well inside the free tier. But if you're also generating per-locale variants, per-date variants, or resized versions, you can hit 10,000+ ops in one deployment.

2. ISR revalidation artifacts. Some teams write JSON snapshot files to R2 as part of their ISR warm-up strategy. Each Sanity webhook → revalidate → write-back cycle = 1 Class A op. At scale this adds up, but you'd need hundreds of publishes per day before it registers.

3. Video uploads routed through Workers. If you're uploading Mux-bound video files through a Cloudflare Worker that stages to R2 first, large multipart uploads count each part as a separate Class A op. A 2 GB video split into 5 MB parts is ~400 ops per upload.

For most Next.js + Sanity setups, R2 stays inside the free tier for months. The upgrade trigger is almost always storage (exceeding 10 GB) rather than operations.

R2 pricing requires a Workers Paid plan

This is the detail that surprises people: R2 requires a Cloudflare account on the Workers Paid plan ($5/month) to use in production. The free tier of R2 is accessible, but you cannot bind R2 buckets to deployed Workers or Pages Functions without the paid Workers plan.

If you're running a Next.js site on Cloudflare Pages and want R2 access via a route handler, you need to budget that $5/month base cost. It's not listed prominently in the R2 pricing page — it's buried in the Workers limits table.

For context: Vercel's equivalent (Vercel Blob, backed by Cloudflare R2 under the hood) starts at $0.023/GB on the Pro plan, with no separate operations charge visible to the user. You pay more per gigabyte but don't think about Class A/B splits. If you're already on Vercel Pro ($20/month), Vercel Blob's simplicity might be worth the storage markup.

When R2 makes sense vs when it doesn't

R2 is worth it when: you're already on Cloudflare for DNS/CDN, your primary cost driver is egress, you want a zero-surprise bill for serving static assets globally, and you're comfortable wiring up S3-compatible SDKs in your Next.js route handlers.

Skip R2 when: you need image transformation logic (use Sanity's native CDN or Cloudinary), you're on Vercel and want zero infra config (use Vercel Blob), or your team isn't familiar with Cloudflare Workers bindings and doesn't want to learn them for a side project.

The free tier is genuinely useful for small to mid-size projects. The $5/month Workers Paid base cost is the real minimum — plan for it from day one.