Open-source Ecommerce

March 17, 2026

Composable eCommerce Stack: CMS, Payments, and Search

API-first ecommerceCMS ecommercecomposable commerceecommerce integrationsecommerce tech stackHeadless Commerceheadless ecommerce platform

The ecommerce platforms that most teams picked five or ten years ago were not designed for what CMS tools, search engines, and payment providers can do today. Here is how a composable eCommerce stack works, what each layer does, and why Spree Commerce fits at the center.

Key Takeaways

Last verified: April 2026

The problem: Legacy ecommerce platforms lock every team into dated tools for content, search, and payments because the architecture was not built to evolve.

The shift: Purpose-built CMS, search, and payment tools now outperform anything a single platform bundles, and AI coding tools have cut integration costs dramatically.

How it works: Pick the CMS your content team loves, the search engine your customers deserve, and the payment providers your finance team needs. Spree Commerce handles the commerce layer and connects to all of them.

Why Spree Commerce: Open source, zero platform fees, everything built in. One REST API for your storefront, with built-in adapters for payments and search that keep you off the vendor lock-in treadmill.

The eCommerce Platforms Most Teams Chose Were Not Built for Today

A Forrester study found that 93% of organizations say their digital commerce operations are impacted by technology limitations. That is not surprising when you look at the timeline: Magento launched in 2008. SAP Hybris dates back to 1997. Even Shopify, often considered modern, launched in 2006. These platforms have evolved, but their core architectures reflect the era they were born in.

The gap shows up everywhere. Your marketing team wants a visual editor like Storyblok or a developer-friendly CMS like Payload. The platform ships its own page builder that has not kept up. Your customers expect typo-tolerant, AI-assisted product search. The platform offers exact keyword matching. Your finance team wants to route payments to the cheapest processor per region. The platform only works with one.

Gartner’s 2020 report on composable business applications projected that “organizations that have adopted a composable approach will outpace the competition by 80% in the speed of new feature implementation.” That was a forward-looking projection, not measured data. But the underlying insight has proven out: when each layer of your stack can evolve independently, the whole business moves faster.

The composable approach has its critics. VTEX exited the MACH Alliance in March 2025, calling the vision “dogmatic” and pointing to integration complexity. Fair point: stitching together fifteen SaaS vendors with custom middleware is expensive and fragile. But the critique is about execution, not the principle. The answer is not to go back to monoliths. The answer is an open-source commerce platform with everything built in that connects cleanly to the few external tools that genuinely outperform its native capabilities.

The idea is straightforward. Instead of one platform doing everything adequately, you pick purpose-built tools for each job and connect them through APIs. Your CMS handles content. Your payment provider handles transactions. Your search engine handles product discovery. And your ecommerce platform handles the commerce layer: products, pricing, cart, checkout, and orders.

AI coding tools have made this even more practical. Integration development that used to take weeks now takes hours. When the cost of connecting two systems drops by an order of magnitude, the composable approach stops being an enterprise-only luxury.

This guide walks through each layer of a composable stack, the tools people are actually choosing, and where Spree Commerce fits.

Which CMS Platforms Pair With a Composable eCommerce Backend?

Your CMS and your ecommerce platform run independently. Your storefront calls each through its own API and composes the result. The CMS never touches commerce logic. The ecommerce platform never stores editorial content. They each stay in their lane.

That means any CMS with a content API works. But some pairings are more natural than others. Here are six that teams are choosing right now, each serving a different team profile:

Contentful is the enterprise CMS market leader. Teams already running Contentful for marketing sites add commerce by pointing their storefront at Spree’s REST API alongside Contentful’s Content Delivery API. The cost angle matters here: Contentful’s SaaS subscription plus Spree’s zero platform fees often undercuts pairing Contentful with a SaaS commerce platform that charges per-transaction fees on top.

Payload CMS is the fastest-growing open-source CMS, built natively on Next.js. Because Spree ships a production-grade Next.js eCommerce storefront starter, both share the same framework and TypeScript toolchain. Payload has its own ecommerce plugin for simple carts, but it stops at checkout. It has no B2B buyer organizations or approval workflows, no marketplace vendor splitting, no multi-tenant architecture. For anything beyond a simple storefront, Payload handles content and Spree handles commerce.

Strapi is one of the most popular open-source headless CMS projects, with over 70,000 GitHub stars. For teams that want both their CMS and their commerce platform to be open-source and self-hosted, Strapi plus Spree is the natural pairing. Both run on your infrastructure. Both are API-first. Both are free to get started.

Sanity calls itself a “content operating system” and stores everything in a queryable data lake. Its developer-first philosophy matches Spree’s API-first headless ecommerce approach: both assume you will build the frontend yourself and connect the pieces through APIs.

Storyblok offers a visual editor that non-technical content teams love. Marketing managers drag and drop pages without writing code. Storyblok’s integration marketplace does not list Spree yet, which means every Storyblok user who needs open-source ecommerce with zero platform fees connects through the same API pattern as any other CMS pairing described above.

Cloudflare EmDash launched in April 2026 as Cloudflare’s answer to WordPress: a CMS built for the edge. For teams already on Cloudflare Workers and Pages, EmDash handles content while Spree’s stateless REST API serves commerce data from any origin. This pairing is new but the timing is perfect.

The common thread across all six: your CMS choice depends on your content team’s workflow, not on your commerce platform. Pick the CMS they love, connect it to Spree’s API, and let each system do what it does well. Each of these CMS platforms gets its own deep-dive guide in this series, covering architecture patterns, code examples, and deployment specifics.

How Does Product Search Keep Up With What Customers Expect?

Most ecommerce platforms bundle search as an afterthought. You get keyword matching that slows as your catalog grows and returns zero results when someone types “runnng shoes” instead of “running shoes.” Meanwhile, dedicated search engines have leapfrogged what any single platform bundles.

Spree ships with a native Meilisearch integration: an open-source search engine with over 50,000 GitHub stars that delivers typo-tolerant, faceted product search in single-digit milliseconds. A customer types “runnng shoes” and still gets the right results. They filter by size, color, and price range without the page reloading. This is the same experience that Algolia charges thousands per month to deliver, running on your own infrastructure at zero licensing cost.

Algolia remains the market leader for enterprise search. If your team already uses Algolia for site search across multiple properties, Spree connects to it through the same adapter pattern. The difference is you stop paying platform fees on top of Algolia’s own subscription.

For teams that need something different, Spree’s custom search provider architecture lets you swap in Elasticsearch, Typesense, or a vector database for AI-powered semantic search through a clean adapter interface. Your storefront calls one search endpoint regardless of what powers it behind the scenes.

The pattern works the same across search providers. Spree indexes your product catalog into whichever search engine you configure and delegates queries to it. When a faster or cheaper option appears, you swap the search layer without touching the rest of your stack. That replaceability is the whole point of composable architecture.

What Are Your Payment Provider Options in a Composable Stack?

A 2024 FIS Global report found that merchants lose an average of 2.1% of revenue to payment processing inefficiencies when locked into a single provider. The fix is straightforward: use different providers for different regions, card types, and customer preferences.

Spree’s Payment Sessions API makes this simple. One endpoint. Your storefront calls it to start a payment. Spree routes to whichever provider is configured for that transaction.

Stripe is the default for most projects. Full card and wallet support, with Stripe Connect for marketplace vendor payouts through the Enterprise Edition. If you are building a multi-vendor marketplace, Stripe Connect splits payments across vendors automatically.

Adyen serves enterprise merchants processing across multiple countries. Spree’s Adyen integration is an open-sourced formal partnership, and Adyen for Platforms handles marketplace payouts at enterprise scale.

PayPal covers buyers who prefer their PayPal account over entering card details. It is a one-click addition through the admin panel.

A merchant can run Stripe in North America, Adyen in Europe, and PayPal everywhere as a fallback. Switching or adding a provider is a backend configuration change, not a code rewrite. That flexibility matters more than it sounds: when a payment provider raises fees, changes terms, or drops support for a region, you move to a different one without touching your checkout flow or your storefront code.

Where Does a Composable eCommerce Stack Run?

A self-hosted ecommerce platform deploys wherever your infrastructure team decides. Unlike SaaS platforms that host your data on shared infrastructure in a region you did not choose, a composable stack lives on your cloud, in your region, under your compliance boundary.

Spree provides official Docker images, AWS deployment guides, and Render one-click setup. Docker Compose handles local development with PostgreSQL, Redis, and Sidekiq configured out of the box. If your team already uses containers, Spree fits into your existing CI/CD pipeline without changes.

Cloudflare Workers and Pages serve your Next.js storefront at the edge while Spree’s API runs from any origin. Content loads from Cloudflare’s global network. Commerce data comes from your backend. Edge performance for the storefront, full control over the commerce data. For teams already invested in the Cloudflare ecosystem, this pairing means the storefront loads in milliseconds globally while the commerce backend stays on infrastructure you control.

Supabase often appears alongside Spree in modern composable stacks. Supabase handles user authentication, real-time features, and supplementary data through its managed PostgreSQL and auth services. Spree handles everything that is commerce: products, pricing, orders, checkout. Both expose REST APIs. Both can self-host.

For teams in regulated industries or EU-based companies with data sovereignty requirements, this deployment flexibility is not a nice-to-have. It is a compliance requirement. Your commerce data lives on your infrastructure, in your region, under your control. No shared tenancy, no vendor deciding where your data lives.

GoDaddy runs over 10,000 stores on Spree’s open-source architecture, proving that self-hosted does not mean small-scale. It means you own the infrastructure decisions.

How Does Spree Commerce’s REST API Tie the Stack Together?

Every commerce operation your storefront needs runs through one interface: Spree’s REST API with full OpenAPI 3.0 specs. Products, pricing, cart operations, checkout, payment sessions, and orders all come from the Store API. A separate Admin API handles back-office operations. Standard HTTP. JSON payloads. OpenAPI specs that import into Postman in seconds.

Your storefront calls one API surface for all commerce operations. Behind that surface, Spree’s built-in adapters handle the specifics: Stripe and Adyen for payments, Meilisearch for search, your chosen CMS for content. Your frontend never needs separate payment SDKs, search clients, or CMS libraries. One authentication model. One set of endpoints.

Spree ships a TypeScript SDK for JavaScript frameworks. A single npx create-spree-app@latest my-store scaffolds a production-ready Next.js storefront connected to the API. For teams using AI coding assistants, Spree publishes an AGENTS.md file and a dedicated MCP server so tools like Claude Code and Cursor can generate integration code faster.

This is what “everything built in, not plugins” means in practice. The commerce capabilities — B2B buyer organizations, multi-vendor marketplace, multi-tenant white-label storefronts, price lists, promotions, multi-warehouse inventory — are all native. You add the CMS, search engine, and payment providers that fit your team. The commerce layer is already there.

Frequently Asked Questions