Your Vue framework should not choose your backend.

Runable gives Vue applications the structure of a meta-framework while leaving HTTP, APIs, and infrastructure in your hands.

Vue 3SSRFile routingAny HTTP server

Request flow

Your server

Fastify · Hono · Express

Application layer

Runable

RouteRenderHydrate

Interface

Vue application

The problem

A productive frontend often comes with an architectural decision attached.

Vue is deliberately flexible. As a project grows, teams add page routing, layouts, middleware, server rendering, hydration, data loading, plugins, and their own folder conventions.

Meta-frameworks solve that integration work brilliantly. The trade-off is that their server layer becomes part of your architecture—even when Fastify, NestJS, AdonisJS, Express, Hono, or an internal platform is the better backend.

Option A

Assemble Vue yourself

Keep complete server control, then select and connect routing, SSR, data loading, middleware, layouts, and application conventions yourself.

Option B

Split the application

Run a separate meta-framework frontend and backend, then accept two projects, two deployments, and a larger integration surface.

The third way

Runable separates Vue conventions from the HTTP runtime.

Your backend keeps ownership of HTTP, APIs, authentication, and business logic. A small adapter forwards interface requests to Runable, which renders the Vue application.

01HTTP request reaches your backend

02API routes stay under backend control

03Runable renders the Vue interface

When Runable fits

Choose Runable when your backend is a deliberate choice, not an implementation detail.

You already have a backend that your team trusts.
Your server framework provides architecture or plugins you need.
You want SSR and framework conventions without a prescribed runtime.
You want the frontend and backend to remain one coherent application.