DEV Community: Nayan Kyada

CMS apps explained: what marketing and product teams actually get

Nayan Kyada — Tue, 21 Jul 2026 07:04:56 +0000

If you're researching CMS apps for your team and finding yourself buried in feature matrices and pricing pages, this is the post to read first. Before you evaluate any specific tool, it helps to understand what a modern CMS actually does — and where the real differences between products show up in daily editing work.

What CMS apps actually do

A content management system is software that lets non-developers create, edit, and publish content without touching code. That's the old definition. Modern CMS apps have expanded well beyond that: they now manage content structure, enforce editorial workflows, deliver content to multiple channels simultaneously, and connect to the rest of your marketing stack.

The shift matters because the original generation of CMS tools — WordPress, Drupal, older Joomla installations — bundled the editing interface, the content database, and the website display layer into one product. That worked fine when a website was the only destination for your content. It breaks down the moment you want the same product description to appear on a website, a mobile app, a digital kiosk, and an email campaign without copying and pasting between systems.

Modern CMS apps split those concerns apart, or at least give you more control over how they connect.

Content models: the layer most buyers overlook

Before your editors ever type a word, someone has to define what kinds of content exist in the system and what fields each type has. This is called the content model, and it's the most consequential architectural decision in any CMS project.

A content model for a software company might include document types like Blog Post, Case Study, Product Page, Team Member, and Pricing Tier. Each type has fields: a Blog Post has a title, a publication date, a main image, an author reference, and a body. A Pricing Tier has a name, a monthly price, a list of features, and a boolean for whether it's the recommended option.

Why does this matter to you as a buyer? Because a poorly designed content model creates editorial friction that compounds over years. If your Case Studies are modeled as a long unstructured text blob rather than discrete fields (client name, industry, outcome metric, quote), your team will fight the CMS every time they try to filter, sort, or reuse that content elsewhere. A good CMS app gives developers the tools to build a tight content model; a good developer actually uses them.

Different CMS apps approach content modeling differently. Some give you a fixed set of field types and a visual schema builder. Others — Sanity is the clearest example here — define schemas entirely in code, which means the model lives in version control, can be reviewed like any other change, and can be tested before deployment.

The editing interface

This is what most buyers focus on, and reasonably so — your marketing team will live in it every day. Modern CMS apps generally offer:

Structured fields. Dropdowns, date pickers, image uploaders, reference selectors. Editors fill in discrete fields rather than formatting everything inside a single rich-text box.

Rich text with portable structure. When you do need long-form text, good CMS apps represent it as structured data rather than raw HTML. This means you can render the same content differently on a website versus a mobile app, and custom components — a callout block, an embedded video, a product card — can be inserted inline without embedding fragile markup.

Visual previews. Most modern CMS apps support some form of live preview, where editors can see what a page will look like before publishing. The implementation quality varies significantly: some are full visual editing with click-to-edit overlays; others are just an iframe that refreshes when you save a draft.

Asset management. Images, documents, and video are usually managed inside the CMS or via a connected digital asset management tool. Decent CMS apps handle focal-point cropping (so an image looks right when displayed at multiple aspect ratios) and serve optimised formats automatically.

Publishing workflows

A basic CMS has two states: draft and published. Most teams outgrow that within months.

Marketing teams typically need: draft → internal review → legal or brand approval → scheduled publish → live. Product teams doing feature launches often need content staged and ready to go live the moment a deploy ships.

Look for CMS apps that support:

Role-based permissions. Editors create; senior editors approve; admins publish. A junior contractor should not be able to push to production.
Scheduled publishing. Set a date and time; the CMS handles the rest. Non-negotiable for any team running campaigns.
Content versioning. The ability to see what a document looked like three weeks ago and restore it if needed.
Draft preview URLs. Shareable links that show a draft to a stakeholder without publishing it publicly.

Not every CMS app does all of these well. Some charge extra for workflow features. Some implement them only at the enterprise tier. It's worth pressure-testing these specifically during any evaluation.

Integrations with the rest of your stack

CMS apps don't live in isolation. The relevant integration categories for most marketing and product teams:

Search. If your site has more than a few dozen pages, you'll want full-text search. Most headless CMS apps integrate with Algolia or a similar index service, syncing content automatically when you publish.

Analytics and personalisation. Some CMS apps have first-party analytics add-ons; most rely on you connecting Google Analytics, Segment, or similar via your frontend.

E-commerce. If product content needs to stay in sync with a Shopify or similar catalogue, check whether the CMS has a native connector or whether that sync is a custom build.

Email and marketing automation. Content reuse across CMS and email campaigns is often messier than vendors suggest. The honest answer is: most teams still copy and paste, unless they invest in a deliberate integration.

Deployment triggers. Headless CMS apps typically fire a webhook when content is published, which triggers a rebuild or cache invalidation on the website. This is nearly invisible when it works and very confusing when it doesn't — worth asking any developer you're evaluating how they handle and monitor it.

Choosing the right class of CMS app

The broad categories you'll encounter:

Type	Best for	Watch out for
Traditional (WordPress, Drupal)	Simple sites, tight budgets, familiar editors	Coupling to one frontend, plugin maintenance debt
Hosted headless (Sanity, Contentful, Storyblok)	Multi-channel, design-system-driven sites	Per-seat costs, API call limits at scale
Self-hosted headless (Payload, Strapi)	Teams that want full data control	Infrastructure and security burden on your team
Visual / page-builder (Webflow, Builder.io)	Marketing teams who need layout control	Can create brittle designs outside a design system

The right answer depends on your team's technical capacity, how many channels you publish to, and how much editorial flexibility you actually need versus how much you think you need. Most marketing sites do not require the most sophisticated option. Most fast-growing product companies hit the limits of the simplest option faster than they expect.

When you're ready to evaluate specific tools or talk to a developer about implementation, the content model conversation is the one worth having first.

Tailwind CSS in 2026: what actually changed for teams

Nayan Kyada — Mon, 20 Jul 2026 07:40:09 +0000

Tailwind CSS in 2026 is a fundamentally different tool from the one most teams learned in 2022. The v4 engine, CSS-first configuration, and first-class container queries have each individually reshaped daily workflow — and the combination is worth talking about plainly, separate from any migration checklist.

The CSS-first config is not just syntax sugar

The headline change in v4 is that tailwind.config.js is gone by default. Design tokens live in a @theme block inside your CSS file:

/* app/globals.css */
@import "tailwindcss";

@theme {
  --color-brand: #1d4ed8;
  --font-display: "Inter", sans-serif;
  --spacing-18: 4.5rem;
}

This feels like a small ergonomic shift until you actually live with it on a team. The old tailwind.config.js was a JavaScript file, which means it got imported, extended, and occasionally mutated by plugins in ways that were hard to audit. Designers who opened the repo could not read it comfortably. New engineers would ask whether the config was the source of truth or just one layer on top of a preset.

A CSS file with @theme is unambiguous. It co-locates with the rest of your styles. It gets reviewed in the same diff as component changes. A junior dev on a team I worked with last quarter noticed a color token drift between Figma and production within two days of this setup, something that had been invisible for months under the old config structure.

What teams actually need to watch for: any tooling that statically parses tailwind.config.js — design token exporters, Storybook addons, custom CLI scripts — will break silently. Audit those before the switch, not after.

The Oxide engine changes what the build step costs

V4's Rust-based engine (Oxide) isn't a minor performance improvement. On the largest Next.js project I maintain — roughly 380 components, a design system package, and a monorepo with four apps — full CSS rebuilds dropped from around 800ms to under 80ms. Incremental rebuilds became effectively instant.

For most teams this doesn't change what ships to users, since CSS is built once at deploy time. But it changes the development feedback loop in a real way. Hot reload with Tailwind classes no longer has a perceptible lag. That matters more than it sounds: slow Tailwind rebuilds used to push developers toward inline styles or style attributes to avoid the wait, which undermined the whole point.

Turbopack + Oxide is the pairing worth actually running in 2026. Next.js with next dev --turbopack and v4 Tailwind gives you a dev loop that is competitive with Vite on startup and incremental speed.

Container queries are now a first-class workflow, not a plugin

V3 had container queries behind @tailwindcss/container-queries. V4 ships them in core:

// components/card.tsx
export function Card({ children }: { children: React.ReactNode }) {
  return (
    <div className="@container">
      <div className="grid grid-cols-1 @md:grid-cols-2 @lg:grid-cols-3 gap-4">
        {children}
      </div>
    </div>
  );
}

This changes how component libraries get built. The old pattern was: build a component, expose className props, let the consumer manage layout breakpoints. The new pattern is: build a component that is genuinely self-contained — it knows how to render in a narrow sidebar and a full-width hero without the consumer passing responsive props.

For teams that sell or share component libraries internally, this is a meaningful workflow shift. Components can finally be tested in isolation without needing to fake viewport widths. Storybook stories become more trustworthy because the component reacts to its container, not to the story viewport.

The practical catch: container queries require a named containment context to work correctly in certain nested layouts. @container without a name defaults to the nearest ancestor with containment, which creates subtle bugs when components are composed. Naming containers explicitly (@container/sidebar) is worth making a team convention from day one.

What this means for the design-to-code handoff

The part most opinion posts skip: v4 actually moves Tailwind closer to being a shared language between design and engineering, not just a developer utility.

When your design tokens live in a CSS file rather than a JS object, they can be generated directly from Figma variable exports via a simple script. Several teams I know have wired up a GitHub Action that exports Figma tokens as CSS variables and opens a PR against globals.css. That was theoretically possible with v3 but required a transform step through JavaScript. Now it is a direct write.

The flipside is that CSS-in-JS tooling that reads Tailwind config to build theme context — Stitches-style setups, some Chakra migrations — needs rethinking. If your team has that kind of layering, v4 is a bigger architectural change than the migration guide implies.

The honest team verdict

Tailwind CSS in 2026 is genuinely better for teams that were already using it. The config clarity, build speed, and container query ergonomics are real improvements that reduce friction in practice. It is not meaningfully easier to adopt from scratch than v3 was — the learning curve for the utility-class model is the same.

If your team is on v3 and things are working, the upgrade is worth doing for the build performance alone. If you were already stretching the plugin ecosystem to handle container queries and dynamic theming, v4 removes the scaffolding you were building around the gaps.

The one thing I'd push back on is the idea that CSS-first config is simpler for everyone. If your design system lives in a monorepo and multiple apps need to consume the same tokens, the CSS import model requires discipline around layer ordering and import paths that a shared JS config handled more automatically. Solvable — but you need to design the token-sharing architecture before you migrate, not during.

Sanity video hosting in 2026: Mux vs Cloudinary vs Bunny Stream

Nayan Kyada — Sat, 18 Jul 2026 06:27:38 +0000

Choosing sanity video hosting is not the same decision as choosing Sanity CMS itself. Sanity stores your video asset reference; a separate vendor actually transcodes, stores, and streams the file. In 2026 three vendors come up repeatedly when teams evaluate this: Mux, Cloudinary, and Bunny Stream. They differ sharply on upload UX inside Sanity Studio, adaptive streaming support, how they handle poster images (which directly affects LCP), and — most visibly — cost once you scale past a demo.

What the comparison covers

Each vendor is evaluated on four axes:

Studio upload workflow — does a first-party or community plugin exist, or do you wire a custom input?
Adaptive streaming — HLS/MPEG-DASH with per-resolution renditions, or a single progressive download?
Poster and thumbnail handling — server-generated frame URLs you can feed to next/image for LCP optimisation?
Pricing structure — what the free/starter tier covers and what triggers the first meaningful bill.

I am not going to recommend one unconditionally. The right pick depends on whether you need signed playback, how much you care about Studio editor UX, and whether your traffic is predictable.

Mux

Upload workflow. Mux has the most mature Sanity integration. The sanity-plugin-mux-input package (maintained, currently on v2) adds a drop-in custom input that uploads directly to Mux's upload URL API without routing files through your own server. Editors get a progress bar and a playback preview inside Studio. Schema wiring is around ten lines.

// schemas/video.ts
import { defineField, defineType } from 'sanity'

export default defineType({
  name: 'videoPost',
  type: 'document',
  fields: [
    defineField({
      name: 'video',
      type: 'mux.video', // registered by sanity-plugin-mux-input
      title: 'Video',
    }),
  ],
})

The plugin stores a playbackId and assetId on the document. You query playbackId via GROQ and construct the HLS URL client-side: https://stream.mux.com/{playbackId}.m3u8.

Adaptive streaming. Full HLS with automatic per-title encoding. Mux generates renditions at multiple bitrates per asset; the player selects the right one per viewer. This is the most production-ready adaptive streaming option of the three.

Poster handling. Mux generates thumbnail URLs from any frame: https://image.mux.com/{playbackId}/thumbnail.webp?time=3. That URL is a real image you can pass directly to next/image with priority to hit LCP. Width and height are predictable from your Mux asset metadata.

Pricing. Mux bills on storage ($0.015/GB/month) and delivery ($0.009/min streamed). There is no meaningful free tier for production — the free tier gives you 10 GB storage and 100 minutes of delivery per month, which is a test environment, not a live site. A mid-traffic site streaming 2 000 minutes/month and storing 20 GB hits roughly $25–35/month before any per-seat Sanity cost.

Cloudinary

Upload workflow. Cloudinary has a sanity-plugin-cloudinary package but it sees less active maintenance than the Mux plugin. The pattern stores a Cloudinary public_id on the document. Alternatively you can build a custom input with Cloudinary's upload widget (JavaScript, loaded client-side in the Studio), but that means more glue code. Editors do get an in-Studio upload experience if you wire it correctly; it just requires more setup than Mux.

Adaptive streaming. Cloudinary supports HLS adaptive streaming but it is not on by default. You must request it via transformation parameters (sp_hd/ prefix on the URL or via a named transformation). Out of the box you get a progressive MP4 delivery, which works but does not adapt to bandwidth. For most video-light sites (hero clips, explainers under 3 minutes) this is fine. For long-form it is a real limitation.

Poster handling. Cloudinary's transformation API is strong here. A poster URL looks like:
https://res.cloudinary.com/{cloud}/video/upload/so_3,f_webp,q_auto,w_1280/{public_id}.webp
You get frame extraction at any second (so_ parameter), automatic format negotiation, and quality tuning — all without a separate image CDN. That flexibility is genuinely useful if you also serve images through Cloudinary.

Pricing. Cloudinary uses a credit system. The free tier gives 25 credits/month (roughly 25 GB storage or transformation-weighted equivalent). Video transformations consume credits faster than image transformations. A realistic video-heavy site — 10 videos averaging 200 MB, regular re-transcoding for new formats — can exhaust the free tier quickly. The Plus plan at $89/month is the first meaningful paid tier. If you are already paying for Cloudinary for images, adding video has marginal incremental cost until you exceed your credit ceiling.

Bunny Stream

Upload workflow. There is no official Sanity plugin for Bunny Stream as of mid-2026. You write a custom input or a Sanity action that calls Bunny's REST API to create a video object, retrieve an upload URL, and store the Bunny video GUID on the document. It is maybe 60–80 lines of TypeScript and not difficult, but it is not a packaged install. Editors upload from Studio but the integration is yours to maintain.

Adaptive streaming. Bunny Stream transcodes to HLS with multiple renditions automatically on upload — 240p through 1080p (4K on higher plans). It matches Mux's adaptive streaming quality and is the main reason Bunny is worth considering at all despite the missing plugin.

Poster handling. Bunny generates a thumbnail at https://vz-{zone}.b-cdn.net/{guid}/{frame}.jpg. Frame extraction is available but less flexible than Cloudinary — you select from pre-generated thumbnails or upload a custom one via the API. For LCP purposes it works: you get a stable URL to pass to next/image. You will want to set explicit width and height to avoid CLS.

Pricing. Bunny is substantially cheaper than Mux or Cloudinary for delivery-heavy workloads. Storage costs $0.005–0.01/GB/month depending on region. Delivery (bandwidth) costs $0.005–0.015/GB depending on zone, billed per GB served rather than per minute. For a site streaming 100 GB/month, Bunny runs $0.50–1.50 in delivery vs Mux at roughly $18–22 for the same load (converting minutes to GB at typical bitrates). The trade-off is you are owning more integration code.

Side-by-side summary

	Mux	Cloudinary	Bunny Stream
Sanity Studio plugin	Official, maintained	Community, less active	None — custom input required
Adaptive HLS	Yes, automatic	Optional (transformation param)	Yes, automatic
Poster/thumbnail URL	Yes (`image.mux.com`)	Yes (transformation API)	Yes (pre-generated frames)
Free tier	10 GB / 100 min/month	25 credits/month	1 TB bandwidth trial
Indicative cost at modest scale	$25–40/month	$0–89/month (credit-dependent)	$2–8/month
LCP-friendly poster	Yes	Yes (best transformation control)	Yes (limited frame selection)
Signed/private playback	Yes (signed tokens)	Yes (signed URLs)	Yes (token auth)

Which to pick

If editor experience in Studio is a priority and your client or team expects a polished upload UI without custom code, Mux is the least friction option. The plugin is solid, the HLS delivery is reliable, and the poster URL is a first-class feature. The cost is higher but predictable.

If you are already running Cloudinary for image delivery and your video library is small (under 20 videos, short clips), Cloudinary avoids adding another vendor. The credit model gets expensive fast on large video catalogues, and adaptive streaming needs deliberate setup.

If delivery cost is the deciding constraint — you have high bandwidth, predictable load, and a developer who can write 80 lines of custom integration — Bunny Stream is hard to beat on price. Adaptive HLS works well, thumbnails are usable, and the bandwidth cost at scale is genuinely lower than Mux by a factor of 10 or more on some workloads.

None of these vendors is wrong. The Mux-specific tutorials elsewhere on this site (signed HLS, upload and playback) remain valid if you pick Mux. But picking Mux as a default without evaluating Bunny's cost curve is a decision worth making explicitly, especially on projects where video volume is high and editor-facing upload UX is a secondary concern.

Sanity vs WordPress cost: annual TCO once you're already live

Nayan Kyada — Fri, 17 Jul 2026 06:35:01 +0000

The migration debate is settled elsewhere. This post is about what you actually spend every year once the site is built and handed over — Sanity + Next.js on one side, a self-hosted WordPress on the other. Both stacks running in production, both with real editors, both needing to stay secure and fast.

What counts as steady-state cost

I'm counting four buckets: hosting infrastructure, third-party licenses (plugins, themes, SaaS add-ons), the developer time consumed by maintenance and security patching, and the hidden cost of editor inefficiency — the hours content teams lose to a slow, brittle CMS UI. I'm not counting one-time migration work or design fees; the switch-over economics are covered separately in WordPress to Sanity migration cost: does it pay back?

All figures below are 2026 market rates, USD, for a mid-size content site: 20–50k monthly sessions, one Sanity project or one WordPress install, two to five editors.

Hosting

WordPress almost always runs on a managed WordPress host. WP Engine Startup is $30/month ($360/year). If you grow past 25k visits/month or need staging + production parity, you're on Growth at $77/month ($924/year). Add Cloudflare Pro ($240/year) if you want proper CDN and DDoS mitigation without relying on the host's bundled CDN, which is rate-limited at the cheaper tiers. Realistic annual hosting: $600–$1,200.

Sanity + Next.js splits into two bills. Sanity's Growth plan is $15/month per project ($180/year) — that covers 100k API CDN requests per month, 20 GB bandwidth, three non-admin users, and 10k documents. Most small-to-mid content sites fit here indefinitely; the free tier covers solo developers. Next.js on Vercel Pro is $20/month per seat for the first developer, then $20/month per additional member; for a two-developer team that's $480/year. Alternatively, a $20/month Fly.io VM or a $24/month Render instance covers the Next.js runtime if you prefer not to be on Vercel. Realistic annual hosting: $660–$840 (Vercel Pro + Sanity Growth, two devs). You can go lower on Vercel Hobby for personal projects, but production sites with preview URLs and team access need Pro.

Plugin and license costs

This is where WordPress stacks up fast. A production WordPress site in 2026 typically carries:

Advanced Custom Fields Pro: $49/year
WP Rocket or similar caching plugin: $69/year
Yoast SEO Premium or Rank Math Pro: $99–$129/year
Gravity Forms or WPForms Pro: $99–$259/year
A premium theme or Elementor Pro: $59–$199/year
WP Offload Media (S3/CloudFront): $99/year
Wordfence Premium or Sucuri: $119–$299/year
BackupBuddy or similar: $99/year

Conservative total for a real production site: $800–$1,400/year in plugin licenses alone. I've audited WordPress installs for clients that topped $2,000/year in renewals across 15+ plugins, several of which were redundant.

Sanity + Next.js has near-zero third-party license spend at this scale. next/image handles image optimisation natively. Sanity's built-in SEO fields replace Yoast. Form handling goes through a route handler to SendGrid ($19.95/month on Essentials if volume is low, often free for simple contact forms). There's no caching plugin — Next.js ISR and Vercel's edge network handle that. No security plugin — the attack surface doesn't exist. Realistic annual licenses: $0–$240 (SendGrid or similar, optional).

Maintenance and security-patching time

This is the cost most spreadsheets miss. WordPress core releases major versions roughly three times per year; plugins release updates constantly. A disciplined team tests updates in staging before pushing to production. That cycle — pull update, smoke-test, push, verify — runs about 1.5–2 hours per month for a site with 10–20 active plugins. At a conservative $80/hour developer rate, that's $1,440–$1,920/year in pure maintenance time.

WordPress is also the most-targeted CMS on the internet. Plugin vulnerabilities (ACF, WooCommerce, Elementor, caching plugins) surface regularly. When a critical CVE drops, patching is not optional and not always scheduled. Budget one emergency patch cycle per year: 3–4 hours including rollback testing. That's another $240–$320.

Sanity + Next.js maintenance time is different in shape. Sanity's API is versioned and backward-compatible; you opt into API version bumps explicitly. The Studio is a React app you update when you choose to. Next.js releases are more frequent but the App Router surface is stable. Realistic maintenance cycle: 45–60 minutes per month, mostly npm audit and dependency bumps, with no urgent plugin-level CVE exposure. Annual developer time cost: $720–$960.

Editor efficiency

This one is qualitative but real. Slow editor UX has a measurable cost in time. WordPress's block editor (Gutenberg) confuses non-technical editors — I consistently see clients spend 20–30 minutes per post wrestling with block nesting, reusable block management, or broken custom field layouts. At two editors publishing twice a week, 20 wasted minutes per session adds up to roughly 138 hours/year. If those editors are marketing hires at $35/hour, that's ~$4,800/year in lost productivity.

Sanity Studio with a well-structured schema is faster for editors. Portable Text keeps formatting decisions minimal. Structured fields mean editors fill in slots rather than compose layouts. The same two-editors-twice-a-week workload typically runs 5–8 minutes of friction per session in my experience — closer to $1,200–$2,000/year in editor time.

Annual cost comparison

Cost bucket	WordPress (annual)	Sanity + Next.js (annual)
Hosting	$600–$1,200	$660–$840
Plugin / license fees	$800–$1,400	$0–$240
Dev maintenance time	$1,680–$2,240	$720–$960
Editor inefficiency	~$4,800	~$1,600
Total	$7,880–$9,640	$2,980–$3,640

The hosting line is roughly equivalent — WordPress wins slightly at the low end, Sanity + Vercel wins slightly at the high end. Every other line favours Sanity + Next.js, and the gap widens as the team grows.

Where WordPress still wins on running cost

Shared hosting at $10/month plus free plugins is a real option for a solo operator with no developer on retainer and no budget for Vercel Pro. If you're running a personal site, doing your own updates, and your "editor" is yourself, WordPress's all-in cost can be $400–$600/year. Sanity + Next.js at that scale with a Hobby Vercel account and Sanity's free tier is similar — but the setup requires more upfront developer skill to self-maintain.

WordPress's plugin ecosystem also covers niche requirements (LMS, WooCommerce, membership sites) that would require custom development in a Next.js stack. If your requirements fit a plugin, using it is cheaper than building.

The number that changes the decision

Editor time is the swing factor for most clients. Founders often undercount it because it shows up as salaries, not invoices. Once you model it honestly, the $5,000–$6,000 annual gap between the two stacks becomes hard to ignore for any team publishing more than a handful of posts per month.

If the numbers point toward switching, the technical migration walkthrough shows what the work actually involves, and signs your WordPress site needs a headless rebuild helps you sanity-check whether you're there yet.

Sanity image-url hotspot not working: four causes and fixes

Nayan Kyada — Thu, 16 Jul 2026 06:40:14 +0000

Sanity's hotspot and crop system works well when all the pieces line up — but if your rendered image is ignoring the focal point you set in Studio, one of four things is almost certainly wrong. None of them are subtle bugs; they're all configuration mistakes that are easy to miss and easy to fix.

The four causes (and their fixes)

1. `fit` is still set to `clip` instead of `crop`

This is the most common cause. The @sanity/image-url builder defaults to fit('clip'), which scales the image to fit inside the requested dimensions without cropping anything. Hotspot data is only applied when the builder is told to crop — that is, when it cuts the image down to the requested dimensions, centering the cut on the focal point.

Fix: always chain .fit('crop') when you pass .width() and .height().

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

const builder = imageUrlBuilder(client)

export function urlFor(source: SanityImageSource) {
  return builder.image(source)
}

// Usage — hotspot will only apply if fit is 'crop'
const url = urlFor(image)
  .width(800)
  .height(600)
  .fit('crop')   // <-- required for hotspot to do anything
  .auto('format')
  .url()

Without .fit('crop'), Sanity's CDN receives no crop instruction and the hotspot coordinates are silently ignored.

2. Missing `options: { hotspot: true }` on the schema field

If the image field in your Sanity schema is not configured with hotspot support, Studio never renders the focal point UI, and the hotspot and crop keys are never written to the document in the first place. The URL builder can't use data that isn't there.

Fix: add options: { hotspot: true } to every image field where editors need focal control.

// schemas/post.ts
export default {
  name: 'post',
  type: 'document',
  fields: [
    {
      name: 'coverImage',
      type: 'image',
      options: {
        hotspot: true, // <-- enables the focal point UI in Studio
      },
    },
  ],
}

After adding this, existing documents will still have no hotspot data — editors need to open each document and set the focal point manually, then republish.

3. Passing only `asset._ref` to the URL builder instead of the full image object

This one is common when developers destructure a GROQ projection too aggressively. The URL builder needs the full image object — asset, crop, and hotspot — to apply the focal point. If you pass only the reference string or only { asset }, the builder has no crop/hotspot coordinates to work with.

// ❌ Wrong — only the reference, crop and hotspot are lost
"coverImage": coverImage.asset._ref

// ✅ Correct — project the full image object
"coverImage": coverImage {
  asset,
  crop,
  hotspot
}

In your component, pass the full object:

// src/components/CoverImage.tsx
import { urlFor } from '@/lib/sanity-image'
import type { SanityImageObject } from '@sanity/image-url/lib/types/types'

interface Props {
  image: SanityImageObject // asset + crop + hotspot
}

export function CoverImage({ image }: Props) {
  const src = urlFor(image)
    .width(1200)
    .height(630)
    .fit('crop')
    .auto('format')
    .url()

  return <img src={src} alt="" width={1200} height={630} />
}

If you use Sanity TypeGen, the inferred type for a projected image field with crop and hotspot will match SanityImageObject automatically — a good reason to keep TypeGen up to date.

4. Hotspot values outside the `0–1` range from a bad data import

Sanity stores hotspot as { x, y, width, height } where every value is a float between 0 and 1 (fraction of the image dimensions). If you migrated content from another system or ran a custom import script, it's possible the hotspot data was written with pixel values instead of fractional values — for example { x: 320, y: 240, width: 640, height: 480 } on a 1280×960 image instead of the correct { x: 0.25, y: 0.25, width: 0.5, height: 0.5 }.

Pixel-valued coordinates don't cause a runtime error; the CDN just receives coordinates it can't map sensibly, so the crop lands in a wrong or extreme position.

How to verify: open the raw document in Sanity Studio (three-dot menu → Inspect, or sanity documents get <id> via the CLI) and check the hotspot values. If any of x, y, width, or height are greater than 1, the import was wrong.

Fix: write a migration script using @sanity/client to normalise the values.

// scripts/fix-hotspot-values.ts
import { createClient } from '@sanity/client'

const client = createClient({
  projectId: process.env.SANITY_PROJECT_ID!,
  dataset: process.env.SANITY_DATASET!,
  token: process.env.SANITY_WRITE_TOKEN!,
  apiVersion: '2024-01-01',
  useCdn: false,
})

const IMAGE_WIDTH = 1280
const IMAGE_HEIGHT = 960

const docs = await client.fetch(
  `*[_type == 'post' && defined(coverImage.hotspot)]{ _id, coverImage }`
)

for (const doc of docs) {
  const h = doc.coverImage.hotspot
  // Only patch if values look like pixels (> 1)
  if (h.x > 1 || h.y > 1) {
    await client
      .patch(doc._id)
      .set({
        'coverImage.hotspot': {
          x: h.x / IMAGE_WIDTH,
          y: h.y / IMAGE_HEIGHT,
          width: h.width / IMAGE_WIDTH,
          height: h.height / IMAGE_HEIGHT,
        },
      })
      .commit()
    console.log(`Patched ${doc._id}`)
  }
}

Run this against your staging dataset first. Verify a few documents in Studio before running on production.

How to confirm hotspot is working

The fastest sanity check: open browser DevTools, copy the generated image URL, and append &debug=true — Sanity's CDN won't recognise that param, but you can manually inspect the URL for the crop query string parameter. A working hotspot URL will contain something like crop=0.1,0.05,0.1,0.05 (left, top, right, bottom fractions). If crop is absent, the builder didn't receive crop/hotspot data or fit wasn't set to crop.

You can also pass the image object through the builder and log .options to confirm the builder has received all three keys before generating the URL:

const img = urlFor(image).width(800).height(600).fit('crop')
console.log((img as any).options) // { source: { asset, crop, hotspot }, width, height, fit }

All four of the causes above produce identical symptoms — a hotspot that looks set in Studio but has no effect on the rendered image. Work through them in order: fit setting first (takes ten seconds to check), schema options second, GROQ projection third, and data integrity last.

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

Nayan Kyada — Wed, 15 Jul 2026 06:34:59 +0000

Sanity vs Directus is a comparison that comes up more than you'd expect on technical forums in 2026, usually from teams who already have a Postgres database running and are wondering why they'd pay for a separate content lake when Directus can wrap what they have. It's a fair question. These two tools solve adjacent problems but from genuinely different starting points, and the right choice depends heavily on whether your content is primarily relational data or editorial content.

What each tool actually is

Sanity is a hosted content platform. Your content lives in Sanity's managed "content lake" — a document store with real-time collaboration, a CDN-backed asset pipeline, and GROQ as the query language. You define schemas in code, deploy a customisable Studio, and talk to Sanity's API from your Next.js app. You do not manage infrastructure.

Directus is an open-source data platform that wraps any existing SQL database — Postgres, MySQL, SQLite, MS SQL — and exposes it through a REST API, a GraphQL endpoint, and a web-based admin UI. Schema changes happen in the admin UI (or via migrations), and your data stays in your own database. You can self-host entirely or use Directus Cloud.

That distinction — hosted content lake vs database-wrapper — drives nearly every practical difference between them.

Data ownership and where your content lives

With Sanity, your content lives in Sanity's infrastructure. You can export it via the export API, but you are operationally dependent on Sanity's uptime and their CDN. For most product teams that's fine — Sanity has been reliable and their SLA on Growth/Enterprise tiers is solid. But if you're in a regulated industry, have strict data residency requirements, or your client contract requires them to own the database, it's a real constraint.

With Directus, the database is yours from day one. You point Directus at a Postgres instance on your own infrastructure (or a managed one like Supabase, Neon, or Railway), and Directus adds the API and admin layer on top. If you decide to stop using Directus tomorrow, your data is still in a plain relational schema you can query directly. That data portability is genuinely valuable for agencies building client sites where the client insists on owning the infrastructure.

Schema approach

Sanity schemas are defined in TypeScript files that live in your repo. You version them with Git, review them in PRs, and deploy schema changes by pushing code. The document model is flexible — nested objects, arrays of polymorphic blocks, references between documents — and Sanity TypeGen can generate TypeScript types directly from your schemas so GROQ queries are typed end-to-end.

Directus takes the opposite approach: schema changes are made through the admin UI or via a JSON schema snapshot that Directus can migrate. The underlying tables change when you add a field. That's intuitive for developers who think in relational terms, but it means schema changes can be a bit more ceremonial — you need to run migrations rather than deploy a code change. Directus does have a "Schema Migration" CLI workflow that makes this repeatable, but it's a different mental model.

If your team is comfortable with TypeScript-first schema design and wants schema-as-code, Sanity fits naturally into a Next.js monorepo. If your team thinks in tables and foreign keys and already has a Postgres schema they've built over years, Directus makes more sense.

GROQ vs REST/GraphQL

Sanity's query language GROQ is purpose-built for document graphs. You can project exactly the fields you want, traverse references, filter arrays, and coalesce fallbacks in a single query. In a Next.js RSC context, a single GROQ query can pull a page document, its author reference, related posts, and a filtered array of blocks — no N+1 fetching.

// Fetch a page with resolved references and filtered blocks
*[_type == "page" && slug.current == $slug][0] {
  title,
  "author": author-> { name, image },
  blocks[_type != "hiddenBlock"] {
    _type,
    ...
  }
}

Directus gives you REST and GraphQL. The REST API supports filtering, sorting, and field selection via query parameters, and GraphQL gives you typed queries with nested relations. Both are well-documented and widely understood. If your team already knows GraphQL, the Directus API will feel immediately familiar.

The honest comparison: GROQ handles document-graph traversal with less ceremony once you know it, but it's a proprietary language with a learning curve. GraphQL is transferable knowledge. For a pure content site, GROQ wins on conciseness. For a data-heavy application with complex relational joins, Directus's GraphQL layer is more at home.

// app/lib/directus.ts — fetching a page from Directus in Next.js
import { createDirectus, rest, readItems } from '@directus/sdk';

const directus = createDirectus('https://your-directus.example.com').with(rest());

export async function getPage(slug: string) {
  return directus.request(
    readItems('pages', {
      filter: { slug: { _eq: slug } },
      fields: ['title', 'blocks', { author: ['name', 'avatar'] }],
      limit: 1,
    })
  );
}

Editor UX

Sanity Studio is a React application you customise in code. The Portable Text editor is excellent for long-form content, and the presentation preview tool (where editors see their changes reflected in the live Next.js page in real time) is genuinely impressive. The trade-off is that meaningful customisation — custom input components, document actions, structure grouping — requires a developer.

Directus's admin UI is a polished, general-purpose data management tool. Editors can create and manage content without any developer involvement for field-level changes, and the interface is approachable for non-technical users. It feels more like a spreadsheet/form tool than an editorial environment. For long-form content with rich text and embedded blocks, it's less capable than Portable Text.

Self-hosting

Dimension	Sanity	Directus
Hosting model	Hosted SaaS (default); no self-host option	Self-host on any Docker/Node infra, or Directus Cloud
Database ownership	Sanity's content lake	Your own SQL database
Schema definition	TypeScript in repo	Admin UI + JSON snapshots
Query language	GROQ (proprietary)	REST + GraphQL
Real-time collaboration	Yes (built-in)	Limited (no built-in live cursors)
Pricing floor (2026)	Free up to 2 users / 10k docs	Free self-hosted; Cloud from ~$15/month
Rich text editor	Portable Text (excellent)	WYSIWYG (adequate)
Next.js DX	First-class (typed GROQ, live preview)	Good (typed SDK, REST/GraphQL)

Directus self-hosting is a legitimate option and not particularly hard to run — a single Docker Compose file with Directus and a Postgres container gets you a working instance in under 30 minutes. For agencies deploying client sites where the client wants to own the stack, that matters.

Sanity has no self-host path. If that's a hard requirement, Sanity is out.

Which one to choose for a Next.js project

Choose Sanity if: your project is primarily editorial content (marketing pages, blog, documentation, product catalogue), your team is comfortable with TypeScript-first tooling, and you want real-time collaborative editing with a polished Studio. The Sanity + Next.js integration is the tightest in the market right now — typed queries, live preview, image pipeline, PPR-friendly revalidation.

Choose Directus if: you have an existing relational database you need to expose through a CMS-style interface, your client requires full data ownership, your content is more "structured records" than "editorial pages", or you need the flexibility of GraphQL over a proprietary query language.

The honest answer for most greenfield Next.js content sites in 2026: Sanity's developer experience is ahead. But Directus is not a lesser tool — it's a different tool solving a different problem, and for data-centric applications or infrastructure-owned deployments, it's often the better fit.

Contentful pricing 2026: free tier limits, the $300 cliff, and Enterprise

Nayan Kyada — Tue, 14 Jul 2026 07:21:29 +0000

Contentful pricing in 2026 has one problem that keeps coming up in forums and Slack groups: there is almost no middle ground between the free Community tier and a $300/month commitment. If you are scoping a project and trying to decide whether Contentful fits your budget — or comparing it against Sanity, Payload, or another CMS — this post gives you the actual numbers, what triggers each tier, and what enterprise pricing looks like in practice.

What the Community free tier actually includes

Contentful's Community plan is genuinely useful for small projects, but its limits are specific and worth knowing before you build against them.

Records: 25,000 records per space. A "record" in Contentful counts each published entry and each asset. A mid-size marketing site with 200 blog posts, product pages, team bios, and associated images can eat through 3,000–5,000 records faster than teams expect, especially once you factor in localised variants and component-level entries.

Locales: 2 locales per space. For a bilingual site this is fine. For anything requiring three or more languages — a common requirement for European SaaS companies — you are already past the free tier before you write a single line of code.

Users: 5 users in the Contentful web app. Fine for a freelance project, tight for an agency handing off to a client team.

Environments: 2 environments (master + 1). You cannot have a staging, preview, and production environment under the free plan. Most serious Next.js projects need at least three.

Bandwidth and API calls: The Community plan allows 500,000 API calls per month across Content Delivery API, Content Preview API, and Images API combined. A busy site using ISR with short revalidation windows can breach this.

Rich text and content types: Up to 48 content types per space. This sounds like a lot until you start modelling component-level entries — hero blocks, feature grids, testimonials, modals — each of which typically gets its own content type.

The $300 jump: Contentful Basic

This is the pricing cliff that generates most of the search frustration. There is no $49/month or $99/month tier sitting between Community and Basic. Contentful's Basic plan starts at approximately $300 per month (billed annually; month-to-month is higher). In 2026, that figure has not moved meaningfully.

What does $300 unlock?

Records: 500,000 (20× increase)
Locales: 5 per space
Users: 25
Environments: 3 (still limited — some teams need more)
Roles: Basic plan adds custom roles with limited permission granularity
API call quota: Increased, though Contentful does not publish an exact ceiling for Basic

For a small team shipping a single marketing site, that jump is hard to justify. $300/month is $3,600/year — a cost that rivals full Vercel Pro plans plus a Sanity Growth subscription combined. The problem is not that Basic is overpriced for what it delivers; it is that there is nothing between zero and three hundred.

Teams that hit the 25,000-record ceiling or the 2-locale wall mid-project have two options: upgrade immediately or restructure their data model to delay the upgrade. Neither is a comfortable conversation to have with a client.

Contentful pricing table: 2026

Plan	Monthly cost (annual)	Records	Locales	Users	Environments
Community	Free	25,000	2	5	2
Basic	~$300	500,000	5	25	3
Enterprise	Custom quote	Custom	Custom	Unlimited	Custom

Contentful does not publish a Pro or mid-tier plan in 2026. The table above reflects what is publicly available. Enterprise pricing is negotiated and typically involves a minimum annual commitment — figures in the $2,000–$5,000+/month range appear consistently in community discussions, though Contentful does not confirm public pricing for that tier.

Enterprise: what you can expect

Contentful Enterprise is a custom contract. What that actually means in practice:

You will not get a number without a sales call. Enterprise customers typically get dedicated infrastructure options, SLA guarantees (99.99% uptime), single sign-on (SSO/SAML), audit logs, and more granular RBAC. Contentful's App Framework and Compose + Launch add-ons are generally available at Enterprise tier or as paid additions.

Minimum commitment: Anecdotally, teams report annual contracts starting around $24,000/year ($2,000/month) for smaller Enterprise agreements. Complex organisations with multiple spaces, high API volumes, and support requirements are quoted significantly higher.

Spaces and environments: Enterprise gives you negotiated limits on spaces and environments — this matters if you run multiple brands or clients through one Contentful organisation.

Contentful Studio: Contentful's visual editor tooling is bundled into higher Enterprise tiers. If that is a requirement, factor it into negotiations because it is not available on Basic.

The comparison question: Contentful vs Sanity at the same budget

The search query "Sanity vs Contentful enterprise pricing" has no page that actually answers it with numbers, so here is a direct comparison at the $300/month mark.

At $300/month, Sanity's Growth plan gives you 250,000 documents, 3 datasets (equivalent to environments), up to 20 users in Sanity Studio, and no hard API call limits — overage is charged per-use rather than gated. Sanity also has a $0 free tier with 10GB bandwidth and 2 datasets, and a ramp from free to Growth at $15/month before you hit the Growth flat rate. That graduated pricing is what Contentful does not offer.

Payload CMS, which is self-hosted, has a different cost structure entirely: you pay infrastructure (a $20–50/month VPS handles most projects) rather than a SaaS tier. The trade-off is maintenance overhead.

What actually triggers the upgrade

In practice, the things that push a Contentful project from Community to Basic are:

Third locale added. Two locales is fine until it is not. Adding German, French, Japanese, or any third language trips the limit immediately.
Component-level modelling. Agencies that build flexible page builders in Contentful — where each section is a linked entry — accumulate records faster than teams using a flat schema.
Multiple environments needed for staging. A Next.js team using Contentful draft mode for Preview needs a preview environment separate from production. Two environments is not enough.
Client team size exceeds five. Marketing teams with more than five editors are common.

None of these triggers are unusual. They are normal requirements for a professional project. That is the real frustration: the Community plan is sized for hobby projects, and the Basic plan is sized for teams with real budget. There is nothing for the team in between.

Is the $300 justified?

For organisations with genuine scale — 10+ editors, multiple locales, high content velocity — Contentful Basic and Enterprise deliver a mature, stable platform with strong tooling, an established app marketplace, and a track record. The pricing is hard to argue with at that scale.

For teams scoping a new site and trying to stay under $500/month total infrastructure cost, the jump from $0 to $300 with no intermediate option is a real planning problem. That is the constraint to design around, not the one to discover mid-engagement.

Payload CMS pricing 2026: the real infrastructure cost breakdown

Nayan Kyada — Mon, 13 Jul 2026 07:47:34 +0000

Payload CMS pricing in 2026 is a trick question. The software itself is MIT-licensed — you download it, run it, own it, never pay a license fee. What you actually pay for is the infrastructure you run it on: a server or serverless platform, a database, and somewhere to store uploaded files. This post breaks that down by project size with real numbers from Railway, Fly.io, Vercel, Neon, and AWS S3.

What Payload CMS actually costs (spoiler: $0 for the software)

There is no Payload Cloud as of mid-2026. Payload 3.x ships as a Next.js plugin, so your CMS and your front-end live in the same codebase and deploy to the same host. That's architecturally elegant, but it also means you're responsible for every layer of the stack. Unlike Strapi Cloud or Sanity's hosted backend, there is no first-party managed platform you can point a credit card at and call done.

The five cost buckets to plan for:

Compute — where the Next.js + Payload app runs
Database — Postgres (recommended for Payload 3.x) or MongoDB
File storage — uploaded media, since the local disk on a serverless host is ephemeral
Bandwidth / CDN — egress for media delivery
Email — transactional email for Payload's auth flows (optional but usually needed)

Hosting options compared

Vercel is the natural choice for a Next.js project. Payload 3.x runs inside Next.js route handlers, so it deploys without any special config. The Pro plan ($20/month per member) is practically mandatory once you have more than one developer or need preview deployments — the free tier's 100 GB-hours of serverless function execution runs out faster than you'd expect when Payload's API routes are warm. Edge function restrictions mean your Payload API must live in Node.js runtime, not Edge; keep that in mind.

Railway is the most straightforward option if you want a persistent Node.js process rather than serverless. A small always-on service runs around $5–15/month depending on RAM. Railway also offers managed Postgres, which simplifies the stack. The developer plan is $5/seat but you're usually paying per-resource, not per-seat.

Fly.io is worth considering for teams who want full control. A shared-CPU-1x VM with 256 MB RAM is effectively free under the free allowance; a machine with 1 shared CPU and 1 GB RAM costs roughly $5–7/month. You'd run Postgres as a separate Fly app or use Neon.

Render sits between Railway and Fly — persistent services start at $7/month, managed Postgres at $7/month for the smallest tier.

Database costs

Payload 3.x defaults to Postgres. For most projects:

Neon (serverless Postgres) has a generous free tier (0.5 GB storage, 10 branches) that covers a staging environment or a small production site. The Launch plan is $19/month and includes 10 GB storage — this is where most small production sites land.
Railway Postgres is $0.000231/MB-hour (~$5–8/month for a typical 2–5 GB database).
Supabase free tier is 500 MB; Pro is $25/month. Reasonable alternative if you want the dashboard.
MongoDB Atlas still works with Payload 3.x but is no longer the recommended adapter. Free M0 cluster is 512 MB; M10 (the first paid, non-shared cluster) jumps to ~$57/month — a significant step up.

For most Payload projects in 2026, Neon Launch ($19/month) or Railway Postgres (~$7/month) is the right call.

File storage

Payload's local disk storage is not usable on Vercel (ephemeral filesystem) and unreliable on most containerised hosts after deploys. You need an external storage adapter:

AWS S3 is the default recommendation. A typical editorial site with 50 GB of images and video thumbnails costs $1.15/month in storage plus $4.50/100 GB egress. For low-traffic sites the total is under $5/month.
Cloudflare R2 has zero egress fees. Storage is $0.015/GB/month. For media-heavy sites this is meaningfully cheaper than S3 — 100 GB of assets costs $1.50/month, full stop.
Uploadthing bundles storage and delivery with a simpler API. Free tier is 2 GB; the $10/month plan is 50 GB. Worth considering for small agencies that don't want to manage bucket policies.

Cost table by project size

Project size	Compute	Database	Storage	Monthly total
Hobby / staging	Fly.io free allowance or Railway $5	Neon free	S3 ~$1	$6–$10
Small production (< 10k visits/month)	Vercel Pro $20 or Railway $10	Neon Launch $19	R2 $2	$35–$45
Medium (10k–100k visits/month)	Vercel Pro $20 + usage or Fly 2× $14	Neon Launch $19	R2 $5–10	$45–$65
Agency multi-tenant (multiple clients)	Dedicated VM $40–80	Neon Scale $69 or self-hosted PG	R2 $15–30	$120–$180
High-traffic / enterprise	Fly.io performance or AWS ECS $100–200+	RDS Postgres $100+	S3 + CloudFront $30+	$230+

These are infrastructure-only numbers. Add Vercel team seats ($20/member/month) if you're on Vercel Pro, and any third-party services like SendGrid ($15/month starter) or Resend ($20/month for 50k emails).

What actually triggers a cost increase

Serverless cold starts on Vercel can push you into higher function execution tiers if your Payload API routes aren't cached intelligently. Profile your route handler usage before assuming the free tier is sufficient.

Media volume is the most unpredictable line item. A client who uploads 4K source images without size limits will blow through an S3 budget. Set maxFileSize in your Payload upload config and enforce image optimisation at the adapter level.

Database connection limits on Neon's free tier (max 10 connections) become a problem the moment you add a staging environment, a preview branch, and a local dev machine all hitting the same database. The Launch plan ($19/month) raises this to 100 connections — worth it.

Postgres vs MongoDB on cost: if you're starting fresh in 2026, use Postgres. MongoDB Atlas's lowest non-shared tier ($57/month) is hard to justify when Neon gives you a production-grade Postgres instance for $19.

Realistic monthly totals

For a freelance or agency project with one client site, a realistic 2026 Payload CMS infrastructure budget is:

Bare minimum (hobby/staging): $6–10/month
Small business production site: $40–50/month
Content-heavy or multi-environment: $80–120/month

Compared to a managed headless CMS: Sanity's Growth plan is $15/month; Contentful's Basic is $300/month. Payload's infrastructure floor is competitive — but you're owning ops, updates, and backups yourself. That's a real cost even if it doesn't show up on a hosting invoice.

Strapi pricing 2026: Community edition, Cloud tiers and real infra costs

Nayan Kyada — Sun, 12 Jul 2026 07:06:22 +0000

Strapi pricing in 2026 splits into two fundamentally different models: a free, self-hosted Community edition and a managed Strapi Cloud with three paid tiers. Understanding which path you're actually on — and what your real monthly spend looks like — requires looking past the marketing page and into the infra bill, the feature gates, and the support thresholds.

The Community edition: free but not zero cost

Strapi's Community edition is MIT-licensed and genuinely free. You get the full content-type builder, REST and GraphQL APIs, role-based access control, plugin ecosystem, and unlimited API calls. There is no usage metering, no seat tax, no document limit.

What you pay is the infrastructure layer:

VPS (2 vCPU, 2–4 GB RAM): $6–12/mo on Hetzner, $12–24/mo on DigitalOcean or Render.
Managed Postgres: $7–15/mo (Supabase free tier works up to ~500 MB, then $25/mo; Neon free tier is more generous but production-grade means a paid plan).
Object storage for uploads: $0–5/mo on Cloudflare R2 or Backblaze B2 for under 50 GB.
Total realistic floor: $10–25/mo for a single-environment production setup.

For a staging + production pair, double the VPS line. Add a CI/CD runner if you're deploying via GitHub Actions to a private server — that's usually free on the GitHub free tier within minutes limits.

The hidden cost of self-hosting is time: Strapi updates regularly, and major versions (v4 → v5 happened in late 2024) require migration work. Budget 2–4 hours per minor upgrade cycle if you're running a customised instance.

Strapi Cloud tiers in 2026

Strapi Cloud is the managed hosting option. It handles deployment, Postgres, file storage, SSL, and rolling updates. The trade-off is a fixed monthly cost and less control over the underlying stack.

Plan	Monthly price (billed annually)	Projects	Seats	Uploads storage	Support
Developer	$29	1	3	25 GB	Community
Pro	$99	3	5	100 GB	Email (48 h)
Team	$299	10	10	200 GB	Priority email
Custom / Enterprise	Negotiated	Unlimited	Unlimited	Custom	SLA + CSM

Prices above are per-organisation, billed annually. Monthly billing adds roughly 20%. A Pro plan billed monthly runs ~$119/mo.

A few line items that don't show on the marketing page until you hit them:

Overages on storage are charged at $0.25/GB/mo above the plan limit.
Custom domains are available from the Developer tier upward — no extra charge, but you manage DNS.
Environments (preview, staging, production) count as separate projects against your project quota. A Pro plan covers 3 projects total, so staging + production for two sites fills it.
Database backups are included on Pro and above; Developer tier has manual snapshots only.

What actually triggers a move to Strapi Cloud

Most developers start on self-hosted Community. Three situations consistently push teams toward Cloud:

1. DevOps bandwidth runs out. When the person who configured the VPS leaves, or when a security patch drops and nobody wants to own the 11 pm deployment window, a $99/mo Pro plan looks cheap relative to incident cost.

2. Client handoff requires a supported URL. Agencies delivering to non-technical clients need a stable admin URL, SSL that renews itself, and someone other than the developer to call when Strapi goes down. Cloud satisfies all three without a custom ops setup.

3. The project adds a second environment. Adding staging to a self-hosted setup means a second VPS, second Postgres instance, a deploy script, and environment variable management. On Cloud, it's a second project slot — already included on Pro.

The move away from Cloud happens too, usually when an organisation hits the Team tier ($299/mo) and realises their traffic pattern doesn't justify it. At that point, a dedicated $40/mo VPS with managed Postgres at $25/mo ($65/mo total) looks better, especially if they have a developer who'll own the ops.

Strapi Cloud vs self-hosted: total cost comparison

For a single-project, 3-editor content team running one environment:

Self-hosted Community: $10–25/mo in infra, zero licence. Suits teams with a developer who will own the server.
Strapi Cloud Developer: $29/mo all-in. Suits solo freelancers or small teams who want zero ops overhead.
Strapi Cloud Pro: $99/mo. Suited to agencies managing 2–3 client sites where client uptime expectations are contractual.

For a two-environment (staging + prod) setup with 5 editors, Pro is usually the correct Cloud tier, and self-hosted remains competitive at $20–40/mo if you're disciplined about maintenance.

Decision guide by team size

Solo freelancer or side project: Self-hosted Community on a $6 Hetzner VPS. The Developer Cloud tier at $29/mo is a reasonable upgrade if you want zero maintenance. Skip Cloud Pro — the project slots and email support aren't worth it at this scale.

Startup (2–8 person team, one product): Self-hosted is viable if a technical co-founder owns the server. Cloud Pro at $99/mo is worth it when the team lacks server confidence or when staging environment friction slows down marketing. The break-even against self-hosted ($20–40/mo) is roughly two developer-hours of avoided ops work per month.

Agency (3–15 client sites): Cloud Pro covers 3 projects — not enough for most active agency workloads without reusing project slots. Cloud Team at $299/mo covers 10 projects and makes sense if you're billing infrastructure management as part of a retainer. Alternatively: self-host a multi-tenant Strapi instance (one codebase, multiple content roots via environments) — complex to set up, cheaper at scale.

Enterprise (compliance, SLA): Negotiate Custom/Enterprise directly. Strapi's enterprise agreement includes SSO, audit logs, a dedicated CSM, and an uptime SLA. This is where the Community edition's MIT licence matters: if you need Strapi on-premise behind a corporate firewall, you can do it. No other managed-CMS player gives you that option at the same price point.

The Strapi v5 migration cost

If you're on a legacy Strapi v4 instance evaluating a move to v5 (the current major version as of mid-2026), factor in migration effort: content-type schema changes, plugin compatibility audits, and API response format differences. For a moderately customised v4 instance, budget 8–20 hours of developer time. This cost applies regardless of whether you move to Cloud or stay self-hosted.

Sanity vs Hygraph 2026: an honest side-by-side for Next.js teams

Nayan Kyada — Sat, 11 Jul 2026 06:32:51 +0000

Sanity vs Hygraph is one of the cleaner matchups in headless CMS right now because the two products make genuinely different bets. Sanity bets on a content lake with a flexible query language and a programmable studio. Hygraph (formerly GraphCMS) bets on GraphQL as the native interface and content federation across external APIs. Neither is a poor choice for Next.js — but they suit different project shapes, and picking the wrong one costs real time.

This post runs through the areas that matter most in practice: data model and querying, editor UX, Next.js integration, pricing, and where each tool breaks down.

What Sanity and Hygraph actually are

Sanity is a hosted content platform. Your schemas live in a TypeScript config that you version-control. GROQ is the query language — it runs against Sanity's hosted content lake and returns exactly the shape you ask for. The Sanity Studio is an open-source React app you embed into your repo (or deploy separately) and customise at component level.

Hygraph is a hosted GraphQL-native CMS. The schema is configured through a web UI and exposed via a GraphQL API. The standout feature is content federation: Hygraph can stitch in data from external REST or GraphQL APIs — Shopify, Stripe, a custom microservice — and surface it as a unified GraphQL schema alongside your CMS content. Editors never see the difference.

Querying: GROQ vs GraphQL

For most Next.js data fetching this is the most consequential difference.

GROQ lets you project exactly the fields you want, follow references, apply conditional logic, and flatten nested arrays in a single round trip. A typical page query might look like this:

// groq — fetch a page with resolved author and only the fields needed for SSG
*[_type == "post" && slug.current == $slug][0] {
  title,
  publishedAt,
  "author": author->{ name, "avatar": image.asset->url },
  body[] {
    ...,
    _type == "imageBlock" => {
      "url": asset->url,
      "lqip": asset->metadata.lqip,
      "dimensions": asset->metadata.dimensions
    }
  }
}

No over-fetching, no multiple round trips for references. Sanity TypeGen generates TypeScript types from that query, so your RSC components are fully typed without manual interfaces.

Hygraph's GraphQL API is spec-compliant and predictable. If your team already lives in GraphQL and uses a client like urql or graphql-request, the integration feels natural. The schema-first approach means generated types through tooling like GraphQL Code Generator work well. Where Hygraph GraphQL can feel awkward is deeply nested reference traversal — you need to plan your schema to avoid over-fetching, and rich document fields like long-form structured content require more query boilerplate than a GROQ projection.

Content federation is Hygraph's genuine advantage here. If your Next.js app needs to pull product data from Shopify and editorial content from the CMS into a single component without a custom aggregation layer, Hygraph's Remote Sources feature handles that cleanly. With Sanity you'd write that aggregation yourself in a route handler or server component.

Editor experience

Sanity's editor experience is highly configurable but requires developer time to configure well. Out of the box it is functional; with a week of studio customisation — custom input components, structure builder grouping, live preview via Presentation — it becomes excellent. Portable Text is the richest structured content model available in any headless CMS; editors get a Word-like experience with fine-grained control over embedded components.

Hygraph's editor is cleaner to set up for non-developers. Schema changes happen in the UI, no code deployment required. The Rich Text editor is solid and the component model is simpler than Portable Text, which is a reasonable trade-off for teams who want to onboard editors quickly without developer involvement. The limitation is customisation ceiling — you cannot extend the editor UI the way you can with Sanity Studio components.

For multilingual content, both platforms support localisation, but Sanity's document-level internationalisation plugin and Hygraph's built-in locale management are both mature. Hygraph has a slight edge in UI clarity for locale switching; Sanity gives more schema-level control.

Next.js integration

Area	Sanity	Hygraph
Data fetching	`@sanity/client` or `next-sanity` with GROQ	`graphql-request` or any GraphQL client
Type safety	Sanity TypeGen from GROQ queries	GraphQL Code Generator from schema
Draft / preview	Draft Mode with live preview via Presentation plugin	Content Stages + preview URLs (no Studio overlay)
ISR revalidation	Webhooks to `/api/revalidate` with HMAC	Webhooks to `/api/revalidate`
Image CDN	Sanity image pipeline (auto format, hotspot, LQIP)	Hygraph asset API (transformations, but fewer presets)
On-demand ISR	First-class, well-documented	Supported via webhooks

Sanity's image pipeline is deeper. LQIP hashes, hotspot focal crops, and automatic AVIF/WebP negotiation are built into the asset metadata and easy to use with next/image. Hygraph's asset transformations cover the basics — resize, crop, format — but metadata like blur hash requires additional setup.

Both CMSes work well with Next.js App Router RSC. Neither requires a client component for data fetching. Sanity's next-sanity package handles streaming-compatible clients; with Hygraph you use a standard fetch wrapper with graphql-request.

Pricing

Sanity's free tier allows up to 3 users, 2 datasets, and generous API quotas for most small projects. The Growth plan starts at $15/month per seat. The content lake pricing model means API calls and dataset size are the main cost levers — predictable for content-heavy sites, less so for high-traffic APIs.

Hygraph's free tier is more limited on operations (API calls per month) and project count. Paid plans start around $199/month for the Scale tier, which puts it out of reach for freelance or small agency projects. The pricing model is designed for enterprise teams where content federation replaces custom integration work — at that scale, the cost is justified. For a standard marketing site or blog, Sanity's pricing is considerably more accessible.

Where each one breaks down

Sanity's weaknesses: the studio requires developer investment to reach its potential. Teams without a developer to maintain schema changes can struggle. GROQ has a learning curve for engineers coming from GraphQL. And if you need to federate data from external APIs at the CMS layer, Sanity has no equivalent to Hygraph's Remote Sources.

Hygraph's weaknesses: schema changes via the UI mean no Git history for content model evolution — a real operational pain on larger teams. The pricing floor makes it hard to justify for smaller scopes. Rich text and structured content modelling is less expressive than Portable Text. Editor customisation is limited compared to what you can build in Sanity Studio.

Which one to pick

Choose Sanity if your project is content-heavy, your team will invest in studio setup, you want the deepest image pipeline, and your budget is constrained at the start. It fits most Next.js marketing sites, blogs, and product documentation projects.

Choose Hygraph if your architecture already uses GraphQL across services, you need content federation to unify external APIs without writing a custom aggregation layer, and you're working inside an enterprise team where the $199/month floor is not a barrier. The GraphQL-native approach and federation feature are genuinely differentiated — but you're paying for them.

For the majority of Next.js projects I scope, Sanity is the right default. Hygraph earns its place in a specific scenario: composable commerce or multi-service data unification where GraphQL federation does real architectural work.

Contentful alternatives for Next.js in 2026: Sanity, Payload, Strapi, Storyblok, Hygraph

Nayan Kyada — Fri, 10 Jul 2026 07:58:24 +0000

The most common reason teams reach out to me about a CMS migration is Contentful sticker shock — they hit the Enterprise tier wall and realise the bill is climbing past $3,000/month for a mid-sized marketing site. The second reason is that Contentful's schema editor lives entirely in the GUI, which means schema drift, no code review, and no reliable rollback. If either of those sounds familiar, this post maps out the five contentful alternatives for Next.js that I'd actually recommend in 2026, who each one suits, and where each one falls short.

Why teams leave Contentful

Contentful is not a bad product. For non-technical editors who want a polished GUI and don't need a developer to babysit the CMS, it genuinely delivers. The problems surface at scale:

Pricing cliff. The free tier caps at 25,000 records and 2 users. The next meaningful tier (Team) is ~$300/month, and the moment you need SSO, custom roles, or environments beyond sandbox, you're on Enterprise with a custom quote. Most teams I talk to are paying $1,800–$5,000/month.
No code-first schemas. Content types live in the Contentful dashboard. There is no schema.ts you can version-control or generate TypeScript from. This makes multi-environment promotion manual and fragile.
GraphQL is add-on pricing. The REST Content Delivery API is included; the GraphQL API is a paid add-on that counts against API calls differently.
Vendor lock-in on hosted infrastructure. You cannot self-host. If Contentful raises prices again — and they have — you migrate.

None of this is fatal for a funded team with a dedicated DevOps budget. But for a product team or agency building on Next.js App Router, there are now better-fit options.

The five alternatives

Sanity

Sanity defines schemas in TypeScript (defineType, defineField) and stores the source of truth in your git repo. Sanity TypeGen generates fully typed GROQ query results, so your sanity.types.ts is a first-class artifact alongside your Next.js code. The hosted Studio (React-based, fully customisable) ships inside your Next.js repo at /studio via the App Router.

For Next.js specifically, Sanity has the tightest integration story: ISR revalidation via webhooks, draft mode with Presentation, image hot-spot and LQIP metadata baked into asset records, and a real-time content lake that supports streaming SSR naturally. GROQ is more expressive than GraphQL for relational content without n+1 penalties.

Fits: Product and agency teams building content-heavy Next.js sites where developer experience, type safety, and editor customisation all matter. Also the right call when content modelling is complex (multi-locale, multi-tenant, reusable page blocks).

Watch out for: The GROQ learning curve is real if your team only knows GraphQL. The free tier (3 users, 2 datasets) is generous for small projects but the Growth plan at ~$15/user/month adds up on larger editorial teams.

Payload CMS

Payload is code-first and self-hosted (or deployed to Payload Cloud). Schemas are TypeScript config files. It generates its own types automatically. The admin panel is a React app you can extend. It ships its own REST and GraphQL APIs and, from Payload 3.x, runs natively inside a Next.js App Router project — the same next dev process runs both the CMS admin and your front-end.

Fits: Teams that want full ownership of the stack, need custom back-end logic (order management, auth flows, custom endpoints), or are working in a regulated environment where data residency matters. Excellent for a small team that also needs a lightweight back-end API.

Watch out for: You're managing your own database (Postgres or MongoDB), deployments, and upgrades. Payload Cloud reduces that burden but it's still younger than Contentful's infrastructure. Editor UI is functional but not as polished as Sanity Studio.

Strapi

Strapi is the most widely used open-source headless CMS. It has a GUI-based content type builder (like Contentful) but you can also define types via code files. Deployable anywhere, supports SQLite/Postgres/MySQL. Strapi 5 brought improved TypeScript support and a new document service API.

Fits: Teams coming from WordPress or Drupal who want something familiar. Also good when a non-developer needs to create content types without writing code.

Watch out for: Strapi's TypeScript story is still catching up to Payload's. The plugin ecosystem is wide but quality varies. For complex Next.js ISR setups, the webhook layer needs custom work. Strapi Cloud exists but many teams self-host and then underestimate the ops burden.

Storyblok

Storyblok is a visual CMS — editors see their content rendered in a live preview sidebar as they edit components. Its component model maps directly to page-builder blocks. It has a Next.js SDK and supports ISR.

Fits: Marketing teams and agencies building landing pages where non-technical editors need to assemble layouts without developer involvement. If the main complaint about Contentful is that editors can't see what they're editing, Storyblok is the most direct fix.

Watch out for: Schema is defined in the Storyblok GUI (same code-drift problem as Contentful). The content API can be verbose for complex relational content. Pricing scales by seats and API calls; at high traffic you'll need a CDN caching strategy.

Hygraph (formerly GraphCMS)

Hygraph is a federated content platform — it can stitch your Contentful content together with other data sources (Shopify, Salesforce) via a unified GraphQL layer. If your Contentful usage was mostly driven by its GraphQL API and you have multiple upstream data sources, Hygraph is the cleanest migration path.

Fits: Teams with a GraphQL-first architecture, especially e-commerce or enterprise projects combining product data with editorial content.

Watch out for: Hygraph's free tier is limited. The federated layer adds latency and complexity that most content sites don't need. It's the most niche of the five.

Side-by-side table

	Sanity	Payload	Strapi	Storyblok	Hygraph
Schema definition	Code (TypeScript)	Code (TypeScript)	GUI + code files	GUI only	GUI only
Self-hostable	No (Studio in repo, data in cloud)	Yes	Yes	No	No
Next.js integration depth	★★★★★	★★★★★	★★★☆☆	★★★★☆	★★★☆☆
Editor experience	Excellent	Good	Good	Excellent (visual)	Good
Free tier	Generous (3 users)	Open source (self-host)	Open source (self-host)	Limited	Limited
TypeScript types	Auto-generated (TypeGen)	Auto-generated	Manual / partial	SDK types	SDK types
Best for Contentful migrators who…	Want code-first schemas + rich studio	Want full self-hosted control	Want familiar GUI, open source	Want visual editing for marketers	Have GraphQL-first + multi-source needs

Which one to pick

If the main pain with Contentful is pricing and you want a better developer experience: Sanity. The TypeScript-first workflow, GROQ, and tight Next.js App Router integration make it the default recommendation for most projects I scope.

If you need to own your data and your infrastructure: Payload. Especially if you're also building custom API endpoints alongside your content layer.

If your editors are the bottleneck and they want to assemble pages visually: Storyblok. Accept the GUI-only schema trade-off; the editor productivity gain is real.

If Contentful's GraphQL API was the thing your team loved and you have federated data sources: Hygraph.

If you want the lowest long-term licensing cost and your team is comfortable with self-hosted ops: Strapi or Payload.

Migrating CMS mid-project is expensive regardless of which direction you go. The schema design decision at the start of a Next.js project determines how painful that migration becomes — which is why code-first, version-controlled schemas are worth prioritising from day one.

// sanity/schemas/article.ts — code-first schema, lives in git
import { defineType, defineField } from 'sanity'

export const articleSchema = defineType({
  name: 'article',
  title: 'Article',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: (r) => r.required() }),
    defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'body', type: 'array', of: [{ type: 'block' }] }),
  ],
})
// `npx sanity@latest typegen generate` produces sanity.types.ts from this

That single file — committed, reviewed, and diffed like any other TypeScript — is the clearest illustration of why teams moving off Contentful land on Sanity or Payload rather than another GUI-first CMS.

How I migrate WordPress to Sanity + Next.js: a technical walkthrough

Nayan Kyada — Thu, 09 Jul 2026 08:03:44 +0000

Migrating WordPress to Sanity + Next.js is mostly a data engineering problem. The decisions around whether to migrate are covered elsewhere — this post is purely about the mechanics: getting content out of WordPress, shaping it into typed Sanity documents, and making sure Google never sees a broken URL.

I'll walk through the four stages I use on every migration: export, schema mapping, import scripting, and redirect wiring.

Exporting WordPress content

WordPress gives you two export paths. The WXR (WordPress eXtended RSS) XML file you get from Tools → Export is fine for small sites, but it serialises everything into one flat file and the HTML inside <content:encoded> nodes is a pain to parse. I prefer the REST API for anything above a few hundred posts.

For a typical site with posts, pages, and categories I pull:

https://old-site.com/wp-json/wp/v2/posts?per_page=100&page=1
https://old-site.com/wp-json/wp/v2/pages?per_page=100&page=1
https://old-site.com/wp-json/wp/v2/categories?per_page=100
https://old-site.com/wp-json/wp/v2/media?per_page=100

I paginate through all of them and write each collection to a local JSON file. The media endpoint is worth fetching separately — it gives you source_url, alt_text, and mime_type for every attachment, which you need for image migration.

One gotcha: custom post types registered by plugins won't appear under /wp/v2/posts. Check wp-json/wp/v2 for the full namespace list and add any CPTs you find.

Mapping WordPress types to Sanity schemas

WordPress has a flat mental model: everything is a post with a post type. Sanity wants explicit document types with typed fields. I do the mapping on paper before writing a single line of import code.

Typical equivalences:

WordPress	Sanity document type
`post`	`blogPost`
`page`	`page`
`category`	`category`
`tag`	`tag`
`attachment`	inlined as `image` field or `figure` block

The Sanity schemas for blogPost and category look like this in my projects:

// sanity/schemas/blogPost.ts
import { defineType, defineField } from 'sanity'

export const blogPostSchema = defineType({
  name: 'blogPost',
  title: 'Blog post',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: Rule => Rule.required() }),
    defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'publishedAt', type: 'datetime' }),
    defineField({
      name: 'categories',
      type: 'array',
      of: [{ type: 'reference', to: [{ type: 'category' }] }],
    }),
    defineField({
      name: 'excerpt',
      type: 'text',
      rows: 3,
    }),
    defineField({
      name: 'body',
      type: 'array',
      of: [{ type: 'block' }, { type: 'image' }],
    }),
    defineField({
      name: 'seo',
      type: 'object',
      fields: [
        defineField({ name: 'metaTitle', type: 'string' }),
        defineField({ name: 'metaDescription', type: 'text', rows: 2 }),
        defineField({ name: 'canonicalUrl', type: 'url' }),
        defineField({ name: 'legacySlug', type: 'string' }), // stores original WP slug
      ],
    }),
  ],
})

Notice seo.legacySlug. I always store the original WordPress slug on every document. It makes the redirect matrix trivial to generate later.

Writing the import script

The import script has three jobs: upload images to Sanity's asset store, convert HTML body content to Portable Text, and create the documents.

I use @sanity/client directly and the sanity-block-content-to-hyperscript / html-to-portable-text ecosystem. The cleanest library I've found for the HTML conversion is @portabletext/html-input — but it's new and the API shifts. A more stable option is running the WordPress HTML through htmlparser2 and mapping nodes manually. For most blog content the tags involved are limited enough that a manual mapper is 100 lines and fully predictable.

// scripts/migrate.ts
import { createClient } from '@sanity/client'
import { JSDOM } from 'jsdom'
import fs from 'node:fs'

const client = createClient({
  projectId: process.env.SANITY_PROJECT_ID!,
  dataset: 'production',
  apiVersion: '2024-06-01',
  token: process.env.SANITY_WRITE_TOKEN!,
  useCdn: false,
})

const wpPosts: WpPost[] = JSON.parse(fs.readFileSync('./export/posts.json', 'utf8'))
const wpMedia: Record<number, WpMedia> = JSON.parse(fs.readFileSync('./export/media-map.json', 'utf8'))

async function uploadImage(sourceUrl: string, altText: string) {
  const res = await fetch(sourceUrl)
  const buffer = Buffer.from(await res.arrayBuffer())
  return client.assets.upload('image', buffer, {
    filename: sourceUrl.split('/').pop(),
    description: altText,
  })
}

function htmlToBlocks(html: string): PortableTextBlock[] {
  const dom = new JSDOM(html)
  const blocks: PortableTextBlock[] = []
  for (const node of dom.window.document.body.children) {
    const tag = node.tagName.toLowerCase()
    const text = node.textContent ?? ''
    if (['p', 'h2', 'h3', 'h4', 'blockquote'].includes(tag)) {
      blocks.push({
        _type: 'block',
        _key: crypto.randomUUID(),
        style: tag === 'p' ? 'normal' : tag,
        children: [{ _type: 'span', _key: crypto.randomUUID(), text, marks: [] }],
        markDefs: [],
      })
    }
    // extend: handle <ul>, <ol>, <figure> etc.
  }
  return blocks
}

async function run() {
  for (const post of wpPosts) {
    const featuredMedia = post.featured_media ? wpMedia[post.featured_media] : null
    let featuredImageRef = null
    if (featuredMedia) {
      const asset = await uploadImage(featuredMedia.source_url, featuredMedia.alt_text)
      featuredImageRef = { _type: 'image', asset: { _type: 'reference', _ref: asset._id } }
    }

    const doc = {
      _type: 'blogPost',
      _id: `wp-post-${post.id}`,
      title: post.title.rendered,
      slug: { _type: 'slug', current: post.slug },
      publishedAt: post.date_gmt,
      excerpt: post.excerpt.rendered.replace(/<[^>]+>/g, '').trim(),
      body: htmlToBlocks(post.content.rendered),
      featuredImage: featuredImageRef,
      seo: {
        legacySlug: post.slug,
        canonicalUrl: post.link,
      },
    }

    await client.createOrReplace(doc)
    console.log(`Imported: ${post.slug}`)
  }
}

run().catch(console.error)

A few things worth noting here. I prefix _id with wp-post- so re-running the script is idempotent — createOrReplace won't create duplicates. I upload images before creating the document so the reference is ready. The htmlToBlocks function above is a skeleton — you'll need to add handlers for <ul>, <ol>, <a>, <strong>, <em>, and <figure> based on what's in the actual content. Dump a sample post and audit the tags before writing the full mapper.

Run this script locally against a staging dataset first, never production. Check a random 10% of posts in Sanity Studio before promoting to production.

Preserving SEO with a 301 redirect matrix

WordPress URLs are usually /year/month/post-slug/ or just /post-slug/ depending on the permalink setting. Next.js App Router typically uses /blog/[slug]. That's a different path structure, so every old URL needs a 301.

After the import is done I query Sanity for every legacySlug and the new slug in one GROQ query:

// GROQ query to generate redirect map
*[_type == "blogPost"] {
  "from": seo.legacySlug,
  "to": slug.current
}

I export that as a JSON array and write it into next.config.ts as static redirects for small sites, or into a middleware lookup for large ones. The next.config.ts approach is simpler and gets baked into the Vercel edge config:

// next.config.ts — for sites with < 1000 legacy URLs
import type { NextConfig } from 'next'
import redirectMap from './redirects.json' // generated from GROQ export

const config: NextConfig = {
  async redirects() {
    return redirectMap.map(({ from, to }) => ({
      source: `/${from}`,           // e.g. /old-post-slug
      destination: `/blog/${to}`,    // e.g. /blog/new-post-slug
      permanent: true,
    }))
  },
}

export default config

For sites with category archives at /category/[slug]/ I build the same matrix for category documents. WordPress tag pages at /tag/[slug]/ usually don't need preserving unless they have inbound links — check Search Console before deciding.

Once the redirects are live I submit a new sitemap via Search Console and run a crawl with Screaming Frog to verify there are no chains (301 → 301) and no 404s. Category and pagination pages from WordPress that have no equivalent in the new site should redirect to the nearest logical parent — usually /blog or /.

The whole migration for a 300-post blog typically takes two focused days: half a day on export and schema design, half a day on the import script, and one day on redirect audit and staging QA.

DEV Community: Nayan Kyada

CMS apps explained: what marketing and product teams actually get

What CMS apps actually do

Content models: the layer most buyers overlook

The editing interface

Publishing workflows

Integrations with the rest of your stack

Choosing the right class of CMS app

Tailwind CSS in 2026: what actually changed for teams

The CSS-first config is not just syntax sugar

The Oxide engine changes what the build step costs

Container queries are now a first-class workflow, not a plugin

What this means for the design-to-code handoff

The honest team verdict

Sanity video hosting in 2026: Mux vs Cloudinary vs Bunny Stream

What the comparison covers

Mux

Cloudinary

Bunny Stream

Side-by-side summary

Which to pick

Sanity vs WordPress cost: annual TCO once you're already live

What counts as steady-state cost

Hosting

Plugin and license costs

Maintenance and security-patching time

Editor efficiency

Annual cost comparison

Where WordPress still wins on running cost

The number that changes the decision

Sanity image-url hotspot not working: four causes and fixes

The four causes (and their fixes)

1. fit is still set to clip instead of crop

2. Missing options: { hotspot: true } on the schema field

3. Passing only asset._ref to the URL builder instead of the full image object

4. Hotspot values outside the 0–1 range from a bad data import

How to confirm hotspot is working

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

What each tool actually is

Data ownership and where your content lives

Schema approach

GROQ vs REST/GraphQL

Editor UX

Self-hosting

Which one to choose for a Next.js project

Contentful pricing 2026: free tier limits, the $300 cliff, and Enterprise

What the Community free tier actually includes

The $300 jump: Contentful Basic

Contentful pricing table: 2026

Enterprise: what you can expect

The comparison question: Contentful vs Sanity at the same budget

What actually triggers the upgrade

Is the $300 justified?

Payload CMS pricing 2026: the real infrastructure cost breakdown

What Payload CMS actually costs (spoiler: $0 for the software)

Hosting options compared

Database costs

File storage

Cost table by project size

What actually triggers a cost increase

Realistic monthly totals

Strapi pricing 2026: Community edition, Cloud tiers and real infra costs

The Community edition: free but not zero cost

Strapi Cloud tiers in 2026

What actually triggers a move to Strapi Cloud

Strapi Cloud vs self-hosted: total cost comparison

Decision guide by team size

The Strapi v5 migration cost

Sanity vs Hygraph 2026: an honest side-by-side for Next.js teams

What Sanity and Hygraph actually are

Querying: GROQ vs GraphQL

Editor experience

Next.js integration

Pricing

Where each one breaks down

Which one to pick

Contentful alternatives for Next.js in 2026: Sanity, Payload, Strapi, Storyblok, Hygraph

Why teams leave Contentful

The five alternatives

Sanity

1. `fit` is still set to `clip` instead of `crop`

2. Missing `options: { hotspot: true }` on the schema field

3. Passing only `asset._ref` to the URL builder instead of the full image object

4. Hotspot values outside the `0–1` range from a bad data import