One‑Repo Vite + Elysia Demo

Most Vercel projects make you pick a shape: a static front end on one URL, then an application programming interface on another URL or another project. This demo showed a third shape: a Vite site and an Elysia server living in one repository and answering from one Vercel deployment, with the server mounted under `/api/`. (vercel.com 1) (vercel.com 2) Vite is the part that builds the browser app. It turns your source files into static files like JavaScript, style sheets, and HTML that Vercel can serve quickly from its edge network. (vite.dev) (vercel.com) Elysia is the part that answers requests on the server. It is a TypeScript web framework that can export an app for Vercel Functions, so a request to `/api/hello` can run server code instead of returning a file. (vercel.com) (elysiajs.com) The trick is the URL split. Vercel can serve the built Vite app for normal page requests like `/` and `/about`, while requests that start with `/api/` get routed to the Elysia handler in the same deployment. (github.com) (vercel.com) That sounds small until you compare it with the usual hobby-project setup. A lot of small apps use `app.example.com` for the front end and `api.example.com` for the back end, which means two deployments, two environment setups, two local development flows, and one more place for cross-origin request bugs. (vercel.com) (vite.dev) Cross-origin request bugs are the browser errors you get when one website asks another website for data and the browser treats them as different origins. Putting both pieces on one origin avoids a whole class of configuration around Cross-Origin Resource Sharing, which is the browser permission system for those cross-site requests. (vite.dev) Vercel’s current docs make this pairing easier than it used to be. The company now has a dedicated Vite guide for the front end and a dedicated Elysia guide for the back end, and the Elysia guide says Vercel can detect an Elysia entry file and run it as a function. (vercel.com 1) (vercel.com 2) Elysia also has first-party documentation for Vercel. Its docs say Vercel Functions support web-standard frameworks by default, which is why an Elysia app can sit behind `/api/` without a separate server machine running all the time. (elysiajs.com) This does not turn Vercel into a giant all-in-one server for every workload. Vercel Functions still have the tradeoffs of function platforms, so long-running jobs, WebSocket-heavy apps, and stateful back ends may still fit better on a dedicated server or another platform. (vercel.com) For portfolio sites, internal tools, and weekend products, though, the appeal is obvious. One Git repository can hold the Vite client, one Elysia app can answer `/api/`, and one deployment URL can demo the whole product without asking anyone to remember a second hostname. (vercel.com 1) (vercel.com 2)