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

Environnement local Docker Compose
Image Docker multi-stage optimisée production
Pipeline CI (tests + build)
Déploiement via Coolify avec variables d’environnement
Stratégie de migration et de cache côté Laravel
Procédure de rollback testable
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:

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

Étape 7 — Déployer sur Coolify

Dans Coolify:

Créer une Application
Connecter source (repo ou registry)
Définir variables d’environnement
Configurer domaine + SSL
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:

Détection incident
Gel des déploiements
Retour à l’image stable précédente (tag SHA)
Vérification health check + parcours critiques
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:

branche par fonctionnalité
PR avec checks obligatoires
merge squash vers main
build image versionnée
déploiement staging automatique
smoke tests
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

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