Thirty-two designs across eleven trades, on your domain, carrying your branding, running on your server. No platform fee, no revenue share, no cut of every order. And it is pointed at your Ragenaizer books with a single API key, so each sale writes a GST-correct invoice and a balanced ledger entry as it happens.
Pick your trade, pick a look, launch it. It installs like an app as well — a progressive web app your customers add to the home screen on Android or iOS, carrying your brand, with no app store in the way.
Not one template in thirty-two colours. Each design is built around the way its trade is actually shopped — a grocery store is search-first and dense, a jeweller is a full-bleed spotlight, a wholesaler needs price breaks on the row. Different hero, different signature section, different typeface and card treatment.
Every design is free, and you can switch between them after launch without rebuilding the shop — the catalogue, orders and customers stay where they are. These are layouts for your own shop: “Marketplace & deals” is the look of an everything-store, not multi-vendor selling — there is one seller, and it is you.
The thirty-two designs are presets, not a ceiling. The storefront that ships is one consumer of a documented HTTP API, and it holds no privileged access — so a developer can replace it entirely with React, Vue, Svelte, Flutter or a native app, and keep every part that is hard: the GST-correct invoices, the FIFO stock, the books.
/api/openapi.json with a browsable page at /api/docs — on your domain, not ours. Load it into Postman, Insomnia or a code generator and start. It is generated from the routes themselves, so it cannot drift from what the server actually does.
Authorization header, with a shopper role and an admin role. No session affinity, no cookie dance, no CSRF ceremony — a phone app authenticates the same way a browser does.
This does not make the store open source — the application still ships as prebuilt images, and the answer to “do I get the source?” below is still no. It makes the front end yours.
On the usual setup the store is one system and the books are another. You bolt on a tax app, export to Tally, and count stock by hand to find out which of the two was right. Here the store is the accounting system, which is the one thing that cannot be retrofitted onto an incumbent.
Most trades get three presets built on the homepage structure that suits how people shop them — a grocery store is search-first and dense, a jewellery store is a full-bleed spotlight, an electronics store leads with a deals rail. Pick one and tune the palette, type and corner radius; the structure is what changes between them.
3 looks — editorial split hero.
3 looks — editorial split hero and search-first market grid.
3 looks — full-bleed spotlight.
3 looks — deals rail and full-bleed spotlight.
3 looks — search-first market grid.
3 looks — editorial split hero and full-bleed spotlight.
4 looks — full-bleed spotlight.
3 looks — editorial split hero and search-first market grid.
3 looks — full-bleed spotlight.
3 looks — editorial split hero and search-first market grid.
1 look — search-first market grid.
The swatch is the preset’s own primary colour. Every one of these is a starting point rather than a cage — colours, fonts and radius are yours to change once you pick.
Assessed against the shipped build. Shopify and WooCommerce are marked Partial where a capability needs a paid tier, a first-party app or a third-party plugin — and we are marked the same way, or crossed out, wherever that is the truth. Where our answer is one named integration rather than a choice of many, the table says which one.
| Shopify | WooCommerce | Merch | |
|---|---|---|---|
| Core commerce | |||
| Catalog, variants and search | ✓ | ✓ | ✓ |
| Collections, manual and smart | ✓ | Partial | ✓ |
| Cart and checkout, COD and online | ✓ | ✓ | ✓ |
| Discounts and promotions | |||
| Coupon codes with caps, limits and expiry | ✓ | ✓ | ✓ |
| Automatic discounts and customer segments | ✓ | Partial | ✓ |
| Buy-X-get-Y | ✓ | Partial | ✓ |
| Free-shipping discounts | ✓ | ✓ | ✓ |
| Gift cards, tracked as a liability | Partial | Partial | ✓ |
| Fulfilment and operations | |||
| Fulfilment, tracking and timeline | ✓ | ✓ | ✓ |
| Returns and RMA, as credit notes | Partial | Partial | ✓ |
| Shipping zones and rate rules | ✓ | ✓ | ✓ |
| Courier and 3PL integration | ✓ | Partial | Shiprocket |
| Selling models | |||
| Subscriptions and recurring orders | Partial | Partial | ✓ |
| Digital products and course access | ✓ | ✓ | ✓ |
| Wholesale and B2B price lists | Partial | Partial | Partial |
| Customers and marketing | |||
| Accounts and order history | ✓ | ✓ | ✓ |
| Wishlist and reviews | Partial | ✓ | ✓ |
| Abandoned-cart recovery | ✓ | Partial | ✓ |
| Meta Pixel, CAPI and UTM capture | ✓ | Partial | ✓ |
| Email campaigns and automations | ✓ | Partial | ✗ |
| SEO depth and analytics | ✓ | ✓ | Partial |
| Store and platform | |||
| Themes, count and quality | ✓ | ✓ | ✓ |
| Visual drag-and-drop editor | ✓ | Partial | Partial |
| PWA, installable on a phone | Partial | Partial | ✓ |
| Multi-language, including RTL | ✓ | Partial | Partial |
| Self-hostable, own your data | ✗ | ✓ | ✓ |
| App and plugin ecosystem | ✓ | ✓ | ✗ |
| Multi-channel selling | ✓ | Partial | ✗ |
| Payments, tax and books | |||
| Accounting-native, GL and invoices | ✗ | ✗ | ✓ |
| Inventory tied to the ledger | Partial | Partial | ✓ |
| GST and India tax compliance | Partial | Partial | ✓ |
| Payment-gateway breadth | ✓ | ✓ | Razorpay |
| Multi-currency | ✓ | Partial | ✓ |
| Built-in POS | ✓ | Partial | ✓ |
The core commerce loop is complete: catalogue, cart, checkout, discounts, fulfilment, returns, subscriptions and digital goods are all shipped. What we do not have is breadth — an app marketplace, multi-channel selling, an email-campaign suite, gateways beyond Razorpay and couriers beyond Shiprocket. The storefront API softens that for anyone with a developer: a custom front end or an outside integration is buildable. It does not replace an app store, though — that is a build, not an install. If you want to click Install on a loyalty app this afternoon, an incumbent is the honest answer today.
The e-commerce platform is free and you host it yourself. There is no transaction fee, no per-app subscription and nothing metered — the parts that are usually sold as add-ons elsewhere, like returns, subscriptions and gift cards, are simply in it. What you need is a Ragenaizer licence, because the books it posts into are the Accounts module.
One storefront API key, generated in Ragenaizer under Settings. The store's backend holds it and calls Ragenaizer over the network; the browser never sees it, and it is stored encrypted along with your payment and shipping secrets. Point it at your tenant and the catalogue, stock and prices are the ones your accounts already have.
That an order is not an event you reconcile later. Placing one writes a GST-correct invoice and a balanced general-ledger entry, moves stock on FIFO, and — for a return — issues a credit note rather than an informal refund note. A gift card is carried as a liability until it is redeemed, because that is what it is. There is no export, no nightly sync and no second system holding a different number.
Thirty-two presets across eleven retail verticals, built on four genuinely different homepage structures — an editorial split hero, a full-bleed spotlight, a search-first market grid, and a deals layout with a promo rail. Grid density, card shape and typography change with the structure, not just the palette. What it is not is a drag-and-drop builder; you are picking and tuning a preset.
It is a progressive web app, so a customer installs it from the browser on Android or iOS and there is no app-store build, review or release to manage. The manifest is generated from your theme, so the icon, name, splash and colours are yours — the installed app is your brand, not ours.
Breadth, and we would rather say it here than let you find out later. There is no app marketplace, no multi-channel selling into marketplaces and social, and no email-campaign suite. Payments are Razorpay today and couriers are Shiprocket. Tax is Indian GST. Those are real gaps for some businesses and none at all for others, which is why the table above marks them rather than omitting them. The documented storefront API changes what the first gap costs you — a developer can build a custom front end or wire in an outside service — but it is a build rather than an install, so it helps a team with engineering and not a merchant who wants to click Install this afternoon.
Not today, and it is worth being precise about that. What is public is the deployment — the install script, the compose file and the reverse-proxy config are on GitHub and yours to read and change. The store itself ships as prebuilt container images, so you run it on your own server, on your own domain, holding your own data and secrets, but the application source is not published. "Self-hosted" here means you own the infrastructure, not that you own the codebase. You can, however, replace the entire front end — see the next answer.
Yes. The storefront that ships is one consumer of a documented HTTP API and holds no privileged access, so anything it does, your own front end can do — in React, Vue, Svelte, Flutter or a native app. Your store serves an OpenAPI document at /api/openapi.json and a browsable page at /api/docs, on your own domain; authentication is a bearer JWT with a shopper role and an admin role. What is published is the storefront surface — catalogue, cart, checkout, accounts, wishlist, reviews, returns, subscriptions. Administering the shop stays with the bundled admin panel, and the API the store uses to reach your books is internal and never public, so your front end never handles a Ragenaizer key. The full endpoint list, with descriptions and request and response shapes, is on the Merch API reference — and you do not have to start from nothing: a complete starter storefront is on GitHub under an MIT licence, in plain HTML, CSS and JavaScript with no framework and no build step, so a team that knows only those three can clone it, point one line at your shop and have a working shop front the same afternoon.
Run the installer without a key and it boots a demo store with sample products and an admin login, so you can walk the whole thing — catalogue, checkout, discounts, returns — before you point it at a real tenant.
Any Linux box with Docker. The installer asks for your domain and your storefront API key, generates its own secrets, pulls the images and brings everything up behind automatic HTTPS.
| Install | |
curl -fsSL https://raw.githubusercontent.com/Abhi-hyperscripts/ragenaizer-commerce/main/install.sh | bash | |
| What it needs | |
| A domain | Its A record pointing at the server, so a certificate can be issued |
| Ports 80 and 443 | Open to the internet |
| A storefront API key | Ragenaizer → Settings → API Keys → Generate storefront key |
| What it brings up | |
| Caddy | HTTPS reverse proxy — the only thing exposed to the internet |
| Store and admin | Prebuilt images; nothing to compile |
| Postgres | Shopper accounts, carts and theme only — never accounting data |
| Redis | A disposable short-lived cache of catalogue, stock and price |
| Watchtower | Optional automatic updates |
Leave the API key blank on the first run and it boots a demo store with sample products and an admin login, so you can walk the whole flow before pointing it at real books. The install script, the compose file and the proxy config are public on GitHub.
Free to run, yours to host, and already speaking to your books.
The store is free and self-hosted; what it needs is a Ragenaizer tenant to post into, because the invoices, the stock and the returns belong to the Accounts module. That is the whole trade: you run the shop, the business OS keeps the books, and neither has to be told what the other did.