All posts
laravelpreview-environmentspreview-urlstaging-environmentquickstart

Laravel preview environments: a live URL for every branch

PreviewDrop Team·August 17, 2026·6 min read

Your Laravel PR passed CI, but the reviewer can't actually see it. They'd have to pull the branch, run composer install, set up the database, run php artisan migrate, and hope their local .env matches yours. So the review becomes a code read instead of a click. The bug that only shows up when the queue worker hits a real database ships to production.

PreviewDrop fixes this with one thing: a live, isolated URL for every Laravel branch. Push, and the pull request gets a comment with a working link. No CI YAML, no Bref adapters, no shared staging server that everyone fights over.

The problem with "just use a staging server"

Most Laravel teams have a single shared staging environment. It works until two features land on it at once. One developer's half-finished migration breaks the other's demo. The database is in a state nobody can reproduce. You end up merging blind because "staging was down" or "someone else was on it."

The alternative — spinning up a fresh environment by hand — takes 20 minutes of yak-shaving for a 30-second review. That's why preview environments exist, and why platforms like Laravel Cloud and Vercel build them into the workflow. The catch is that Laravel Cloud ties you to its own hosting, and Vercel's serverless runtime runs Node.js, not PHP. Laravel on Vercel means Bref + Lambda, which drops queue workers, scheduled jobs, and long-running requests.

PreviewDrop takes a different route: it runs your actual Dockerfile. PHP, queues, storage — the full Laravel stack, not an adapter.

Set it up in under five minutes

You need a Dockerfile, a connected repo, and one push. That's it.

1. Add a Dockerfile

PreviewDrop detects Laravel from your composer.json, but a Dockerfile gives you full control over the build. Here's a minimal one:

FROM php:8.3-cli

RUN apt-get update -qq && apt-get install -y unzip git libpq-dev \
    && docker-php-ext-install pdo pdo_pgsql \
    && rm -rf /var/lib/apt/lists/*
RUN curl -sS https://getcomposer.org/installer | php -- \
    --install-dir=/usr/local/bin --filename=composer

WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-interaction

COPY . .

EXPOSE 8000
CMD sh -c "php artisan migrate --force && php artisan serve --host=0.0.0.0 --port=\${PORT:-8000}"

The CMD runs artisan migrate --force before serving, so your preview database is always at the schema your branch expects.

2. Set the one variable Laravel won't start without

Laravel refuses to boot without APP_KEY. Generate one and add it to your project's variables:

php artisan key:generate --show

Paste the output into the PreviewDrop project variables as APP_KEY. Use a dedicated key for previews — never reuse your production key. Add APP_ENV=staging and your DB_CONNECTION to match your database type.

3. Push and share the link

git push origin feature/my-branch

PreviewDrop detects the push, builds the image, runs your migrations, and posts a TLS-terminated preview URL to the pull request. Your reviewer clicks, sees the real feature against a real database, and leaves feedback. No local setup, no "works on my machine."

What you get that a shared server can't give you

Each preview is an isolated container with its own database. Two developers can push two features at the same time and review both, independently. When you merge or close the branch, the preview self-destructs — no zombie environments piling up on a server you pay for.

Previews also expire on a timer. The Free plan keeps previews alive for 4 hours, Starter for 24, Pro for 3 days, and Team for 7. That's long enough for a review cycle and short enough that you're never paying to host a branch nobody's looked at in a week.

Honest limits

Preview environments are for review, not production. php artisan serve is PHP's built-in server — fine for a handful of reviewers, but you'd swap it for Octane or nginx + php-fpm in production. And a preview database is disposable: don't point it at anything you can't afford to lose.

If you're already on Laravel Cloud and it's working, keep it. But if your team is on shared staging, or you've been fighting Bref adapters to get Laravel onto a serverless platform, a Dockerfile-based preview is the lowest-friction path to "review with a click, not a code read."

Want a live URL for your next Laravel branch? Create a free account — 2 concurrent previews and 3 projects, no credit card required.

Ready to give every branch a live URL?

Free tier — 2 concurrent previews, no credit card required.

Start free