Services

L’onglet Services (V) branche sur le projet les services de Joppa : PostgreSQL, MySQL, Redis, Mailpit, Meilisearch… Son compteur indique combien de services sont liés. Un clic suffit : les variables du service vont dans le .env, après un diff, et suivent son port.

Services ou processus

Sous l’intro, l’onglet le rappelle : « Les services sont partagés par Joppa entre vos projets (base de données, cache, mail). Ce que le projet lance lui-même est dans Processus. » (Voir les processus).

• Un service Joppa tourne une fois pour tous vos projets ; chaque projet y a sa base. Il se crée depuis la page Services et se branche ici.
• Un processus appartient au projet : ses serveurs de dev, ses workers, ses conteneurs Docker Compose. Il se gère dans l’onglet Processus.

Les services liés démarrent en premier avec « Tout démarrer », avant les processus du projet.

Brancher un service

Le bloc des services liste ceux de Joppa. Utiliser PostgreSQL (ou Redis, Mailpit…) ouvre un diff avec deux choix :

• Lier et écrire dans .env : les variables du service sont écrites, et tenues à jour si son port change.
• Lier sans écrire : Joppa retient le lien, sans toucher au fichier.

Un service branché démarre aussitôt s’il était arrêté, y compris quand vous acceptez les services devinés à l’ajout d’un projet. Pour une base de données, si la base du projet n’existe pas encore, Joppa la crée : la ligne du service annonce « Base {nom}, créée à l’activation », puis, une fois branché, un sélecteur permet de passer à une autre base du service ; si la base choisie n’existe pas dans le service, Créer la crée. Les listes de bases (page du service, base de test) se mettent à jour dès qu’une base est créée. Un projet n’utilise qu’un service de chaque type : brancher MySQL remplace PostgreSQL.

Ne plus utiliser… fait l’inverse : Délier et nettoyer le .env remet la valeur de .env.example (ou retire la variable), Délier sans toucher au .env garde le fichier tel quel. Les variables que vous avez modifiées à la main sont gardées.

Le branchement écrit dans le .env : si l’éditeur du .env (onglet Environnement) a des modifications non enregistrées, les interrupteurs sont désactivés (« Enregistrez ou annulez d’abord les modifications du .env »).

Sous quels noms

Joppa écrit sous les noms que le projet lit déjà : ceux du .env, puis ceux de .env.example (même commentés). Il reconnaît de nombreux alias (DATABASE_URL, DIRECT_URL, POSTGRES_PRISMA_URL, POSTGRES_*, PG*, MYSQL_*…) et garde le schéma et les paramètres de vos URL existantes.

Si le projet ne déclare rien, Joppa utilise les noms usuels de son framework :

Service	Laravel	Autres
Base de données	DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD	DATABASE_URL (Symfony : avec ?serverVersion=…&charset=utf8)
Redis, Valkey	REDIS_HOST, REDIS_PASSWORD, REDIS_PORT	REDIS_URL
Mailpit	MAIL_MAILER=smtp, MAIL_HOST, MAIL_PORT…	Symfony MAILER_DSN · Rails SMTP_ADDRESS, SMTP_PORT · Django EMAIL_HOST, EMAIL_PORT · Node SMTP_HOST, SMTP_PORT
Meilisearch	MEILISEARCH_HOST, MEILISEARCH_KEY, SCOUT_DRIVER	Symfony MEILISEARCH_URL, MEILISEARCH_API_KEY
Typesense	TYPESENSE_*, SCOUT_DRIVER	TYPESENSE_HOST, TYPESENSE_PORT, TYPESENSE_PROTOCOL, TYPESENSE_API_KEY

Le framework est reconnu à ses fichiers : Laravel (artisan), Symfony, Django (manage.py), Rails, Node (package.json).

Les services devinés

Joppa lit les fichiers du projet pour deviner les services dont il a besoin, même sans Docker Compose. Ce n’est qu’une indication : rien n’est ajouté ni branché sans vous.

Service	Ce qui le trahit
PostgreSQL, MySQL, MariaDB	DB_CONNECTION (pgsql, mysql, mariadb), le schéma de DATABASE_URL, DB_URL, POSTGRES_URL ou MYSQL_URL, le provider de Prisma, le dialect de Drizzle, les paquets pg, postgres, mysql2, mariadb…
Redis, Valkey	un pilote Laravel réglé sur redis (CACHE_STORE, SESSION_DRIVER, QUEUE_CONNECTION, BROADCAST_CONNECTION), REDIS_URL, VALKEY_URL, les paquets predis/predis, laravel/horizon, ioredis, redis, bullmq, iovalkey
Meilisearch, Typesense	SCOUT_DRIVER, MEILISEARCH_HOST, TYPESENSE_HOST…, les paquets meilisearch/meilisearch-php, typesense/typesense-php, meilisearch, typesense
Mailpit	un SMTP local sur le port 1025 (MAIL_MAILER=smtp avec MAIL_PORT=1025, ou SMTP_PORT=1025)

Joppa lit le .env, puis .env.example pour les clés que le .env n’a pas, composer.json, le package.json de la racine et ceux de apps/*, packages/* et services/*, prisma/schema.prisma et drizzle.config.*. Pour la base et le cache, il ne garde qu’un moteur : celui que le .env nomme passe avant un schéma, qui passe avant un paquet. SQLite ne demande aucun service. Un REDIS_HOST seul ne compte pas : chaque .env.example de Laravel le liste.

Le résultat apparaît à deux endroits :

• sur la page du projet, une ligne « Ce projet semble utiliser PostgreSQL, Redis et Meilisearch. », avec Voir dans Services ;
• en haut de cet onglet, le bloc « Ce projet semble utiliser », qui montre pour chaque service où il a été vu (.env.example · DB_CONNECTION=pgsql) et les moteurs qui feraient aussi l’affaire (Redis « ou Valkey », MySQL « ou MariaDB »). Brancher PostgreSQL 18 ouvre le diff habituel quand Joppa a déjà un service de ce moteur ; sinon, Ajouter Meilisearch ouvre la création du service, puis son branchement.

Les extensions PostgreSQL

Pour PostgreSQL, Joppa cherche aussi les extensions que le projet utilise :

• CREATE EXTENSION dans les fichiers .sql (migrations Prisma, Drizzle, Supabase, database/, db/…) et dans les migrations ;
• dans les migrations Laravel, Schema::ensureVectorExtensionExists() et ->vector( (pgvector), uuid_generate_v4() (uuid-ossp), gin_trgm_ops (pg_trgm) ;
• Rails enable_extension "hstore", Django CreateExtension("citext"), TrigramExtension(), VectorExtension()… ;
• Prisma extensions = [pg_trgm, uuid_ossp(map: "uuid-ossp")] et les types Unsupported("vector(…)") (pgvector) ou Unsupported("geometry(…)") (PostGIS) ;
• l’image de Compose : pgvector/pgvector, postgis/postgis.

Seules les extensions que Joppa sait fournir sont retenues : pgvector, PostGIS, pg_trgm, uuid-ossp, pgcrypto, citext, hstore, unaccent… La ligne PostgreSQL les liste (« Extensions : pgvector, pg_trgm ») ; un CREATE EXTENSION suffit d’ailleurs à deviner PostgreSQL. Ajouter PostgreSQL ouvre sa création avec ces extensions déjà cochées, sur le serveur et pour chaque nouvelle base. Quand le serveur choisi n’a pas encore une extension à activer sur le serveur (pgvector, PostGIS…), Activer pgvector ouvre ses réglages avec l’extension cochée, prête à enregistrer. La ligne reste affichée tant que le PostgreSQL branché sur le projet n’a pas toutes ses extensions.

Un service disparaît de la liste dès que le projet utilise un service du même type. La croix d’une ligne ignore ce service pour ce projet ; celle du bandeau, ou du haut du bloc, les ignore tous. Ce que le Docker Compose du projet lance déjà est laissé à l’import depuis Docker Compose.

La base de test (Laravel)

Les tests d’un projet Laravel lisent leur base dans phpunit.xml et dans .env.testing. Quand le projet en a un, cet onglet affiche un bloc Base de test qui dit ce qu’ils demandent :

• ils demandent une base précise (phpunit.xml règle DB_CONNECTION=pgsql et DB_DATABASE=boutique_testing, par exemple, souvent vers un autre outil) : Joppa propose cette base, sous ce nom, dans un de ses services du même moteur ;
• ils tournent sur SQLite alors que l’app utilise PostgreSQL, MySQL ou MariaDB : Joppa propose de les faire tourner sur le même moteur, dans une base <base de l'app>_test ;
• rien n’est réglé pour eux : ils utiliseraient la base de l’app, que RefreshDatabase vide. Joppa propose une base <base de l'app>_test à part.

Si l’app et les tests sont tous les deux sur SQLite, il n’y a rien à proposer et le bloc n’apparaît pas.

Le service est celui que le projet utilise déjà (sinon le premier du bon moteur) et le nom de la base se modifie. Créer et relier démarre le service si besoin, crée la base si elle manque et écrit DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME et DB_PASSWORD. Chaque fichier a son diff (Voir les changements) ; un DB_URL rempli est vidé, sans quoi il passerait avant ces valeurs.

Si les fichiers pointent déjà vers une base qui n’existe pas dans le service, le bloc le dit (« La base … n’existe pas encore dans … ») et Créer la base la crée, en démarrant le service si besoin.

Le projet a	Joppa écrit dans
.env.testing et phpunit.xml	.env.testing, et phpunit.xml seulement si vous cochez Modifier aussi phpunit.xml
.env.testing seul	.env.testing
phpunit.xml seul	phpunit.xml (ou phpunit.xml.dist s’il n’y a que lui)

Dans phpunit.xml, Joppa ne touche qu’aux balises <env name="DB_…"> : il change leur value, décommente celles que Laravel livre en commentaire, ajoute les manquantes à la fin de <php> avec la même indentation. Le reste du fichier ne bouge pas. Avant la première écriture, chaque fichier est copié à côté (phpunit.xml.joppa-backup, .env.testing.joppa-backup), et un fichier modifié sur le disque depuis l’aperçu n’est pas écrasé.

Le même choix est proposé quand vous ajoutez un projet Laravel et quand vous en créez un.