ADMN
Laravel + Vue

Preview environments for Laravel + Vue

Every pull request gets a real, full-stack Laravel + Vue environment — Composer installed, Vite-built, database migrated and seeded, queues running — on a managed VPS, behind its own HTTPS URL. Open in minutes, torn down clean when the PR merges.

  • Inertia & SPA
  • Vite production build
  • Seeded MySQL / Postgres
Why it's painful today

A Laravel + Vue PR is two moving parts, not one

Reviewing a branch means standing up the PHP app and the compiled Vue frontend together — migrated, seeded, with the Vite manifest in place. Doing that by hand for every pull request is slow; sharing one staging box means whoever pushes last wins.

Vite builds drift from the backend

A reviewer pulls the branch, forgets npm run build, and sees stale assets against new routes — or a blank page because the manifest is missing.

Shared staging gets clobbered

Two open PRs, one staging database. Migrations and seeders from one branch quietly break the other; nobody trusts what they're looking at.

“Works on my machine”

Local PHP, Node and MySQL versions all differ. The bug a designer reports never reproduces because no two environments match.

One environment, fully wired

What every Laravel + Vue preview includes

Each branch boots a complete stack on its own VPS — backend, frontend build and backing services, wired together and served on one origin.

PHP + ComposerYour PHP version, composer install, app booted under a real web server.
Vite + Vue buildnpm ci then npm run build — hashed assets and the Laravel Vite manifest baked in.
Inertia, one originBackend and frontend served together — no separate API host, no CORS, shared props intact.
MySQL or PostgresIsolated per environment, migrate + seeders run on boot.
Redis + queue workerCache, sessions and a queue:work worker plus the scheduler.
HTTPS URL + envA real certificate, APP_URL and a fresh APP_KEY wired automatically.
The build, automated

Exactly the steps you'd run by hand

You declare the install, build and migrate commands once. We run them in a clean container on every push — no bespoke CI YAML, no SSH.

# on every push to the branch
composer install --optimize-autoloader
npm ci && npm run build              # Vite → public/build + manifest
php artisan migrate --seed   # isolated DB, realistic data
php artisan queue:work & php artisan schedule:work
✓ ready https://acme-checkout-v2.admn.cloud
How it works

From branch to shareable URL in three steps

  1. 01

    Connect the repo

    Point ADMN at your Laravel + Vue repository and declare your build commands and database template — once.

  2. 02

    Pick a branch

    Choose any branch or PR. We provision a dedicated VPS, build the frontend, migrate and seed the database, and start workers.

  3. 03

    Share the URL

    A real HTTPS environment for QA, design review or a client demo. Renew the lease to keep it, or let it expire and tear down clean.

Questions

Laravel + Vue preview environments, answered

Does it work with Inertia.js?

Yes — Inertia is the default assumption. Your Laravel routes return Inertia responses, Vite builds the Vue pages, and the whole thing serves from one origin, so there are no CORS hoops and shared props just work. Inertia SSR is supported too: add the SSR build/serve commands and we run the Node SSR process alongside PHP.

How is the Vue frontend built?

On every deploy we run your install and build steps in a container — typically `npm ci` (or pnpm/yarn) then `npm run build`, which runs Vite and emits the hashed assets Laravel’s Vite helper references. The compiled manifest ships with the environment, so the preview serves production-built assets, not a dev server.

What about the database — is it migrated and seeded?

Each environment gets its own isolated MySQL or PostgreSQL database. We run `php artisan migrate` and your seeders on first boot, so the preview opens on realistic data instead of an empty schema. Tear-down drops the database with the environment — no shared staging to clobber.

How are environment variables and APP_KEY handled?

Your project’s env template is rendered per environment: APP_URL is set to the generated HTTPS URL, a fresh APP_KEY is generated, and database/Redis credentials are injected to point at that environment’s own services. Secrets you define on the project are merged in.

Do queues and the scheduler run?

Yes. The same image runs a `queue:work` worker and the scheduler, so jobs, broadcasts and scheduled tasks behave like production. Redis is provisioned for cache, sessions and queues by default.

How long does a preview environment live?

As long as you need it. Each environment runs on its own auto-expiring lease you can renew or pin to a PR; idle ones tear down on their own so you never pay for an environment you forgot about.

Ship your next Laravel + Vue PR with a live URL

Connect GitHub and get a full-stack preview environment for every branch — built, migrated and seeded, then destroyed without a trace.