Type-checked Laravel + React previews, per branch
Push a branch and get a real Laravel + React environment: tsc verifies your types, Vite builds the hashed bundle Laravel’s manifest expects, the database is migrated and seeded, and the whole stack runs on a managed VPS behind its own HTTPS URL. Inertia or decoupled SPA — both wire themselves up.
- ✓ Inertia React adapter
- ✓ tsc type-check gate
- ✓ shadcn / Radix / Tailwind
What we build on the frontend side
A React preview is more than booting PHP. We run your full Vite + TypeScript toolchain so the environment serves the exact production bundle — components, styles and all.
Vite production build
npm ci && npm run build compiles your TypeScript React tree into hashed JS/CSS and writes the Laravel Vite manifest — the same artifacts you’d ship to production.
Type-check before live
Slot a tsc --noEmit step into the pipeline. A type error fails the build, so a broken branch never reaches a reviewer — the URL only goes green on code that compiles.
Inertia adapter wired
Controllers return Inertia responses, the React adapter mounts your pages, and everything serves from one origin — shared props, CSRF and routing without an API base URL.
Component libraries baked in
shadcn/ui, Radix primitives and Tailwind all run through the same build. The preview serves your real design-system CSS and JS, not a stripped dev render.
A red type-check is a red environment
The point of TypeScript is to fail loudly before runtime. We make that part of provisioning: the build is the gate, so a preview that exists is a preview that compiled.
Type-check runs first. A renamed prop or a drifted API shape stops the build cold.
On a clean check, Vite emits the hashed bundle and manifest for Laravel to serve.
Only then does the environment go live on its HTTPS URL — never on broken types.
Your commands, run in a clean container
No CI YAML to babysit and no SSH. You list the steps; we run them on every push to the branch, in isolation, on the environment’s own VPS.
# on every push to the branch composer install --optimize-autoloader npm ci && npm run build # Vite + tsc → public/build + manifest php artisan migrate --seed # isolated DB, realistic data php artisan queue:work & php artisan schedule:work ✓ ready https://acme-dashboard-tsx.admn.cloud
Inertia or decoupled — both provision the same
However your frontend talks to Laravel, the environment wires the connective tissue so you don’t hand-edit config per preview.
Inertia React
One Laravel app, one origin. The React adapter renders pages from Inertia responses, optionally with a Node SSR pass for first paint. No CORS, no API token wiring.
- ✓ Single HTTPS origin
- ✓ Optional Inertia SSR (Node process)
- ✓ Shared props & CSRF out of the box
Decoupled Vite / CRA SPA
A standalone React SPA pointed at the Laravel API in the same environment. We inject the API URL and set Sanctum stateful domains + the CORS allow-list to the generated host.
- ✓
VITE_API_URLauto-set - ✓ Sanctum cookie auth wired
- ✓ CORS / preflight handled
Everything the backend needs, too
The React build is only half the story — the environment also stands up a complete, isolated Laravel runtime.
migrate --seed on boot, dropped on tear-down.queue:work and the scheduler run so jobs and cron-style tasks behave.APP_URL and a fresh APP_KEY set per environment.Laravel + React previews, answered
Does the build run a TypeScript type-check?
It can — and it should. Put `tsc --noEmit` (or `vue-tsc`-style `react` equivalents like `tsc -b`) right before `npm run build` in your declared commands. If types don’t check, the build fails and the environment never goes live, so reviewers only ever open a branch that actually compiled. Catching a bad prop or a renamed API field at build time is far cheaper than finding it in QA.
How does the Inertia React adapter fit in?
Inertia React is the default path. Your Laravel controllers return `Inertia::render(...)`, `@inertiajs/react` mounts the page components, and Vite compiles your `.tsx` into hashed assets that Laravel’s Vite manifest resolves. Because everything serves from one origin, you get shared props and CSRF for free — no API base URL, no token plumbing.
Can you run Inertia SSR for React?
Yes. Add your SSR build step (Vite emits a separate `ssr.js` bundle) and the serve command — typically `php artisan inertia:start-ssr`, which runs a small Node process. We keep that Node SSR process alongside PHP in the same environment, so first paint is server-rendered and the React tree hydrates on the client.
Are these React Server Components?
No — and this is a common mix-up. Inertia React is client-rendered React (optionally with the Node SSR pass above for the initial HTML); it is not React Server Components and there is no RSC streaming boundary. If you specifically need RSC, that lives in a Next.js app, which has its own preview page. Inertia gives you SPA-style React glued to Laravel routing without an RSC runtime.
Do shadcn/ui, Radix and Tailwind assets get built?
They do. Tailwind runs through its PostCSS/Vite pipeline during `npm run build`, and shadcn/ui components (which compile down to Radix primitives plus your local source) are just `.tsx` in your repo — they get bundled like any other component. The preview serves the same production CSS and JS your users would get, not a dev build.
What if my React app is a decoupled Vite/CRA SPA, not Inertia?
That works too. Declare both the Laravel API build and the SPA build; we serve the SPA and point it at the same environment’s API. Because they share one HTTPS origin on admn.cloud you usually avoid CORS entirely, but if you keep them split we wire `VITE_API_URL`, the Sanctum stateful domains and CORS allow-list to the generated URL so cookie auth and preflight requests just work.
Give every React PR a URL that actually compiled
$15/mo flat plus usage, 10 concurrent environments to start, unlimited projects and seats. Connect GitHub and let each branch build, type-check and tear down on its own.