Deploy Laravel to Your Own Server

How to deploy Laravel with Temps

Commands run on your machine unless they say otherwise. The CLI runs with bunx or npx.

1. 1

   Install Temps on a Linux server

   On a VPS with at least 2 CPU cores and 4 GB of RAM, download the installer, read it, then run it. It installs Docker if needed, the Temps binary and its database, and asks how the console is reached: an sslip.io address or your own domain.

   curl -fsSL https://temps.sh/deploy.sh -o deploy.sh
   less deploy.sh
   bash deploy.sh

2. 2

   Log in from your machine

   Point the CLI at your Temps console. It opens a browser to approve the login.

   bunx @temps-sdk/cli login https://console.example.com

3. 3

   Read the connection Temps injects

   Temps injects POSTGRES_URL, not DB_URL or DATABASE_URL. Point the pgsql connection at it and set DB_CONNECTION=pgsql.

   config/database.php

   'pgsql' => [
       'driver' => 'pgsql',
       'url' => env('POSTGRES_URL'),
       // ...keep the rest of the connection settings
   ],

4. 4

   Declare the PHP extensions you use

   Temps adds the PHP extensions listed as ext-* in the require section of composer.json to the image. Without ext-pdo_pgsql, pages that query PostgreSQL fail with "could not find driver"; phpredis, Laravel's default Redis client, needs ext-redis.

   composer require ext-pdo_pgsql:*
   composer require ext-redis:*   # only with a linked Redis

5. 5

   Commit your built assets (beta.56)

   beta.56 doesn't run a front-end build for PHP projects, and a page that uses @vite returns 500 without public/build/manifest.json. Build locally, take /public/build out of .gitignore and commit the folder, or deploy with your own Dockerfile. Nightly builds, and the next release, run your build script during the deploy.

   npm run build
   git add public/build

6. 6

   Trust the proxy

   Temps terminates HTTPS at its proxy, so trust forwarded headers or Laravel generates http:// URLs.

   bootstrap/app.php

   ->withMiddleware(function (Middleware $middleware) {
       $middleware->trustProxies(at: '*');
   })

7. 7

   Set APP_KEY and APP_URL

   Generate the key locally and store it as a project variable; never commit it.

   bunx @temps-sdk/cli environments vars set APP_KEY "$(php artisan key:generate --show)" -e production
   bunx @temps-sdk/cli environments vars set APP_URL "https://app.example.com" -e production

8. 8

   Point the health check at a path that doesn't need the database

   Before switching traffic, Temps probes / until it answers. On the first deploy the tables don't exist yet, so if / queries the database the deploy fails before you can migrate. Set health.path to /up in .temps.yaml. Laravel 11 and later register /up in bootstrap/app.php; on older versions, add a route that returns 200.

   .temps.yaml

   health:
     path: /up

9. 9

   Deploy Laravel

   From the project root, run up with the preset, or set it under Project → Settings → Build & deploy → Build → Framework. If the directory isn't linked to a project yet, up walks you through creating one first. For a project created from a Git repository, pushes to the tracked branch deploy automatically.

   bunx @temps-sdk/cli up --preset nixpacks-php

10. 10

    Create and link a PostgreSQL database

    Temps doesn't create a database for you. Create one, then link it to the project (or use Databases → Create database in the dashboard). Linking injects POSTGRES_URL plus POSTGRES_HOST, POSTGRES_PORT, POSTGRES_DB, POSTGRES_USER and POSTGRES_PASSWORD into the next deployment. It doesn't inject DATABASE_URL.

    bunx @temps-sdk/cli services create -t postgres -n my-laravel-app-db
    bunx @temps-sdk/cli services link --id <service-id> -p my-laravel-app

11. 11

    Run migrations after deploys that change the schema

    Temps doesn't run migrations and has no release phase. Find the running container, then run the migration in it over SSH, by hand or from CI right after the deploy step. Don't add it to the start command: restarts and replicas would run it more than once.

    bunx @temps-sdk/cli projects show -p my-laravel-app --json   # note the numeric "id"
    bunx @temps-sdk/cli containers list -p <project-id>     # note the container_name
    ssh your-server 'docker exec <container_name> php artisan migrate --force'

Production configuration for Laravel on Temps

# Set once per environment
bunx @temps-sdk/cli environments vars set APP_DEBUG false -e production
bunx @temps-sdk/cli environments vars set LOG_CHANNEL stderr -e production
bunx @temps-sdk/cli environments vars set DB_CONNECTION pgsql -e production

# With a linked Redis (REDIS_URL is injected)
bunx @temps-sdk/cli environments vars set CACHE_STORE redis -e production
bunx @temps-sdk/cli environments vars set SESSION_DRIVER redis -e production
bunx @temps-sdk/cli environments vars set QUEUE_CONNECTION redis -e production

// config/database.php — Laravel's default Redis connection
'redis' => [
    'client' => env('REDIS_CLIENT', 'phpredis'),
    'default' => [
        'url' => env('REDIS_URL'),
        // ...keep the rest of the connection settings
    ],
],

# With a linked managed S3 service: AWS_ACCESS_KEY_ID,
# AWS_SECRET_ACCESS_KEY and AWS_DEFAULT_REGION are injected for you.
bunx @temps-sdk/cli environments vars set FILESYSTEM_DISK s3 -e production
bunx @temps-sdk/cli environments vars set AWS_BUCKET my-uploads -e production
bunx @temps-sdk/cli environments vars set AWS_ENDPOINT "<the S3_ENDPOINT value>" -e production
bunx @temps-sdk/cli environments vars set AWS_USE_PATH_STYLE_ENDPOINT true -e production

Common Laravel deploy errors and fixes

The build stops with "Could not auto-detect project type from files".

A composer.json isn't a detection signal. Deploy with up --preset nixpacks-php, or set the framework under Project → Settings → Build & deploy → Build.

Every request returns 500: "No application encryption key has been specified".

APP_KEY is missing. Generate it locally with php artisan key:generate --show and set it as a project variable, a different key per environment.

Links, redirects and pagination use http://.

Temps terminates HTTPS at its proxy. Trust forwarded headers with $middleware->trustProxies(at: '*') in bootstrap/app.php, and set APP_URL to the https:// address.

Jobs are dispatched but never run.

Temps runs the web process only; worker:, scheduler: and horizon: Procfile lines are ignored. Run queue:work or Horizon as a service in a Docker Compose project, or outside Temps, against the same Redis.

Pages that query the database fail with "could not find driver".

The image has no pdo_pgsql extension, because composer.json doesn't ask for it. Run composer require ext-pdo_pgsql:*, commit composer.json and composer.lock, and deploy again.

Class "Redis" not found.

phpredis, Laravel's default Redis client, is a PHP extension that Temps only builds when composer.json lists it. Run composer require ext-redis:* and deploy again, or install the pure-PHP client with composer require predis/predis and set REDIS_CLIENT=predis.

Pages return 500 with "Vite manifest not found".

beta.56 doesn't build front-end assets for PHP projects. Commit public/build after npm run build, or build the assets in your own Dockerfile. Nightly builds, and the next release, run your build script.

Uploaded files vanish after a deploy, or /storage links return 404.

App containers have no persistent volume, so the public disk is wiped on each deploy. Store uploads on an S3 disk, as above.

Composer can't install a private package.

Set COMPOSER_AUTH as a project variable with the JSON credentials Composer expects, for example a GitHub token.

How Temps builds and runs Laravel

Every app runs in a Docker container on your server, behind the Temps proxy. Before traffic switches to a new deployment, Temps health-checks it; if the check fails, the deployment is marked failed and the current version keeps serving.

What works with Laravel on Temps

• FrankenPHP serving public/
• PHP extensions built from ext-* in composer.json
• Managed PostgreSQL and Redis you link
• Your own start command with a Procfile web: line
• Health check before each cutover
• Preview environments per branch (opt-in)

Managed services for Laravel

Temps runs these services on your server. Create one, link it to the project, and its connection variables reach the next deployment. Set up managed services.

Environment variables for Laravel

Set your own with environments vars set or in the project settings; values are encrypted at rest.

What it costs to self-host Laravel

Temps is free to self-host under MIT / Apache 2.0, with no per-seat fee and nothing metered, so hosting Laravel costs what the server costs. A Hetzner CX23 (2 shared vCPU, 4 GB RAM, 40 GB NVMe, 20 TB traffic) meets the minimum Temps needs and is €5.49/month excluding VAT, plus €0.50/month for an IPv4 address; Hetzner sells it in Germany and Finland only. Prices checked October 10, 2026.

For one to three production apps, the server guide recommends 4 vCPU and 8 GB RAM: a Hetzner CX33 is €8.49/month excluding VAT. Any Linux VPS that meets the minimum works; sizes and other providers are in Choosing a server. For what the same app costs on Heroku, see Temps vs Heroku.

Laravel on Temps: frequently asked questions

Included with every Temps project

Deployments, analytics, error tracking, session replay and uptime monitoring run in the same self-hosted platform, so your Laravel app doesn't need separate subscriptions for them.

Related guides

• Every setting for this stack is in the Laravel deployment reference.
• Which stacks are detected and which need a preset is listed in supported languages and frameworks.
• How health checks, cutover and rollbacks work is covered in Deployments.
• Moving off Heroku? Follow Migrate from Heroku.
• Comparing self-hosted platforms? See Temps vs Coolify.

Deploy another framework