We've rethought how developers interact with the platform from project initialization to deployment.

Here's what we've been working on and what's coming next.

From Storefront to Platform - Rethinking the Nimara 

Traditionally, a storefront is just the frontend layer sitting on top of a backend like Saleor - and that's precisely how Nimara started. But we're rethinking that and moving toward a more platform-oriented architecture. 

What began as a frontend is evolving into a complete foundation for launching a real, production-ready commerce setup. That means not just UI but all the integrations you need: payments, CMS, search, and more.

The Nimara Storefront is now a complex component: a composition of smaller frontend modules, infrastructure elements, and services. You may think of it less like a single app and more like a curated bundle of interoperable tools tailored for composable commerce projects.

Modular Architecture with Submodules

We've broken Nimara down into reusable parts, so each service now lives in its own Git repo:

• Nimara Mailer (notifications),
• Nimara Stripe (payments),
• Nimara Storefront (frontend),
• ...and more to come.

Using Git submodules, you will be able to fork, plug in, and extend components without disrupting the platform.

And yes, we're aware that monorepos have their perks. However, submodules will give us finer control over versioning and dependencies, especially when different teams own different components.

Clean Starts with platform-init

A new starter repository, platform-init, will act as the foundation for every Nimara project going forward. It's minimal, clean, and structured for real-life use cases.

You can easily add components or features based on your project’s needs:

• A Next.js Storefront, ready to be themed and extended
• A Stripe backend written in Python, modular and isolated
• A transparent DevOps layer with tools and deployment scaffolding

This structure eliminates configuration guesswork and lets you launch projects in minutes instead of days.

Repeatable Integrations with the Recipe System

One of the most significant pain points in headless development is redoing the same setups over and over. So, we created something we called recipes.

A Nimara recipe is a self-contained integration package that includes:

• Clear setup instructions (manual and CLI-compatible)
• Required environment variables
• Dependencies and connection logic
• Git visibility rules (for public/private modules)

We're actively rolling out recipes for Stripe, ButterCMS, Sailor Engine, and more to dramatically simplify the onboarding of new projects (and developers).

Planned for the Future: The Nimara CLI

We plan to build a command-line tool tailored for Nimara projects to turn these workflows into real automation.

Early features will include:

• nimara init: clone and prepare a clean project from platform-init
• nimara apply stripe: apply the Stripe backend recipe with all configs
• Version and submodule handling under the hood

This will be powered by JSON or YAML manifest files describing each component’s behavior, dependencies, and integration needs.

Why We’re Going Modular (and Forkable)

We’ve chosen to keep our architecture decentralized. Instead of a bloated monorepo, we fork individual components per project.

Why?

• It gives teams more control over update cycles;
• reduces regression risk from shared code;
• and keeps integration testing isolated and focused.

It’s a more sustainable way to scale when you’re building tailored solutions across multiple clients or teams.

Infrastructure, But Transparent

We're also formalizing deployment across Nimara modules. That means each component will include:

1. Terraform or Pulumi manifests
2. Environment configuration guidelines
3. Compatibility documentation

This ensures your infra isn’t a black box. You’ll know exactly what gets deployed and how.

Better ENV Management = Fewer Broken Setups

We’ve started embedding .env.example files and config validation into every recipe. For each environment variable, we also provide clear manuals on where to find the required values, so you’re never left guessing.

Eventually, the CLI will validate and set these up for you.

No more mystery bugs from missing variables. It's just a clean handoff from configuration to deployment.

Looking Ahead

You'll appreciate this shift if you've ever had to reverse-engineer someone else's dev environment just to get a storefront running.

Nimara is being shaped to:

• Remove hidden knowledge from the process,
• Encourage reuse across projects,
• Empower developers with predictable, scriptable workflows,
• And accelerate time to deployment.

Nimara is no longer just a storefront starter; it's becoming a complete framework for composable commerce. These updates are a step toward making composable commerce actually practical.

What’s Next?

Over the next few weeks, we’ll:

• Publish the nimara-recipes repository,
• Test full project lifecycles in real conditions (including postmortems),
• Begin documenting standard setups for Saleor, Stripe, and Storefront,
• Increase end-to-end test coverage by adding more automated tests to ensure reliability and stability.

Stay Tuned

In the coming weeks, we'll publish more guides, recipes, and tooling, as well as a starter repo you can clone and use immediately.

Until then, if you're curious about what we're doing, want early access, or have ideas of your own:

• Join our Discord
• Visit the site
• Follow us on GitHub

Let’s make e-commerce development faster, cleaner, and genuinely fun to work with.