kolea
Kōlea es un ESP auto-alojado en Cloudflare Workers que gestiona broadcasts, secuencias de drip y email transaccional. Destaca por su consentimiento escopado (abandonar una serie no baja del listado) y arquitectura materializada para envíos fiables bajo licencia MIT.
Ficha actualizada 23 sept 2026, 20:13 · upstream 23 sept 2026, 20:11 · release sin release detectada
Qué es kolea
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Kōlea es un sistema auto-alojado diseñado para operadores únicos, reemplazando ESPs de pago manteniendo la propiedad de los datos en D1 (SQLite). Su filosofía central es el consentimiento escopado: abandonar una secuencia no elimina al suscriptor del listado principal, diferenciándose de las herramientas tradicionales.
La arquitectura utiliza Cloudflare Workers con D1 para persistencia, R2 para medios y Queues para fan-out de envíos. El panel de administración se renderiza en el servidor usando Hono + JSX, evitando frameworks frontend pesados. Todo el sistema está construido en TypeScript estricto con Bun como runtime local.
Las métricas de analítica miden la salud del listado y el rendimiento de las campañas sin depender de terceros, mostrando caídas de conversión paso a paso. El diseño prioriza la auditoría y la privacidad, verificando el consentimiento justo antes de cada envío al proveedor.
- Gestión de newsletters auto-alojadas con propiedad total de datos
- Envíos transaccionales sin dependencias externas complejas
- Secuencias de drip con lógica de consentimiento granular
- Análisis de salud del listado y retención interna
- Blog integrado como extensión de los broadcasts
- Lógica de consentimiento escopado verificable en el código
- Arquitectura basada en Cloudflare Workers (D1, R2, Queues)
- Panel admin server-rendered sin framework frontend pesado
- Envíos materializados antes del fan-out para resiliencia
- Licencia MIT y código abierto auditable
- Diseñado para un solo operador, no multi-tenant por diseño
- Requiere Bun 1.1+ como runtime local obligatorio
- No incluye relay SMTP propio, necesita proveedor externo
- Configuración de despliegue manual (DNS, DMARC, Access)
- Análisis limitado a datos importados sin historial previo
Capturas del proyecto
Imágenes reales detectadas en la documentación del repositorio.
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Despliegue en Cloudflare Workers requiere D1, R2 y Queues. Configurar DNS, DMARC y Cloudflare Access para autenticación JWT. El runtime local usa Bun. Verificar docs/INSTALL.md antes de producción. Ajustar concurrencia de queues (pinned to 6) para evitar límites de proveedores como Resend.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.