Frontend stacks
This page answers one question before you commit a team: can we build the frontend with the stack we already have? It states what runs on the platform today, what does not, and which rendering modes are supported. Nothing on this page is a roadmap item; see Today versus roadmap for how that line is drawn.
The short answer
| You want to | Supported today |
|---|---|
| Build a commerce storefront: catalog, cart, checkout, buyer accounts, pages editors compose | Nuxt 4 only, as a Theme that extends the @revenexx/cover layer |
| Host a web app that is not a storefront on the platform: a landing page, a documentation site, an app shell | Any of the fifteen JavaScript frameworks the platform builds, from Next.js and SvelteKit to plain static bundles |
| Run a server-rendered PHP, Java, .NET or Ruby frontend (Laravel, Symfony, Shopware storefront, Spring, Rails) on the platform | Not supported. The platform has no runtime for them. This is not a configuration gap; it is not a thing the platform does. |
| Keep a frontend on your own infrastructure and read platform data from it | Supported through the public API and its SDKs. It is a client of the platform, not a Site or a Theme. |
Reduced to a staffing decision:
- A team that works in Nuxt, Vue and TypeScript can build everything on this page.
- A team on another JavaScript framework can deploy and host on the platform, but a storefront Theme is Nuxt work.
- A PHP-only team cannot put a frontend on the platform. It either adds Nuxt skills, or keeps the frontend where it is and integrates over the API.
A single-page application is not required. See A single-page app is not required.
Storefront Themes are Nuxt 4
A Theme is the front end a Site runs: a Nuxt 4 application that extends the published base layer @revenexx/cover and is deployed with the ssr adapter. The base layer brings the storefront components, composables and server routes; Blökkli blocks, the units editors compose pages from, are Vue components; and the visual editor runs inside your Theme on a route the Theme serves. All three are Nuxt mechanisms, which is why the constraint is Nuxt and not "any Vue app".
What a Theme is built with today:
| Requirement | Version |
|---|---|
| Nuxt | 4.x (the scaffold pins ^4.2) |
| Vue | 3.5 or newer |
| Node.js | 22 or newer, on the node-22, node-24 or node-25 build runtime |
| Peer libraries the base layer expects | Nuxt UI 4, Pinia 3, vue-i18n 10 or 11 |
revenexx create theme writes a project on exactly these versions, and revenexx deploy theme builds it on the platform. The whole storefront runs locally with no credentials, because every commerce domain defaults to mocked data; see Experience Studio: getting started.
There is no Theme engine for any other framework. A React, Svelte or Angular storefront can be hosted as a Site (next section), but it does not get Blökkli pages, the theme marketplace, per-domain activation on a tenant, or the storefront components.
Sites build fifteen JavaScript frameworks
Independently of Themes, the platform builds and serves web apps in a range of JavaScript frameworks. It detects the framework, applies its install and build commands, and picks the rendering adapter from what the build produced.
| Adapter | Frameworks |
|---|---|
ssr and static | Nuxt, Next.js, SvelteKit, Angular, Astro, Remix, TanStack Start, Analog |
static only | React, Vue, Vite, Flutter (web), React Native (web), Lynx, and other for any static bundle |
The full matrix, with identifiers and detection rules, is on Frameworks. Every build runs on a Node runtime (node-22, node-24, node-25) or on static-1 for a build with no Node step at all; see Build configuration.
Use this path for the things around a storefront: a campaign microsite, a documentation site, a partner portal shell. For the storefront itself, use a Theme.
Not supported: server-rendered PHP and other non-Node stacks
There is no PHP, JVM, .NET or Ruby runtime on the platform. Concretely:
- A Laravel or Symfony application cannot be deployed as a Site or a Theme.
- An existing Shopware or Magento storefront cannot be moved onto the platform as-is.
- A .NET, Spring or Rails frontend cannot be deployed either.
None of these fail for a fixable reason such as a missing build command. The platform executes Node builds and Node servers, and serves static files. If your frontend is one of the above, your options are to rebuild it as a Nuxt Theme, or to keep hosting it yourself and make it an API client. Bring an existing frontend works through that decision.
A single-page app is not required
A Site renders one of two ways, and the choice is a property of the Site called the adapter:
| Adapter | HTML is produced | Fits |
|---|---|---|
ssr | On every request, by your server build | Storefronts. Prices, stock and the buyer's session are per-request facts, and the pages that earn money need to be indexable. |
static | Once, at build time | Landing pages, documentation, brochure sites, and single-page apps. |
A storefront Theme is ssr. Within an ssr Site you can still prerender routes that never change per buyer; Nuxt, Next.js, SvelteKit and Astro all mix prerendered and per-request routes, and the reference Theme does exactly that for its shell and catalog pages.
A single-page app is one option under static: it needs a fallback file so client-side routes resolve on reload. It is a valid way to deploy a non-storefront app, and the wrong way to build a storefront. Detail: Rendering, Static and Server-side rendering.
Keeping the frontend off the platform
The public API at api.revenexx.com is the same one Themes, Cockpit and integrations use, and it does not care what calls it. A frontend that stays on your own infrastructure, in any language, reads and writes tenant data by sending the tenant slug in X-Revenexx-Tenant and a server-side API key in X-Revenexx-Api-Key with each request. Typed clients exist for Web/JavaScript, Node and PHP; more are in development and listed on SDKs.
What you take on with that choice:
- Hosting, TLS, scaling and deploys are yours. Previews, instant rollbacks and platform-managed domains apply to Sites, not to external clients.
- Multi-tenancy is yours to resolve. A deployed Theme is told which tenant a request belongs to; an external frontend has to know.
- Page composition is not available. Blökkli pages, the visual editor and the theme marketplace exist only inside a Theme.
- The credential must stay server-side. Calls to the gateway go from your server, never from the browser. See API keys and API usage.
This is the right path when a frontend already exists, works, and cannot be rewritten now. It is the wrong path for a new storefront, where the Theme gives you the multi-tenant plumbing for free.
Skills to staff a storefront project
The honest list for a Theme:
- Nuxt 4 and Vue 3 with the composition API: layers, composables,
useFetch, and file-path shadowing to override what the base layer ships. - TypeScript throughout, including Nitro server routes, because every call to the gateway goes through your own
/api/*routes. - CSS custom properties, since branding per tenant is driven by design tokens rather than rebuilds.
- Useful and not mandatory: Pinia, FormKit for checkout forms, and vue-i18n, all of which the base layer already uses.
Business logic does not belong in the Theme. Pricing, validation and approvals live in an App, which is one Node function plus JSON contracts; see Apps and Sites. A team that covers Nuxt on the front and Node on the back can deliver a whole project. PHP is not needed anywhere in it.
Today versus roadmap
Everything described above as supported is available now and used by the scaffold the CLI produces.
There is no published roadmap for a PHP or other non-Node runtime on the platform, and none for storefront Themes in a framework other than Nuxt. Treat anything not listed as available on this page as unavailable, and do not plan a project around it changing. If it does, this page and the changelog will say so.
If your project depends on a stack that is not supported, say so in a request at support.revenexx.com with the stack and the timeline. That is the input that shapes what gets built next.
Where to go next
- Bring an existing frontend: what carries over from an existing shop, what is rebuilt, and how the move is scoped.
- Apps and Sites: where business logic lives and how a Theme reaches it.
- Experience Studio: getting started: a themed storefront on a preview URL in eight steps.
- Frameworks: the fifteen frameworks the platform builds, and how the adapter is detected.