AURORA Commerce: a zero‑infrastructure Nuxt 4 storefront built on YAML, Nuxt Content v3, and Stripe
AURORA Commerce is a zero‑infrastructure Nuxt 4 storefront that stores products as YAML and uses Nuxt Content v3 and Stripe to power bilingual e-commerce sites.
AURORA Commerce rethinks the assumptions that accompany most small e-commerce builds. Instead of a separate CMS, a hosted database, and an admin UI, this Nuxt 4 storefront keeps product records in plain YAML files in the repository, uses Nuxt Content v3 for typed queries, and relies on a single server route to create Stripe Checkout sessions. The result is a deployable, bilingual storefront with essentially no recurring infrastructure costs — an appealing trade‑off for curated catalogs and developer-driven shops. This article walks through the architecture, developer experience, trade-offs, and who should (and shouldn’t) adopt this approach.
The repo-as-database approach
The core design decision behind AURORA Commerce is simple: treat the Git repository as the source of truth for catalog data. Each product is a discrete YAML file under a content directory; creating or updating a product is as straightforward as adding or editing a file and pushing a commit. For stores with a curated inventory — think 10 to a few hundred SKUs — this pattern eliminates the need for a separate CMS subscription, database hosting, or migration tooling.
Operationally, this reduces moving parts. A marketing or product change that would normally require logging into a CMS now becomes a Git commit and a deploy trigger. Pricing updates, image swaps, and copy changes are auditable via commit history and pull requests, which aligns well with teams that already use GitOps or want review workflows for content. Because product metadata (titles, descriptions, price, sizes, images, attributes) is stored alongside the codebase, it becomes trivial to validate types, enforce linting rules, and integrate content checks into CI pipelines.
That repo-first model also simplifies deployments. When a changelist is merged, the static site generator (Nuxt 4) compiles the latest content, and the site publishes the updated catalog. For projects that favor low operating expense and maximum control, this is a practical compromise: you give up a visual CMS for a much smaller operational footprint and better developer ergonomics.
How Nuxt Content v3 provides typed content and fast queries
Nuxt Content v3 acts as the bridge between file-based content and the running Nuxt application. It parses YAML files into a typed collection and exposes a query API that feels familiar to developers: filter collections, order results, and fetch individual records by slug. Because Nuxt Content generates a typed schema from your product files, TypeScript and IDEs provide autocomplete on nested fields like product.sizeChart or product.fabricWeightGsm — a big win for developer experience and guardrails against runtime errors.
This setup yields two practical advantages. First, querying for a catalog listing or a single product is fast and deterministic: everything is compiled at build time and can be statically rendered or server-rendered on demand. Second, it keeps product data strongly typed and testable. You can add schema validation rules or use linters in CI to prevent malformed product entries from reaching production. For teams that value reliability and compile-time guarantees, Nuxt Content v3 makes a file-based approach feel robust rather than ad-hoc.
A minimal backend for secure Stripe checkout
The only server-side code in AURORA Commerce is a single API route responsible for creating Stripe Checkout sessions. The checkout flow is deliberately minimal: the frontend maintains cart state (Pinia), sends the cart to the server route, the server instantiates Stripe using a secret key, creates a Checkout session with line items and price data, and returns the session URL for a redirect.
One important implementation detail is the use of price_data in each line item rather than pre-created Stripe Price IDs. By synthesizing the price and product metadata at session creation, the storefront keeps the source of truth in the YAML files and avoids maintaining a separate products catalog inside Stripe. This also simplifies onboarding: teams do not need to pre-sync product SKUs with Stripe’s dashboard. The server route handles currency conversion semantics (for example, converting euros into cents) and can include shipping address collection rules and allowed countries, which keeps payment and compliance logic centralized and minimal.
Because Stripe secret keys still live in environment variables, standard precautions apply: keep keys out of the repository, rotate credentials when necessary, and use your hosting platform’s secrets manager (for example, Vercel environment variables). The approach trades a small amount of server-side responsibility for eliminating a larger fleet of backend services.
Bilingual content strategy without an i18n library
AURORA Commerce supports English and French without a separate translation system by storing bilingual fields directly in each product file (e.g., title and titleFr, description and descriptionFr). Nuxt’s routing strategy (prefixing the French locale under /fr while leaving English at the root) makes it possible to resolve the appropriate field at render time with a small composable that returns the locale-appropriate value.
This pattern has several benefits: translation copy is colocated with the product it describes, reducing synchronization issues; small teams don’t need to maintain a parallel localization pipeline; and there are no extra translation keys sprawled across the codebase. The trade-off is that it only scales comfortably for a small number of locales and for teams that are comfortable managing bilingual content in the repository. For projects that require dynamic translation workflows, community translation platforms, or a changing set of locales, a dedicated i18n solution or headless CMS would be a better long-term fit.
Design tokens centralized in Tailwind
To maintain a consistent visual identity, AURORA Commerce centralizes design tokens in tailwind.config.ts. Brand colors, fonts, and other tokens live in one place so a single modification — for example, changing brand.accent — cascades across the UI. This reduces the “hunt for the component” problem: designers and developers can alter visual system primitives without touching individual components.
Centralizing tokens in Tailwind also supports theming patterns such as dark mode or seasonal variants. Because Tailwind is compiled at build time, modifying tokens is part of the same deployment flow as content changes, meaning branding tweaks can be staged, reviewed, and released alongside product updates.
When AURORA Commerce is the right fit
This architecture shines for several categories of projects:
- Curated, small catalogs (tens to low hundreds of SKUs) where inventory is relatively stable.
- Indie brands, pop-up shops, or direct-to-consumer lines that want to avoid ongoing SaaS costs.
- Prototypes, MVPs, and experiments where speed of delivery and low operational burden matter more than complex commerce features.
- Teams comfortable with Git-based workflows and pull-request driven content updates.
In these contexts, you get a modern frontend stack — Nuxt 4 and Vue 3 — combined with TypeScript, Pinia for state management, Tailwind for styling, and Stripe for payments, without the overhead of a content platform or a dedicated backend.
When this approach is not suitable and migration options
There are clear limits. If you need real-time inventory synced with multiple warehouses, complex multi-dimensional product variants, B2B pricing rules, or a client that requires a visual, non-technical content editing experience, a file-based repo approach will feel constraining. Similarly, very large catalogs (thousands of SKUs) will run into scaling and content management friction.
AURORA Commerce anticipates that trade-off by designing for extensibility: the data-access layer is a single abstraction. If you outgrow the file-based collection, you can replace queryCollection calls with an adapter that queries Sanity, Contentful, or your own headless CMS with minimal changes to the UI and checkout flow. That migration path preserves the investment in frontend components while swapping the backend content store — a practical way to start small and scale later.
Developer experience, workflow, and operational considerations
For developers, the repo-first model improves visibility and control. Content changes live in the same version control system as code, enabling PR reviews, automated tests, and schema validation. Because Nuxt Content exposes typed models, you can add TypeScript interfaces and CI checks to catch invalid product files before deployment.
Operationally, the storefront can be hosted on a serverless platform such as Vercel. Build pipelines compile content and assets, and environment variables (Stripe secret key, public app URL) configure runtime behavior. Security practices remain conventional: keep secrets out of code, use HTTPS, and monitor for anomalous server route usage.
There are also practical UX considerations: because there is no admin UI, non-technical stakeholders will need a change process (for example, opening issues or merge requests). For some teams, a simple content PR workflow with a short onboarding doc is sufficient; for others, building a lightweight internal admin that edits YAML and commits to the repo could bridge the gap without adopting a full CMS.
Integration and ecosystem fit
AURORA Commerce sits comfortably within modern frontend ecosystems. It pairs with common developer tools: TypeScript for typing, Pinia for cart state, Tailwind CSS for design tokens, and Bun for fast local development. It also interoperates with the broader landscape of e-commerce tooling: Stripe handles payments, so plugins and webhooks can be added for fulfillment, email notifications, or analytics without changing the core catalog approach.
From an integrations standpoint, keeping product metadata in YAML doesn’t lock you out of external services. Fulfillment and inventory can be delegated to a third-party platform that consumes order webhooks from Stripe or a serverless function. If you later adopt a headless CMS, the adapter pattern means the storefront UI and checkout flow need little modification.
Business cases and cost implications
One of the strongest arguments for AURORA Commerce is cost predictability. Eliminating a commercial CMS and an always-on backend reduces monthly bills; for small merchants that margin crunch, that matters. The time-to-market is also competitive: a developer can spin up a usable storefront, wire a Stripe account, and deploy to Vercel in under an hour if the product data is ready.
However, cost savings come with labor trade-offs. Non-technical content updates require engineering involvement, unless you invest in a lightweight content workflow or an internal editing interface. For agencies building sets of small stores for clients, the repo-first model lowers recurring costs but increases the need for documented processes and onboarding.
Broader implications for e‑commerce and web development
AURORA Commerce exemplifies a continuing shift toward composable, code-centric commerce. The Jamstack and GitOps movements have shown that many web experiences can be driven by static content augmented with minimal server-side logic. By pushing product data into the repository and limiting dynamic behavior to payment session creation, this pattern reduces operational complexity and increases visibility for engineering teams.
For the industry, that suggests a tiered model of commerce platforms: large enterprises continue to rely on full-featured headless commerce systems with robust inventory and API ecosystems, while smaller merchants and experimental projects can adopt repo-first storefronts to lower costs and accelerate iteration. It also challenges the idea that a CMS is always necessary for content management: for some teams, Git provides better auditability and control.
Developers benefit from this arrangement because it reinforces best practices around type safety, CI-driven validation, and design-system discipline. But product owners and agencies should also weigh the non-technical costs: a lack of a visual editor and the need for developer involvement in content updates could be a strategic choice rather than a limitation.
How to get started with AURORA Commerce
Get going in a few pragmatic steps:
- Clone the starter repository and inspect the content/products directory to see how product files are structured.
- Add or duplicate a YAML product file to create your first SKU; include bilingual fields if you need French support.
- Configure your environment variables: set the public app URL and a Stripe secret key in your hosting platform.
- Test locally (Nuxt 4 dev), ensure TypeScript validations pass, and run a build to verify static pages compile.
- Deploy to a platform like Vercel for automatic builds on push; open a test Stripe Checkout session and validate the success and cancel flows.
- Adjust tailwind.config.ts to set your brand tokens so design changes propagate sitewide.
For teams that want a visual editing path later, plan for an adapter layer early: keep the query layer abstracted so that you can swap Nuxt Content for a managed content API later without rewriting UI components.
AURORA Commerce is not a one-size-fits-all replacement for enterprise platforms, but it is a thought-through alternative for projects where low cost, full control, and developer-centric workflows matter.
AURORA Commerce demonstrates how thoughtful choices — colocation of content, typed queries, centralized design tokens, and a single payment backend — can deliver a fully functional storefront with a fraction of the infrastructure we commonly accept. As developer tools and headless payments continue to mature, expect more hybrid patterns like this: repo-managed catalogs that can seamlessly graduate to managed content stores when scale or client needs demand it. Future iterations may add optional admin layers, automated importers for inventory systems, more flexible translation handling, or built-in analytics and fulfillment connectors — all without changing the core premise that, for many small merchants, the simplest architecture is the most effective.
