Tutoriel 2026: Déployer Laravel + Vue avec Docker, GitHub Actions et Coolify

Vous savez coder en Laravel + Vue, mais la mise en production reste stressante ?

Ce guide est conçu pour transformer votre déploiement en processus fiable: testable, traçable et réversible.

Nous allons construire un pipeline moderne avec:

• Laravel 12 pour la logique backend
• Vue 3 + Vite pour le frontend
• Docker pour standardiser les environnements
• GitHub Actions pour automatiser les contrôles qualité
• Coolify pour déployer simplement sur votre serveur

Objectif final: chaque push est contrôlé, chaque release est reproductible, et chaque incident dispose d’un plan de rollback clair.

Niveau de difficulté

Intermédiaire — vous devez connaître les bases de Laravel, Vue et Git.

Ce que vous allez mettre en place

1. Environnement local Docker Compose
2. Image Docker multi-stage optimisée production
3. Pipeline CI (tests + build)
4. Déploiement via Coolify avec variables d’environnement
5. Stratégie de migration et de cache côté Laravel
6. Procédure de rollback testable
7. Socle d’observabilité pour petite équipe

Prérequis

Assurez-vous d’avoir:

• Un repo GitHub contenant votre projet Laravel + Vue
• Docker Desktop / Docker Engine (24+)
• Node.js 20+
• Un VPS avec Docker
• Une instance Coolify opérationnelle
• (Optionnel) un domaine configuré

Versions recommandées:

• PHP 8.3
• Laravel 12
• Vue 3
• Vite 6
• PostgreSQL 16
• Redis 7

Étape 1 — Préparer la structure du projet pour la conteneurisation

Arborescence type:

.
├── app/
├── bootstrap/
├── config/
├── database/
├── public/
├── resources/
├── routes/
├── storage/
├── tests/
├── composer.json
├── package.json
└── vite.config.js

Ajoutez à la racine:

• .dockerignore
• Dockerfile
• docker-compose.yml
• dossier docker/ (nginx, supervisor, entrypoint)

Exemple .dockerignore:

.git
.github
node_modules
vendor
storage/logs
storage/framework/cache
storage/framework/sessions
storage/framework/views
.env
.env.*

Pourquoi c’est essentiel: moins de contexte envoyé au build = build plus rapide et moins coûteux en CI.

⚠️ Attention: ne jamais embarquer de secrets dans l’image Docker. Les secrets doivent être injectés au runtime.

Étape 2 — Créer un Dockerfile multi-stage propre

Le principe: construire ce qui est lourd (assets, vendor) dans des étapes dédiées, puis livrer une image finale légère.

# syntax=docker/dockerfile:1.7
 
FROM node:20-alpine AS frontend_builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY resources ./resources
COPY vite.config.* ./
COPY public ./public
RUN npm run build
 
FROM composer:2.8 AS php_vendor
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader --no-interaction
 
FROM php:8.3-fpm-alpine AS app
RUN apk add --no-cache nginx supervisor postgresql-dev icu-dev libzip-dev oniguruma-dev
RUN docker-php-ext-install pdo pdo_pgsql mbstring intl zip opcache
 
WORKDIR /var/www/html
COPY . .
COPY --from=php_vendor /app/vendor ./vendor
COPY --from=frontend_builder /app/public/build ./public/build
 
RUN chown -R www-data:www-data storage bootstrap/cache
RUN chmod -R 775 storage bootstrap/cache
 
COPY docker/nginx.conf /etc/nginx/http.d/default.conf
COPY docker/supervisord.conf /etc/supervisord.conf
 
EXPOSE 80
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisord.conf"]

💡 Conseil: une image déterministe réduit énormément les surprises entre staging et production.

Étape 3 — Monter l’environnement local avec Docker Compose

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:80"
    env_file:
      - .env
    depends_on:
      - db
      - redis
    volumes:
      - ./:/var/www/html
 
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: noqta
      POSTGRES_USER: noqta
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
 
  redis:
    image: redis:7-alpine
 
volumes:
  pgdata:

Commandes de démarrage:

docker compose up -d --build
docker compose exec app php artisan key:generate
docker compose exec app php artisan migrate
docker compose exec app php artisan test

Règle simple: ce qui n’est pas fiable en local ne sera pas fiable en CI.

🚀 Vous voulez industrialiser ce flux dans votre contexte métier? L’équipe API Integration de Noqta peut vous accompagner sur l’architecture et l’exécution.

Étape 4 — Sécuriser la configuration Laravel pour la production

Variables critiques:

APP_ENV=production
APP_DEBUG=false
LOG_LEVEL=info
QUEUE_CONNECTION=redis
CACHE_STORE=redis
SESSION_DRIVER=redis
DB_CONNECTION=pgsql

Script d’entrée recommandé (docker/entrypoint.sh):

#!/usr/bin/env bash
set -e
 
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan migrate --force
 
exec "$@"

⚠️ Attention migrations: les migrations destructives (drop/rename agressif) ne doivent pas être exécutées sans stratégie progressive.

Étape 5 — Construire un pipeline CI crédible dans GitHub Actions

Le workflow CI doit couvrir au minimum:

• installation dépendances PHP/JS
• build frontend
• migration base de test
• exécution des tests

Exemple:

name: CI
on:
  pull_request:
  push:
    branches: ["main"]
 
jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: testdb
      redis:
        image: redis:7
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install --no-interaction --prefer-dist
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build
      - run: cp .env.example .env && php artisan key:generate
      - run: php artisan migrate --force
      - run: php artisan test --parallel

Améliorations utiles:

• Pint + Larastan
• ESLint / Type check
• Scan vulnérabilités (Trivy)

Le vrai gain business est ici: vous réduisez les erreurs humaines avant même le déploiement.

Étape 6 — Construire et publier l’image versionnée

Utilisez un second workflow pour builder et pousser l’image (GHCR), avec deux tags:

• latest
• sha-<commit>

Avantages:

1. traçabilité complète
2. rollback rapide
3. promotion de la même image entre environnements

Étape 7 — Déployer sur Coolify

Dans Coolify:

1. Créer une Application
2. Connecter source (repo ou registry)
3. Définir variables d’environnement
4. Configurer domaine + SSL
5. Activer health checks

Endpoint santé Laravel:

Route::get('/up', fn () => response()->json(['status' => 'ok', 'time' => now()]));

Paramètres conseillés:

• path: /up
• retries: 5
• timeout: 10s
• auto deploy sur main

💡 Conseil: gardez un environnement staging pour valider les releases avant production.

Étape 8 — Checklist de durcissement avant mise en ligne

Sécurité applicative

• APP_DEBUG=false
• CORS strict
• limitation de débit sur auth
• cookies sécurisés + HTTPS

Infrastructure

• sauvegardes DB quotidiennes
• firewall minimal
• principe du moindre privilège

Exploitation

• workers queue supervisés
• alertes jobs en échec
• centralisation des logs

Performance

• OPcache activé
• Redis réellement utilisé
• caches Laravel activés

Étape 9 — Procédure de rollback réellement opérationnelle

Beaucoup d’équipes en parlent, peu la testent.

Procédure recommandée:

1. Détection incident
2. Gel des déploiements
3. Retour à l’image stable précédente (tag SHA)
4. Vérification health check + parcours critiques
5. Rédaction postmortem avec actions correctives

Côté base de données:

• évitez les migrations non réversibles
• utilisez des feature flags
• conservez la compatibilité de schéma sur un cycle de release

⚠️ Rappel: rollback code facile, rollback data complexe. Concevez vos migrations en conséquence.

💡 Besoin d’un partenaire pour fiabiliser votre delivery technique de bout en bout? Noqta Web Development prend en charge architecture, implémentation et exploitation.

Étape 10 — Observabilité minimale, impact maximal

Indicateurs essentiels:

• latence p95
• taux d’erreurs 5xx
• backlog queue
• saturation DB
• fréquence/échec des déploiements

Stack simple:

• Uptime Kuma (disponibilité)
• Grafana + Loki (logs)
• alerting Telegram/Slack

Exemple de log structuré Laravel:

Log::info('checkout_completed', [
  'order_id' => $order->id,
  'user_id' => $order->user_id,
  'total' => $order->total,
]);

Les logs structurés réduisent fortement le temps de diagnostic.

Étape 11 — Erreurs fréquentes (et correctifs)

1) Build frontend sur serveur de prod

• problème: déploiements lents et fragiles
• solution: build en CI uniquement

2) Pas de health checks

• problème: version cassée exposée aux utilisateurs
• solution: gate de santé avant routage

3) Workers non supervisés

• problème: jobs bloqués silencieusement
• solution: supervisor ou service worker dédié

4) État mutable dans le conteneur

• problème: incohérences au scaling
• solution: externaliser l’état (DB/Redis/Object Storage)

5) Pas de staging

• problème: prod = environnement de test
• solution: staging proche de la prod

Étape 12 — Workflow d’équipe recommandé

Workflow efficace pour PME produit:

1. branche par fonctionnalité
2. PR avec checks obligatoires
3. merge squash vers main
4. build image versionnée
5. déploiement staging automatique
6. smoke tests
7. promotion de la même image vers production

Résultat: plus de visibilité, moins d’improvisation, meilleure fiabilité globale.

Résumé final

Avec ce pipeline Laravel + Vue:

• Docker standardise votre runtime
• GitHub Actions sécurise la qualité avant release
• Coolify simplifie le déploiement self-hosted
• Les health checks et le rollback réduisent le risque opérationnel
• L’observabilité transforme les incidents en processus maîtrisés

Si vous devez commencer petit: mettez d’abord la CI.
Deuxième étape prioritaire: déploiement par images immuables versionnées.

Check final

• Environnement local conteneurisé
• Image production multi-stage
• CI automatisée
• Déploiement Coolify
• Hardening sécurité/performance
• Rollback + monitoring

Construisez une fois, déployez proprement, itérez sereinement.