La distribución personalizada de Shopify vincula una app a una sola tienda, o a una sola organización de Shopify Plus. Así que un proveedor que vende a muchos comerciantes independientes, y quiere que cada uno tenga su propia app privada, acaba operando una app por tienda: primero decenas, luego cientos. Diseñé y construí DeploTeka para que eso sea manejable. Aprovisiona, publica y entrega una app dedicada para cada tienda cliente, y en cualquier momento puede decir qué ejecuciones terminaron, cuáles pueden reanudarse con seguridad y qué tiendas tienen evidencia real de instalación. Funciona en producción como servicio alojado, con mi propio producto de medición para Shopify, Fixel Pixel, como cliente cero: una flota de unas 100 tiendas.
La tarea: por qué es difícil una app por tienda
DeploTeka es para proveedores de apps de Shopify: un fundador técnico con un producto conectado a Shopify, o una agencia con código de app o de integración reutilizable, que da servicio a comerciantes sin ninguna relación entre sí. Cada comerciante recibe su propia app de distribución personalizada. Compartir una misma app personalizada entre comerciantes que no tienen nada que ver es justo lo que el producto está hecho para evitar.
En cada tienda, el trabajo es siempre el mismo. Crear la app. Elegir la distribución personalizada. Custodiar las credenciales y entregarlas al backend del proveedor. Publicar la versión del proveedor. Enviar al comerciante un enlace de instalación, esperar su aprobación y después averiguar si la tienda correcta terminó de verdad con la instalación y la versión correctas. A mano, es la misma lista de comprobación para cada cliente, y cada paso puede fallar a su manera. Con cien tiendas, el cuello de botella ya no es el producto. Es la operación.
La respuesta obvia es un script que recorre las tiendas y llama a la CLI de Shopify. Falla ante tres preguntas:
- ¿Terminó la ejecución? El aprovisionamiento es una cadena: crear la app, seleccionar la distribución personalizada, leer las credenciales, aplicar la marca, desplegar la plantilla y crear el acuerdo de instalación firmado y específico de la tienda. Un script que muere en el paso cuatro deja atrás una app a medio hacer y ningún registro de dónde se quedó.
- ¿Es seguro reanudarla? Volver a empezar desde arriba después del paso cuatro no es un reintento. Es una segunda ejecución, en conflicto con la primera, contra una tienda real.
- ¿La tienda está instalada de verdad? El script ve «enlace de instalación creado» y da el trabajo por bueno. El comerciante todavía no ha aprobado nada.
DeploTeka existe para responder a esas tres preguntas con evidencia.
Lo que construí
DeploTeka es un plano de control con aislamiento por tenant, organizado en cuatro capas: contratos y políticas conscientes del tenant en el dominio; orquestación y casos de uso en la capa de aplicación; persistencia en PostgreSQL, un almacén cifrado y los adaptadores de Shopify en la infraestructura; rutas de Fastify y vistas renderizadas en el servidor sobre HTTP. Trabaja con las API y la CLI oficiales de Shopify. El código del proveedor sigue siendo del proveedor: DeploTeka lee la configuración de la app que necesita sin clonar, compilar ni ejecutar ese código fuente en sus propios servidores.
Ocho piezas sostienen el conjunto.
Una frontera de tenant en cada clave
Cada clave de la base de datos lleva la organización a la que pertenece, y cada método de repositorio exige un id de tenant. Un id de trabajo por sí solo no autoriza nada: conocer el id de la ejecución de otro no te permite leerla ni tocarla. El aislamiento vive en la capa de datos, así que una pantalla o un endpoint nuevos no pueden olvidarlo.
Una frontera de secretos en la API
El navegador nunca recibe cookies de Partner o del Dashboard, tokens CSRF, secretos de cliente de la app, tokens de acceso offline ni respuestas en bruto del conector, y nada de eso tiene cabida en los logs ni en los payloads de estado ordinarios. Las credenciales de la app se sellan en un almacén cifrado. Los enlaces de instalación también se tratan como secretos. En el panel web solo un propietario, un administrador o un operador puede revelar uno, cada revelación genera un evento de auditoría y, en la ruta de entrega de tokens, se genera un enlace nuevo en cada revelación en lugar de guardarlo.
Aprovisionamiento idempotente y reanudable
Una ejecución se registra de forma duradera, con una clave de idempotencia, antes de la primera mutación en Shopify. La base de datos mantiene único el par organización más clave, así que la misma petición no puede iniciar una segunda ejecución. Después, la ejecución avanza por pasos persistidos, cada uno con su estado, su evidencia y su evento de auditoría. Si un paso necesita una acción fuera de DeploTeka (de un operador, del comerciante o de una herramienta de despliegue en la máquina del proveedor), la ejecución se pausa en una acción manual con nombre y más tarde se reanuda en la misma ejecución y el mismo ámbito de idempotencia. Tras una caída, continúa desde su último paso persistido. Un efecto del proveedor cuyo resultado se desconoce sigue siendo desconocido y se reconcilia; nunca se reintenta a ciegas.
Versiones publicadas por tienda
La app que DeploTeka genera para cada tienda es un activo versionado del tenant del proveedor, construido a partir de una plantilla. El plano de control la despliega, pero no está acoplado a su código. En la próxima versión, ya en revisión, el modo de entrega añade una barrera: el enlace de instalación del comerciante se retiene hasta que la versión publicada de la app de esa tienda puede leerse de vuelta desde Shopify. Esa barrera salió de una ejecución real, en la que un enlace creado antes de que existiera ninguna versión resultó inservible mientras la ejecución seguía diciendo «listo».
Entrega de credenciales, medida por el resultado
Las credenciales van del almacén al backend del proveedor, nunca a través del navegador. Cada entrega termina como aplicada, repetida o desconocida, y desconocida no es ni un éxito ni un fallo: se reconcilia a través de la ruta de estado. La entrega demuestra el transporte, no que la credencial funcione. Por eso, en DeploTeka, la activación es la primera llamada exitosa a la Admin API de Shopify hecha con la credencial entregada.
Fijé esa definición después de la primera entrega real de credenciales, en mi propia tienda, el 28 de agosto de 2026. Todas las señales internas estaban en verde y la entrega se había completado, y aun así el lado receptor no podía hacer ni una sola llamada a la Admin API hasta que una persona le dijo qué permisos se habían concedido. Un pipeline en verde no era un problema resuelto. Una llamada a la API que funciona, sí.
Roles que mantienen los secretos lejos del estado
Cuatro roles. Propietario: facturación, credenciales del conector, miembros, acciones destructivas. Administrador: plantillas, clientes, tiendas, aprovisionamiento y miembros que no sean propietarios. Operador: clientes, tiendas, aprovisionamiento y revelar un enlace de instalación. Lector: estado en solo lectura e historial de auditoría, sin enlaces que contengan secretos. Un lector puede seguir una ejecución de principio a fin sin poder revelar nunca el enlace que produjo.
Evidencia de instalación, no enlaces de instalación
Una tienda que DeploTeka aprovisiona cuenta como instalada solo cuando la autenticación de Shopify ha producido una sesión offline válida para la tienda y el id de cliente de la app exactos, y la propiedad de tenant, tienda y app coincide en la base de datos. El diseño exige además que las extensiones requeridas de la app se lean de vuelta como listas. En la versión publicada esa comprobación sigue siendo provisional; la próxima versión, ya en revisión, la hace fallar en cerrado: sin prueba positiva responde «desconocido», y la tienda se queda en aprovisionamiento en lugar de aparecer como instalada. Un verificador que no puede alcanzar una tienda también devuelve «desconocido», con un motivo explícito: sin falsos negativos y sin ascensos silenciosos a instalada. Una tienda que DeploTeka aprovisiona nunca aparece como instalada sin evidencia.
Fencing para workers obsoletos
Cada ejecución se mantiene bajo un lease duradero: una reserva con propietario, caducidad y un número de generación que solo sube. Cuando un lease caduca y otro worker toma la ejecución, el worker anterior queda bloqueado (fenced): su generación está obsoleta, así que ya no puede hacer avanzar la ejecución. Cada efecto externo se protege antes y después de la llamada, y un efecto que sobrevive a su lease se registra como desconocido, no como éxito. La planificación pasa por carriles de un solo escritor. El fencing está cubierto por 99 tests específicos, entre ellos dos workers compitiendo por la misma ejecución. A propósito, no es una promesa de exactly-once: el diseño hace explícita la incertidumbre en lugar de fingir que no existe.
Cómo funciona hoy
Llevo yo mismo las operaciones reales de DeploTeka, con Fixel Pixel, mi producto de medición para Shopify, como integración de referencia.
- Julio de 2026. Migré la flota de tiendas de Fixel Pixel al servicio de producción de DeploTeka. Hoy reúne unas 100 tiendas de Shopify.
- Agosto de 2026. Terminado el fencing de workers obsoletos, cubierto por 99 tests específicos, seguido de los carriles de planificación de un solo escritor.
- 28 de agosto de 2026. Primera entrega real de credenciales, en mi propia tienda.
- 7 y 8 de septiembre de 2026. Publicaciones en producción, con un ensayo de publicación en dos tiendas de mi propia flota el 8 de septiembre.
Cada publicación en producción, y cada acción sobre una tienda real o una credencial, necesita mi autorización. La próxima versión, ya en revisión, añade la comprobación de extensiones en fallo cerrado y la barrera del enlace de instalación. Saldrá a producción cuando termine la revisión y yo la apruebe.
Decisiones de ingeniería que vale la pena copiar
Ninguna es específica de Shopify. Sirven para cualquier sistema que ejecute trabajos largos, de varios pasos, contra API que no controlas.
- Registra antes de tocar. Escribe la ejecución y su clave de idempotencia en tu propia base de datos antes de la primera llamada a la API de otro. Una restricción de unicidad sobre tenant más clave convierte «¿ya habíamos empezado esto?» en una garantía de la base de datos.
- Persiste pasos, no solo trabajos. Un trabajo marcado como «en curso» no te dice nada después de una caída. Una ejecución hecha de pasos persistidos, cada uno con su estado y su evidencia, te dice dónde reanudar y permite que una persona intervenga en una acción con nombre sin romper la cadena.
- Bloquea con una generación, no con un timeout. Los leases caducan y los workers lentos se despiertan. Una generación monótona comprobada antes y después de cada efecto externo impide que un worker antiguo sobrescriba el trabajo de su sucesor.
- Haz de lo desconocido un estado de primera clase. Las redes pierden respuestas. Tres resultados (hecho, fallido y desconocido con un motivo) evitan que una respuesta perdida se redondee a verde o se reintente hasta crear un duplicado. Cuando una comprobación no puede demostrar algo, que falle en cerrado y responda «desconocido».
- Define «hecho» por el resultado del cliente. La activación es la primera llamada exitosa a la Admin API con la credencial entregada, no el último paso en verde de tu pipeline. Por la misma lógica, nunca entregues un enlace a algo que todavía no existe.
- Deja por escrito qué respalda cada afirmación. El contrato de producto de DeploTeka etiqueta cada afirmación sobre su comportamiento según su evidencia: código, test, registro de producción fechado, fuente oficial de la plataforma o decisión aceptada. Así, un test que pasa no se cita como prueba de producción.
Lo que viene
Tres piezas: una prueba positiva de que las extensiones requeridas de una tienda están listas, para que esa comprobación pueda responder «sí» en lugar de «desconocido»; una publicación en toda la flota, con un registro por tienda de lo que se publicó exactamente; y llevar a los primeros proveedores de apps externos por el recorrido completo. Ninguno lo ha completado todavía.
Si necesitas algo parecido
DeploTeka es el tipo de sistema que me gusta construir: muchos tenants, una plataforma que no controlas, ejecuciones largas de varios pasos, secretos y la obligación de saber qué pasó de verdad. El mismo diseño sirve para pipelines de aprovisionamiento, plataformas de integración, automatización de back-office y cualquier ejecutor de trabajos en el que una ejecución a medias cueste dinero.
Puedo construir para ti una plataforma de este tipo, o la pieza que te falta: aprovisionamiento idempotente, un ejecutor de trabajos reanudable, un flujo de entrega de credenciales o una frontera de tenant que aguante. Mira cómo abordo las integraciones de API y la automatización, o describe tu tarea en Task for Daniel. Si prefieres escribir primero el encargo, la guía API Integration Brief (en inglés) enumera lo que conviene cerrar antes de escribir código, incluidas las claves de idempotencia.