Vercel: Vite + Elysia Deploys
Vercel rolled out an update that lets projects with a Vite frontend and an Elysia backend deploy from the same folder and serve the API at /api/, simplifying monorepo DX and deployment surface. That change reduces friction for small services and micro‑apps by standardizing routing and deployment layout in one repo. For internal libraries and platform teams, it’s a small but practical improvement to build‑and‑deploy ergonomics. (x.com)
A Vite app is the part users see in the browser, and an Elysia app is the part that answers requests like “save this form” or “look up this record.” Until now, putting both in one Vercel project usually meant extra folder rules, custom rewrites, or splitting the frontend and backend into separate deployments. (vite.dev, vercel.com) Vercel’s new change is that a Vite frontend and an Elysia backend can now live in the same folder and deploy together, with the backend automatically served from `/api/`. That turns one repository into one deployment shape, instead of a frontend app plus a second service that has to be wired in by hand. (vercel.com, vercel.com) Vite is a frontend build tool that takes browser code and turns it into production files like JavaScript bundles and static assets. Its own docs describe it as a fast development server plus a build command, which is why teams often use it for React, Vue, Svelte, and Preact apps. (vercel.com, vite.dev) Elysia is a backend web framework built for TypeScript, with routing for things like `GET /users` and `POST /login`. Vercel added automatic Elysia detection in November 2025, so an Elysia server can already deploy with zero configuration when Vercel sees the right entry file. (vercel.com, vercel.com) The awkward part was the seam between the two. Vite expects to build frontend assets, while Vercel Functions expect backend entrypoints, so combining them often pushed developers toward monorepo plumbing, rewrite rules, or a dedicated `api` layout that was easy to get wrong. (vite.dev, vercel.com) Standardizing the backend at `/api/` fixes the routing question in one stroke. A browser request for `/api/users` now has one obvious destination, while everything else can stay with the Vite app’s static files and client-side routes. (vercel.com, vite.dev) That is especially useful for small internal tools, admin panels, and micro-apps that need one page of user interface and a handful of endpoints. Instead of managing two repositories, two preview URLs, or a proxy between ports, a team can keep the form and the handler next to each other and ship them with one `vc deploy` flow. (vercel.com, vercel.com) It also lines up with how Vercel already handles previews. Every deployment gets its own URL, so when the frontend and backend ship as one unit, a pull request can test the exact browser code and the exact `/api/` behavior together instead of stitching two environments together by branch name. (vercel.com, vercel.com) This is not a giant platform reset. It is a packaging change: Vite still builds the frontend, Elysia still handles requests, and Vercel Functions still run the backend code, but the default project shape is now closer to how small full-stack apps are actually written. (vercel.com, vercel.com, vercel.com) For platform teams, the payoff is less policy and fewer exceptions. When every tiny dashboard and internal service can use the same “frontend here, backend at `/api/`” layout, templates get simpler, onboarding gets shorter, and there is less custom deployment glue to debug six months later. (vercel.com, vercel.com)
