Servicios

La pestaña Servicios (V) conecta al proyecto los servicios de Joppa: PostgreSQL, MySQL, Redis, Mailpit, Meilisearch… Su contador indica cuántos servicios están vinculados. Basta un clic: las variables del servicio van al .env, tras un diff, y siguen su puerto.

Servicios o procesos

Bajo la introducción, la pestaña lo recuerda: «Joppa comparte los servicios entre tus proyectos (base de datos, caché, correo). Lo que el proyecto ejecuta por sí mismo está en Procesos.» (Ver los procesos).

• Un servicio de Joppa se ejecuta una sola vez para todos tus proyectos; cada proyecto tiene en él su base de datos. Se crea desde la página Servicios y se conecta aquí.
• Un proceso pertenece al proyecto: sus servidores de desarrollo, sus workers, sus contenedores Docker Compose. Se gestiona en la pestaña Procesos.

Los servicios vinculados se inician primero con «Iniciar todo», antes que los procesos del proyecto.

Conectar un servicio

El bloque de servicios lista los de Joppa. Usar PostgreSQL (o Redis, Mailpit…) abre un diff con dos opciones:

• Vincular y escribir en .env: se escriben las variables del servicio, y se mantienen al día si cambia su puerto.
• Vincular sin escribir: Joppa guarda el vínculo, sin tocar el archivo.

Un servicio conectado se inicia enseguida si estaba detenido, también cuando aceptas los servicios deducidos al añadir un proyecto. En el caso de una base de datos, si la base del proyecto todavía no existe, Joppa la crea: la fila del servicio indica «Base de datos {nombre}, creada al conectarla» y, una vez conectado, un selector permite pasar a otra base del servicio; si la base elegida no existe en el servicio, Crear la crea. Las listas de bases de datos (página del servicio, base de pruebas) se actualizan en cuanto se crea una. Un proyecto solo usa un servicio de cada tipo: conectar MySQL reemplaza a PostgreSQL.

Dejar de usar… hace lo contrario: Desvincular y limpiar el .env restaura el valor de .env.example (o quita la variable), Desvincular sin tocar el .env deja el archivo tal cual. Las variables que modificaste a mano se conservan.

La conexión escribe en el .env: si el editor del .env (pestaña Entorno) tiene cambios sin guardar, los interruptores se desactivan («Primero guarda o descarta los cambios del .env»).

Con qué nombres

Joppa escribe con los nombres que el proyecto ya lee: los del .env y luego los de .env.example (aunque estén comentados). Reconoce muchos alias (DATABASE_URL, DIRECT_URL, POSTGRES_PRISMA_URL, POSTGRES_*, PG*, MYSQL_*…) y conserva el esquema y los parámetros de tus URL existentes.

Si el proyecto no declara nada, Joppa usa los nombres habituales de su framework:

Servicio	Laravel	Otros
Base de datos	DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD	DATABASE_URL (Symfony: con ?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

El framework se reconoce por sus archivos: Laravel (artisan), Symfony, Django (manage.py), Rails, Node (package.json).

Servicios deducidos

Joppa lee los archivos del proyecto para deducir los servicios que necesita, incluso sin Docker Compose. Es solo una indicación: no se añade ni se conecta nada sin ti.

Servicio	Qué lo delata
PostgreSQL, MySQL, MariaDB	DB_CONNECTION (pgsql, mysql, mariadb), el esquema de DATABASE_URL, DB_URL, POSTGRES_URL o MYSQL_URL, el provider de Prisma, el dialect de Drizzle, los paquetes pg, postgres, mysql2, mariadb…
Redis, Valkey	un driver de Laravel en redis (CACHE_STORE, SESSION_DRIVER, QUEUE_CONNECTION, BROADCAST_CONNECTION), REDIS_URL, VALKEY_URL, los paquetes predis/predis, laravel/horizon, ioredis, redis, bullmq, iovalkey
Meilisearch, Typesense	SCOUT_DRIVER, MEILISEARCH_HOST, TYPESENSE_HOST…, los paquetes meilisearch/meilisearch-php, typesense/typesense-php, meilisearch, typesense
Mailpit	un SMTP local en el puerto 1025 (MAIL_MAILER=smtp con MAIL_PORT=1025, o SMTP_PORT=1025)

Joppa lee el .env, luego .env.example para las claves que faltan en el .env, composer.json, el package.json de la raíz y los de apps/*, packages/* y services/*, prisma/schema.prisma y drizzle.config.*. Para la base de datos y la caché conserva un solo motor: el que nombra el .env gana a un esquema, que gana a un paquete. SQLite no necesita ningún servicio. Un REDIS_HOST solo no cuenta: todos los .env.example de Laravel lo incluyen.

El resultado aparece en dos sitios:

• en la página del proyecto, una línea «Este proyecto parece usar PostgreSQL, Redis y Meilisearch.», con Ver en Servicios;
• arriba de esta pestaña, el bloque «Este proyecto parece usar», que muestra dónde se vio cada servicio (.env.example · DB_CONNECTION=pgsql) y los motores que también servirían (Redis «o Valkey», MySQL «o MariaDB»). Conectar PostgreSQL 18 abre el diff habitual cuando Joppa ya tiene un servicio de ese motor; si no, Añadir Meilisearch abre la creación del servicio y luego lo conecta.

Las extensiones de PostgreSQL

Para PostgreSQL, Joppa también busca las extensiones que usa el proyecto:

• CREATE EXTENSION en los archivos .sql (migraciones de Prisma, Drizzle, Supabase, database/, db/…) y en las migraciones;
• en las migraciones de Laravel, Schema::ensureVectorExtensionExists() y ->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")] y los tipos Unsupported("vector(…)") (pgvector) o Unsupported("geometry(…)") (PostGIS);
• la imagen de Compose: pgvector/pgvector, postgis/postgis.

Solo se conservan las extensiones que Joppa puede ofrecer: pgvector, PostGIS, pg_trgm, uuid-ossp, pgcrypto, citext, hstore, unaccent… La fila de PostgreSQL las lista («Extensiones: pgvector, pg_trgm»); un CREATE EXTENSION basta para deducir PostgreSQL. Añadir PostgreSQL abre su creación con esas extensiones ya marcadas, en el servidor y para cada base nueva. Cuando al servidor elegido le falta una extensión que hay que activar en el servidor (pgvector, PostGIS…), Activar pgvector abre sus ajustes con la extensión marcada, lista para guardar. La fila se mantiene mientras al PostgreSQL conectado al proyecto le falte alguna.

Un servicio sale de la lista en cuanto el proyecto usa un servicio del mismo tipo. La cruz de una fila ignora ese servicio en este proyecto; la del aviso, o la de arriba del bloque, los ignora todos. Lo que ya ejecuta el Docker Compose del proyecto queda para la importación desde Docker Compose.

La base de datos de pruebas (Laravel)

Las pruebas de un proyecto Laravel leen su base de datos en phpunit.xml y en .env.testing. Cuando el proyecto tiene uno de ellos, esta pestaña muestra un bloque Base de datos de pruebas que indica lo que piden:

• piden una base de datos concreta (phpunit.xml define DB_CONNECTION=pgsql y DB_DATABASE=shop_testing, por ejemplo, a menudo apuntando a otra herramienta): Joppa propone esa base de datos, con ese nombre, en uno de sus servicios del mismo motor;
• se ejecutan en SQLite mientras la app usa PostgreSQL, MySQL o MariaDB: Joppa propone ejecutarlas en el mismo motor, en una base de datos <base de la app>_test;
• no hay nada configurado para ellas: usarían la base de datos de la app, que RefreshDatabase vacía. Joppa propone una base de datos <base de la app>_test aparte.

Si la app y las pruebas están ambas en SQLite, no hay nada que proponer y el bloque no aparece.

El servicio es el que el proyecto ya usa (si no, el primero del motor adecuado) y el nombre de la base de datos se puede cambiar. Crear y enlazar inicia el servicio si hace falta, crea la base de datos si falta y escribe DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME y DB_PASSWORD. Cada archivo tiene su diff (Ver los cambios); un DB_URL con valor se vacía, porque tendría prioridad sobre estos valores.

Si los archivos ya apuntan a una base de datos que no existe en el servicio, el bloque lo indica («La base de datos … aún no existe en …») y Crear la base de datos la crea, iniciando el servicio si hace falta.

El proyecto tiene	Joppa escribe en
.env.testing y phpunit.xml	.env.testing, y phpunit.xml solo si marcas Modificar también phpunit.xml
solo .env.testing	.env.testing
solo phpunit.xml	phpunit.xml (o phpunit.xml.dist si es el único)

En phpunit.xml, Joppa solo toca las etiquetas <env name="DB_…">: cambia su value, descomenta las que Laravel trae comentadas y añade las que faltan al final de <php> con la misma sangría. El resto del archivo no cambia. Antes de la primera escritura, cada archivo se copia al lado (phpunit.xml.joppa-backup, .env.testing.joppa-backup), y un archivo modificado en el disco desde la vista previa no se sobrescribe.

La misma elección se propone cuando añades un proyecto Laravel y cuando creas uno.