Cómo conectar Google Stitch con Google Antigravity: Aplicaciones atractivas sin esfuerzo

Si hay algo que me ha costado siempre en el desarrollo de aplicaciones, es el diseño de interfaces. Soy de los que pueden pasar horas peleándose con CSS para que un botón quede centrado, y al final sigue sin convencerme. Seguro que a más de uno os suena.

Pero últimamente Google ha estado soltando herramientas experimentales que, combinadas, pueden cambiar completamente cómo trabajamos. Hoy os traigo la combinación de Google Stitch + Google Antigravity: una dupla que te permite generar aplicaciones funcionales y visualmente atractivas en cuestión de minutos, no días.

¿Qué son estas herramientas?

Google Stitch: diseño por «vibe designing»

Google Stitch es el laboratorio de Google para generación de interfaces. Pero no es un simple generador de imágenes: describes lo que quieres construir y Stitch te propone diseños completos, con múltiples pantallas, flujos de navegación y componentes visuales listos para usar.

Lo mejor es que no te quedas con una imagen estática. Puedes interactuar con el diseño, pedir cambios, anotar modificaciones y, cuando estés satisfecho, descargar el código en HTML/CSS o React/Tailwind.

Actualmente está en beta gratuita (sin límites, de momento), así que es momento de aprovechar.

Google Antigravity: tu compañero de código con IA

Google Antigravity es el IDE de Google con agentes de IA integrados. Piensa en VS Code, pero donde la IA no solo autocompleta: planifica, codifica, depura e itera sobre proyectos complejos con mínima supervisión.

Durante la preview gratuita tienes acceso a Gemini Pro, Deep Think y Flash sin esos molestos límites de API que nos tienen acostumbrados otros servicios.

¿Por qué conectarlas?

Separadas son útiles. Juntas, son otro nivel:

  • Stitch se encarga del diseño visual
  • Antigravity se encarga de la lógica, base de datos, autenticación y despliegue

El truco está en añadir Stitch como servidor MCP (Model Context Protocol) dentro de Antigravity. Así, el agente puede consultar diseños de Stitch directamente e integrarlos en el código que genera.

Paso a paso: la integración

Paso 1: Instalar el servidor MCP de Stitch en Antigravity

En la ventana de agente de Antigravity (la derecha), hacemos clic en los tres puntos y seleccionamos MCP Servers.

Buscamos «stitch» en la lista y lo instalamos. Es un proceso de un clic.

Paso 2: Obtener la API key de Stitch

Necesitamos una clave para que Antigravity pueda hablar con Stitch:

  1. Vamos a stitch.withgoogle.com
  2. En la esquina superior derecha, hacemos clic en nuestro perfil
  3. Seleccionamos «API Keys» y generamos una nueva
  4. Copiamos la clave (empieza por algo como sk-...)

Paso 3: Configurar la API key en Antigravity

Volvemos a Antigravity, a la configuración del MCP Server de Stitch, y pegamos la API key en el campo correspondiente.

Y listo. La integración está completa.

Creando nuestra primera aplicación

Veamos un ejemplo real. Quiero construir un gestor de hábitos con modo oscuro y diseño minimalista.

1. Generamos el diseño en Stitch

Abrimos Stitch y escribimos:

«Aplicación minimalista para llevar un registro de hábitos con modo oscuro, gráficos de progreso semanales y botones para marcar la asistencia diaria. Estética limpia y moderna con toques en color morado».

En menos de un minuto, Stitch genera:

  • Pantalla principal con lista de hábitos
  • Gráfico de progreso semanal
  • Modal para añadir nuevos hábitos
  • Diseño responsive

Podemos iterar hasta que nos guste el resultado final.

2. Pasamos a Antigravity

Ahora viene la magia. En Antigravity, abrimos el chat con el agente y escribimos algo como:

«Crea una aplicación de gestión de hábitos usando el diseño que obtengas del servidor Stitch MCP. La app debe incluir:
– Autenticación con Clerk
– Base de datos con Convex
– Las funcionalidades que propone el diseño de Stitch
– Despliegue en Vercel»

El agente consultará Stitch, obtendrá el diseño, y empezará a construir la aplicación completa.

3. Iteración automática

Aquí es donde brilla Antigravity: no solo genera código, sino que:

  • Abre el navegador para probar la app
  • Detecta errores y los corrige
  • Verifica que la autenticación funcione
  • Comprueba que la base de datos se conecte correctamente

En mi caso, construí una app funcional en 23 minutos. Y no es un prototipo: tiene auth real, base de datos persistente y está lista para producción.

Trucos y consideraciones

Lo que funciona de maravilla

  • Diseños complejos: Stitch maneja bien múltiples pantallas y estados
  • Componentes modernos: Tailwind CSS, React, layouts responsive
  • Iteración rápida: cambiar el diseño en Stitch y pedir a Antigravity que actualice el código funciona sorprendentemente bien

Lo que aún falla

  • Detalles muy específicos: a veces hay que ajustar manualmente márgenes o colores exactos
  • Integraciones complejas: si necesitas APIs de terceros poco comunes, puede requerir intervención
  • Sesiones largas: después de muchos mensajes, el contexto se pierde un poco

Consejos prácticos

  1. Sé específico en Stitch: cuanto más detalle des en el prompt, mejor será el diseño base
  2. Itera en el diseño primero: mejor gastar 5 minutos ajustando en Stitch que 30 cambiando código
  3. Verifica pasos intermedios: pide a Antigravity que te muestre el diseño integrado antes de añadir complejidad

El futuro del desarrollo

Esta combinación de herramientas me hace reflexionar sobre hacia dónde vamos. No creo que vayan a reemplazar a los desarrolladores, pero sí que cambian el tipo de trabajo que hacemos:

  • Menos tiempo peleándose con CSS
  • Menos tiempo configurando boilers
  • Más tiempo pensando en la lógica de negocio y la experiencia de usuario

Es como pasar de ser albañil a ser arquitecto. Sigues construyendo, pero a otro nivel de abstracción.

¿Habéis probado ya esta combinación? ¿Qué experiencias tenéis con herramientas de IA para desarrollo? Me encantaría leer vuestros comentarios.

Recursos útiles:
Google Stitch
Google Antigravity
Documentación MCP

IA con OpenCode

Como ya vimos en la anterior entrada sobre agentes de IA opensource, hay vida más allá de claude code y gemini-cli (ya veremos cuando tengamos tiempo otros como kilo code) y se nos quedó pendiente instalar y probar otro agente muy conocido opencode.

Vamos a hacer aquí un resumen de la instalación, configuración con un modelo LLM que tengamos y hasta el uso de un MCP local, al igual que hicimos con goose. Luego veremos si son comparables y si lo son a sus homólogos «comerciales»

Instalación

La instalación de opencode es de todo menos dificil, solo tienes que entrar a la página https://opencode.ai/download y ahí tienes todas las opciones disponibles, de hecho, lo más sencillo es ejecutar este script que te indican en la página principal:

curl -fsSL https://opencode.ai/install | bash

Por defecto te va a instalar solo la versión de terminal, pero os recomiendo que vayáis a la página de descargas y os instaléis la versión de escritorio también, que no es que tenga muchas ventajas, pero ya que goose lo usamos en su versión de escritorio así podemos comparar un poco mejor (goose también tiene versión de terminal, pero no la he usado demasiado).

Configuración

Lo primero que tenemos que hacer justo después de arrancar opencode es conmfigurar nuestro LLM (debemos tener alguno disponible, ya sea local o remoto, esto es solo un agente).

Por suerte opencode es bastante amable a la hora de configurar un proveedor, solo tenemos que darle al icono + que vemos a la izquierda y se nos presentará la lista de proveedores soportados:

Y tiene un montón, nosotros, como ya hicimos en el post anterior vamos a conectarnos con glm-4.7 (si, ya han sacado nuevo modelo) y lo haremos usando Z.AI codign plan (podemos usar el que nosotros tengamos, aunque sea solo la capa gratuita)

Y luego cuando abramos un proyecto (un directorio) ya se nos permitirá elegir el modelo:

O, si estamos en el terminal, con la opción /model que nos permitirá elegir de los configurados:

Si os fijáis en la última imagen yo tengo ya configurados dos servidores MCP, vamos a ver cómo lo he hecho (tampoco es tan complicado, pero es más difícil que lo de escoger modelo).

En nuestro caso vamos a tener que editar un archivo, que está en /.config/opencode/opencode.jsonc, al que tendremos que adaptar el código que ya pusimos en el post anterior:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "outline": {
	"type": "local",
	"command": ["docker",
		"run",
		"-i",
		"--rm",
		"--init",
		"-e",
		"DOCKER_CONTAINER=true",
		"-e",
		"OUTLINE_API_KEY",
		"-e",
		"OUTLINE_API_URL",
		"biblioeteca/mcp-outline"
	],
	"environment": {
		"OUTLINE_API_KEY": "ol_api_...",
		"OUTLINE_API_URL": "https://mi-servidor-/api"
	},
	"enabled": true
    },
  }
}

Como véis es muy parecido a lo que poníamos anteriormente, solo aseguraos de que el entorno sea el correcto y luego ya podéis activar los MCP para cualquier proyecto o de manera general.

Para activarlos simplemente pinchar (en la versión de escritorio) en MCP en la parte superior derecha y os aparecerá un desplegable para activar o no los MCP que tengáis configurados:

Y, bueno, con esto ya tenemos otro agente listo para usarse, lo podemos usar en dos modos, modo Plan para que no haga ningún cambio y solo planifique lo que hay que hacer o en modo Build para que haga todos los cambios necesarios.

Me queda mucho por explorar todavía con este agente (y sus plugins, que hay alguno sabroso) pero todavía tengo que ver cómo engancharlo con un ollama local para no tener que usar modelos externos… Eso lo dejo para la próxima.

La IA más barata para generar código

Llevo desde casi el principio de toda esta vorágine utilizando github copilot, inicialmente con el modelo único que nos proporcionaba y recientemente en modo agente con claude sonnet y es lo mejor que he probado hasta el momento. Pero los 10 euros del copilot llegan hasta donde llegan y cuando se agota el crédito que tienes para usar claude con copilot te quedas un poco huerfano y es como si tu asistente se hubiese ido de vacaciones… Entonces me puse a buscar lo que costaría tener acceso extra a claude para cuando esto pasaba… Y resulta que son 20 eurazos al mes en su plan básico.

No parece mucho, pero si ya pagas copilot y no quieres pagar un extra tan alto solo para los días que se acaban los créditos de claude, pues se hace un poco cuesta arriba. Así que me puse a buscar qué otras opciones teníamos que fuesen, digamos, un poco más económicas y tuviesen un resultado similar al que te da claude. Y resulta que me topé con glm

Por 3 dolares al mes (contraté el trimestral para probar) dicen que tienen un modelo similar en potencia a claude sonnet 4. Lo que vamos a ver aquí es como utilizar este modelo con el agente claude code que tiene un comportamiento similar a github copilot y que permite, entre otras cosas, interactuar con MCPs. No es un proceso tan complicado, así que os dejo aquí cómo hacerlo:

Lo primero que vamos a necesitar es la clave API de GLM, para eso (suponiendo que os habéis suscrito, que si no nada de esto sirve), os vais a la sección de API keys

Y ahí creais una nueva API KEY. No os preocupeis que podréis copiarla después de haberla creado, no es como en otros sitios que solo te la muestran una vez. Guardad esa API key que la vais a necesitar después. Por cierto, tienen muy buena documentación sobre todo esto en su página web: https://docs.z.ai/guides/overview/quick-start

Lo siguiente que tienes que hacer es instalar claude code, esto suele ser bastante sencillo y bastaría con ejecutar esto (suponiendo que tienes una versión de node >= 18 en tu ordenador):

npm install -g @anthropic-ai/claude-code

Una vez instalado ejecutalo para que se creen los archivos de configuración (y eliges ya de paso el tema)

Luego, como no vamos a usar la cuenta de anthropic, simplemente damos ctrl-c varias veces para salir. Pero con ello ya se nos han creado los directorios de configuración y podemos editarlos.

Pon lo siguiente en el archivo ~/.claude/settings.json

{
    "env": {
        "ANTHROPIC_AUTH_TOKEN": "el api key de glm",
        "ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
    	"ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air",
        "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-4.6",
        "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-4.6"
    }
}

Luego nos vamos a cualquier directorio en el que tengamos código y querramos trabajar y ejecutamos el comando claude

Le decimos que si le damos permiso y ya podremos utilizar claude code con glm (lo podemos comprobar en la parte superior)

Y ya podemos usar el agente de claude con el modelo glm y ver qué tal se le da… En mis pruebas lo ha hecho bastante bien, aunque el interfaz es bastante más espartano que el de github copilot no le falta ninguna de las funcionalidades.

Por ahora disfrutad con esto (lo puedes lanzar desde dentro de un terminal de vscode y lo detecta y se integra con el ide) y en la siguiente entrada ya os digo como acceder a MCPs usando este agente y este modelo.

La herramienta correcta para gestión de tareas

Cualquier equipo, se dedique a lo que se dedique, cuando lo componen varias personas hay un momento en que alguien debe pararse y decir, ¿estamos haciendo las cosas bien? ¿en el orden correcto? ¿dedicando el tiempo necesario a cada una? ¿tenemos controlado el trabajo o el trabajo nos controla a nosotros? Lo que antes eran reuniones y encargos sencillos se ha convertido en un sin fin de recordatorios de cosas que no se han hecho, se han hecho sin necesidad o se han hecho demasiado tarde o demasiado pronto. En este punto es cuando la elección de una buena herramienta de gestión de tareas se hace necesaria.

Si esperáis que os diga cual es la correcta para el desarrollo de software, bueno, pues os equivocáis, todavía no he encontrado la que sea perfecta, pero si que puedo ofreceros mi visión sobre lo que necesitaría tener esa herramienta y los intentos de encontrarla que he tenido durante estos casi 30 años en el oficio.

Primero lo primero, cuales son las necesidades que queremos cubrir con esta herramienta:

  • Queremos poder registrar el tiempo dedicado y estimado para cada tarea sin que nos quite tiempo de trabajo efectivo.
  • Necesitamos saber la prioridad de las distintas tareas y poder ordenarlas en el tiempo.
  • Necesitamos saber quien tiene que trabajar en una tarea y qué es lo que tiene que hacer en la misma
  • Necesitamos saber el estado de cada tarea y el grado de avance general de la tarea y del proyecto al que pertenece
  • Es preciso poder descomponer el trabajo en tareas más pequeñas que puedan ser abordadas por una sola persona o, en el caso de requerir múltiples participantes al mismo tiempo que esté controlado el tiempo dedicado por cada persona
  • Queremos que cada proyecto tenga una visión clara de las tareas en curso y las que están en distintos estados del workflow de desarrollo
  • Necesitamos que haya una trazabilidad completa de las tareas desde su creación hasta que esta se termina
  • Es imprescindible disponer de documentación y una forma de asociarla a las tareas, pero de manera más independiente ya que la documentación ha de permanecer más allá de la vida de la tarea
  • Se necesita una manera ágil de comunicación entre los distintos componentes del equipo y, posiblemente, con elementos fuera de los equipos de desarrollo (usuarios, QA, dirección) aunque no es imprescindible que esté ligado al mismo sistema si que se necesita una manera sencilla de referirse a las tareas externamente.
  • Es deseable poder implementar distintos ciclos de vida a distintos tipos de proyectos y no limitarse a uno solo.
  • Si se usa un sistema el directorio de usuarios debe estar en sincronía con el de la empresa y la autenticación deberá ser compatible con la existente.

Evidentemente cada organización, empresa o grupo puede tener más o menos necesidades, pero en la lista anterior creo que he incluido las principales. El objetivo final es saber qué trabajo queda por hacer, qué hacer primero, tener previsiones de cuando estará un cierto trabajo complejo y saber cómo se están aprovechando los recursos. Obviamente cuanto más sencillo sea el sistema y cuanto menos tiempo nos quite de las tareas reales más efectivo será.

Y, para que sirva de referencia os voy a contar mi historia con los distintos sistemas de gestión de tareas que he tenido el «honor» de probar.

En el 97 empecé a trabajar profesionalmente en esto de la informática después de haber terminado la carrera y haber obtenido toda la teoría necesaria sobre gestión de proyectos y haber hecho un curso de CEPADE sobre gestión de proyectos tecnológicos. En la empresa en la que entré se gestionaba todo con Microsoft Project, por suerte generalmente la planificación moría en el momento en que el proyecto empezaba. Lo único que se esperaba respetar eran los plazos y los entregables. El tiempo dedicado no se actualizaba nunca y solo se ampliaban los plazos o, si el cliente se ponía pegigero, se cambiaba el alcance y se eliminaban o añadían tareas sin demasiado control.

Microsoft desarrolló una especie de project on-line para que los usuarios que estuviesen participando en un proyecto pudiesen imputar las horas o indicar cuando se habían acabado las tareas. Ahora mismo no recuerdo el nombre del producto, lo que si recuerdo es que era tan dificil de instalar y hacer funcionar correctamente que lo usamos solo en un proyecto antes del olvidarlo completamente. Project se quedó para el papeleo y marcar las fechas esperadas y controlar, por tanto, el retraso de las tareas y del proyecto en general.

Seguí usando project (sin ningún online y con control mediante arcaicas hojas excel) hasta que evolucioné lo suficiente (y puse mi propia empresa) como para usar Linux como mi máquina principal… Mira por donde ahí no había forma de ejecutar el project y me las vehía y deseaba para generar los gantt de manera medianamente atractiva para presentársela a los clientes (si, ya era para mis propios clientes). Llegados a este punto descubrí una herramienta online que, aunque inicialmente no creada para ello, servía perfectamente para hacer seguimiento del tiempo dedicado a las tareas de un proyecto, se trataba de trac. Tal como contaba en su página (hoy casi abandonada)

Trac es un sistema wiki mejorado y de seguimiento de incidencias para proyectos de desarrollo de software. Trac utiliza un enfoque minimalista para la gestión de proyectos de software basados en la web.

trac era un sistema de tickets, con un wiki para la documentación y conexión con subversion para el control de código. Si a esto le unimos que permitía indicar el número de horas dedicadas a cada incidencia, ya teníamos una primera forma de controlar en tiempo real las tareas. El wiki no era perfecto y la búsqueda también podía mejorarse, pero cumplió muy bien con su cometido durante unos cuantos años. De hecho el problema sobrevino cuando dejaron de mantener el producto y ya teníamos muchos proyectos gestionados con este sistema. Tengo que decir que antes de llegar a trac (que inicialmente se llamó svntrac) estuvimos usando cvstrac y cvs en lugar de subversion… Y si, tuvimos que migrar de cvs a subversion y de eso a git (es lo que tiene llevar más de 20 años produciendo código sin querer perder nada).

El caso es que descubrimos un poco después que había un programa que tenía todo lo que tenía trac (y algunas cosas más) que era completamente software libre y, además, rapidísimo y se llama Redmine. Aunque lleva creado desde 2006 no fue hasta 2018 que decidí implantarlo en mi empresa (y en la de algún cliente posteriormente). Aunque seguía sin ser perfecta nos ofrecía todo lo que necesitábamos para el control de tareas, nos permitía comunicarnos con los clientes via incidencias, llevar un tracking completo de todo en lo que hemos trabajado de cada proyecto, con múltiples proyectos completamente aislados unos de otros y con usuarios igualmente aislados y con roles diferenciados. Todos nuestros proyectos con mantenimiento se iniciaban como proyecto redmine y evolucionaba a proyecto de mantenimiento abierto a que los clientes pudieran dar de alta sus incidencias y hacer seguimiento de la evolución del mismo.

El mayor problema de redmine es que tremendamente poco intuitivo o, dicho en castellano «es feo de cojones». Aunque tiene todo lo que necesitamos para un equipo de desarrollo (aunque feo-feo), es imposible a día de hoy intentar que un cliente entre por el aro de reonocer esto como una aplicación web… Ahora se espera utilizar llamativos tableros kanvan (inutilizables cuando el número de tareas es alto o los equipos grandes) y modificaciones instantaneas via clicks y sin tener que escribir nada, solo pinchar y arrastrar. Me he pasado los últimos años buscando herramientas software libre que me permitiesen tener la misma privacidad y funcionalidad que redmine pero con un aspecto nuevo y renovado. He probado desde Trello hasta monday.com pasando por Jira y Asana (igual Jira no es tampoco demasiado atractivo). Quitando que ninguna de estas herramientas son libres de verdad y varias de ellas o son demasiado completas o carecen de alguna de las características que hemos descrito anteriormente todas ellas son carísimas… Sigo buscando ya que aunque redmine me viene bien para gestionar un equipo de desarrollo se atraganta a otro tipo de perfil menos hecho a lidiar con informes y formularios. ¿Conocéis alguno bueno y, a ser posible, open source o con una versión realmente barata?

Escribiendo código con una sola mano

Hace unos días he sufrido un desafortunado accidente que ha terminado con el 5º metatarso de mi mano izqierda fracturado. Eso significa que voy a estar de 3 a 8 semanas sin poder usar mi mano izquierda para nada.

El caso es que nunca pensé que echaría de menos tanto a mi mano izquierda pero, en serio, ahora me siento como menos capaz de hacer las mismas cosas que hacía antes, aunque no interviniese para nada la mano izquierda. Yo siempre he dicho que programar es un oficio de cabeza, no de teclas… Pero no veas cómo ayuda poder escribir rápido lo que estás pensando.

La mano izquierda es solo una herramienta, pero una que nos permite hacer mejor y más rápido lo que ya sabemos hacer… Casi como la IA.

Yo estoy suscrito a github copilot casi desde el principio (antes de que lo abriesen al público ya había hecho mis pruebas), como copiloto que te completa las líneas o que escribe por tí las aburridas funciones que le describes, o incluso que adivina lo siguiente que quieres hacer en el archivo en base a lo que ya has escrito antes, era fantástco, una herramienta de la que no te podías fiar 100% pero que te ahorraba muchas horas de búsquedas y pruebas. Pero es que el otro día probé el modo agente (usando claude sonnet 4) y la cabeza casi me estalla…

Había probado antes firebase studio de google, que intenta hacer un desarrollo completo de aplicación de manera visual y en base a instrucciones que le vas dando a la IA y, realmente, me gustó mucho el concepto, la pena es que solo sirve en ese modo para hacer aplicaciones React y yo necesitaba algo más flexible.. Y lo encontré en el modo agente de github copilot

Modo agente de copilot

Puedes usarlo en cualquier proyecto que ya tengas en visual studio code o puedes empezar uno de cero y con unas pocas instrucciones puedes crear el tipo de proyecto que quieras, tanto de front como de back, en el lenguaje que quieras y con el framework que quieras… Y no, no es vibe coding como tal, es una herramienta más que te sirve para ir dando forma y corrigiendo el proyecto en un entorno controlado por ti.

Y lo más flipante es que te explica lo que va a hacer y las ventajas que te da… Y escribe documentación para acompañar… Y además en tu idioma. Solo por eso ya es una herramienta muy valiosa. Pero, lo que es más, te ayuda a comprender que cuanto más claros y detallados están los requisitos más fácil es que lo que obtengas se parezca a lo que querías (igual a nuestros clientes hay que ponerles a hacer vibe coding para que empiecen a aprender a pedirnos las cosas).

Otra cosa muy interesante es poder seguir el razonamiento para arreglar problemas de una manera natural (en azul lo que le digo yo)

La imagen corresponde a un proyecto todavía en marcha, sin embargo puedo poneros como ejemplo un programa que ha desarrollado 100% github copilot (con mi dirección y correcciones). Tenéis todo el código en el repositorio: https://github.com/yoprogramo/imaphp

Ultimamente me he dedicado mucho a hospedar mis propios servidores, aprovechando que estaba probando proxmox. Uno de los servicios qu quería probar era el de servidor de correo e instalé Stalwart, un sistema muy completo y que, a lo mejor, os explico un día como instalar. Tiene multitud de servicios, no solo el de SMTP, sino IMAP, POP, CalDAV, Antispam, etc… Pero algo que no tiene es un cliente webmail. Me puse a buscar a ver si encontraba alguno que no tuviese dependencias y no me gustó ninguno, así que dije.. ¿Qué carajo? Vamos a escribir uno.

Y me puse manos a la obra, decidí que quería que fuese lo más ligero posible y que pudiese ejecutarse en cualquier sitio (docker incluido) y comencé el proyecto de cero usando el modo agente del copilot.

Para poder probarlo de la manera rápida, montad este docker-compose.yml:

services:
  imap-client:
    image: yoprogramo/imaphp:1.0.0
    ports:
      - "8888:80"
    environment:
      - PHP_DISPLAY_ERRORS=Off
      - PHP_ERROR_REPORTING=E_ERROR
    volumes:
      - ./data:/var/www/html/data
    restart: always

Crea un directorio data y dale los permisos para que todo el mundo pueda escribir y lánza el compose:

docker compose up -d

Ahora simplemente accede a http://localhost:8888 (puedes cambiar el puerto en el compose) y verás que se te invita a dar de alta un servidor

Y luego ya podrás entrar con tu usuario imap

Y, finalmente, acceder a tu correo:

Y con esto un pequeño ejemplo del tipo de cosas que se pueden pedir a las IAs de programación actualmente… Pero esto corre que se las pela, lo bueno es que siempre necesitaras a un humano de verdad que entienda lo que está haciendo y cómo arreglarlo.