mortise
Mortise es una plataforma auto-alojada estilo Railway para Kubernetes que simplifica el despliegue de aplicaciones. Gestiona builds, dominios, TLS y variables de entorno sin complicar la gestión del clúster, manteniendo extensibilidad completa.
Ficha actualizada 26 sept 2026, 16:24 · upstream 26 sept 2026, 15:50 · release v1.1.0
Qué es mortise
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Mortise actúa como un operador único en Kubernetes que reconcilia recursos como App, Project, GitProvider y PreviewEnvironment. Incluye una UI basada en SvelteKit integrada, una API REST para gestión de despliegues y rollback, y una CLI (`mortise`) para operaciones directas. El sistema soporta despliegues desde código fuente (GitHub, GitLab) o imágenes pre-construidas, e incluso plantillas Docker Compose como Supabase.
El enfoque técnico destaca por la transparencia operativa: inyecta variables como `MORTISE_REVISION` en los contenedores para reportar el commit exacto del build. Detecta divergencias entre la especificación (spec) y lo que realmente corre (running), mostrando condiciones como `EnvRolledOut` o `PlaintextCredentials`. Esto evita incidentes ocultos donde la plataforma reporta éxito pero la aplicación falla.
La arquitectura es modular: un operador central orquesta controladores, API y UI. Permite usar Helm charts completos (`mortise`) con Traefik y cert-manager incluidos, o solo el operador (`mortise-core`) si ya se gestiona el stack de Ingress y registros OCI externamente.
- Despliegue rápido de aplicaciones Node.js o Go auto-alojadas en Kubernetes sin configurar manualmente Deployments ni Services.
- Gestión de múltiples entornos (producción, staging, preview) con namespaces aislados para cada uno.
- Integración con CI externo (GitHub Actions, GitLab CI) mediante webhooks para despliegues automáticos.
- Despliegue local en k3s o k3d sin necesidad de un clúster Kubernetes existente previamente configurado.
- Creación de entornos efímeros para PRs (Preview Environments) que se auto-limpian tras la revisión.
- Unificación de gestión de variables de entorno y secretos con soporte para credenciales enmascaradas.
- Arquitectura simplificada: un único operador sin dependencias externas ni protocolos de plugins complejos.
- Detección automática de divergencias entre la especificación del recurso y el estado real de los pods (ej. `EnvRolledOut`).
- Soporte nativo para despliegues desde Docker Compose, incluyendo plantillas predefinidas como Supabase.
- Gestión automática de dominios públicos con TLS y redirección HTTPS mediante Traefik por defecto.
- CLI robusta (`mortise`) que permite crear apps, desplegar y gestionar variables sin tocar el clúster directamente.
- Compatibilidad con perfiles de seguridad PodSecurity `restricted` para clusters con políticas estrictas.
- Requiere un clúster Kubernetes funcional (k3s, k8s, EKS, GKE) o instalación local vía k3d/k3s.
- No es un PaaS totalmente gestionado; el usuario debe administrar el clúster subyacente y backups.
- La configuración de Ingress y CertManager es obligatoria si no se usa el chart `mortise` completo con Traefik.
- Algunas funcionalidades avanzadas (como External Secrets o OIDC) requieren integración manual mediante CRDs o Helm values.
- Complejidad alta (`complexity: HIGH`) en comparación con soluciones serverless, requiriendo conocimientos de K8s para troubleshooting avanzado.
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.
Para despliegue rápido sin cluster existente, usa el script `curl -fsSL https://mortise.me/install | bash` (Linux/macOS) o PowerShell (Windows). Para clústeres existentes, instala con Helm: `helm install mortise mortise/mortise --namespace mortise-system`. Si ya tienes Ingress y CertManager, usa `mortise-core`. Asegura que el puerto 8090 esté abierto para la UI. Verifica los requisitos de recursos sugeridos (4 cores, 4GB RAM) para despliegues locales.
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.