Elido incluye un chart de Helm que despliega toda la pila en un clúster de Kubernetes, y este artículo lo recorre en un único nodo k3s. Antes de los comandos, lo que decide si debes seguir leyendo: Elido no es de código abierto y el autoalojamiento no es un producto que vendamos. El repositorio no tiene archivo de licencia, así que nadie fuera de la empresa tiene licencia para ejecutarlo o modificarlo. El chart es una herramienta de despliegue que guardamos en el repositorio, y los comandos de abajo provienen de él y del runbook que lo acompaña (consultado el 2026-10-25). Usa esta guía si trabajas en Elido, si tienes un acuerdo por escrito con nosotros o si quieres ver exactamente qué implica ejecutar la plataforma.
Si todavía estás eligiendo entre proyectos que sí puedes descargar, empieza por la comparación de acortadores autoalojados. Cubre YOURLS, Shlink, Kutt y Dub y no repite ninguno de los pasos de aquí.
Qué es el chart y qué no es
El chart vive en deploy/helm/elido. Sus metadatos apuntan a un repositorio de GitHub bajo la organización elidoapp; una petición sin autenticar a esa dirección devolvió 404 el 2026-10-25, así que no esperes clonarlo desde internet. El archivo de valores descarga imágenes de ghcr.io/elidoapp, y un comentario en él llama público al registro. No pude confirmar las descargas anónimas, así que trátalo como no verificado.
El chart también es joven. Su versión es 0.1.0, y su propia descripción llama al objetivo "clúster k3s de una sola región en una VM potente". Faltan algunas cosas que la gente da por hechas en un chart de Kubernetes, y una versión anterior de este artículo describía algunas por error:
- Sin alta disponibilidad. Cada stateful set ejecuta una réplica.
- Sin trabajos de copia de seguridad. El runbook lo dice y te indica usar Velero, k8up o instantáneas del proveedor.
- Sin objetos de monitorización, paneles ni autoescaladores.
- Sin edge multirregión. El preset colapsa las redirecciones en una sola flota.
Si un regulador o tu propia política los necesita, presupuesta el trabajo de añadirlos tú mismo.
Qué despliega el preset de autoalojamiento
values-selfhost.yaml recorta todo para encajar en un host de 4 núcleos y 8 GB. Ejecuta una réplica de cada carga de trabajo de la aplicación: api-core, analytics-api, click-ingester, url-scanner, notification, bio-renderer, billing, el panel (web), el sitio de marketing y una flota edge que responde por todos los hosts. Un servicio de identidad gestiona el registro y las sesiones.
Detrás hay seis stateful sets con volúmenes persistentes: Postgres (20Gi en el preset), Redis (2Gi), un almacén de columnas para eventos de clic (30Gi), un bus de eventos (10Gi), almacenamiento de objetos (20Gi) y un índice de búsqueda (5Gi). Aquí Redis es una única instancia con persistencia append-only, no un clúster. Varios servicios que antes eran independientes, como la gestión de dominios, la entrega de webhooks y la indexación de búsqueda, ahora se ejecutan dentro de api-core, por eso la lista de cargas de trabajo es más corta de lo que sugiere la documentación antigua.
Requisitos previos
El runbook pide Kubernetes 1.27 o posterior, Helm 3.13 o posterior y kubectl apuntando al clúster. También necesitas registros DNS para los nombres de host del panel, la API, la redirección y bio, un relé SMTP al que pueda llegar el clúster y un controlador de ingress de clase caddy.
k3s incluye Traefik, que competiría por los puertos 80 y 443 con el controlador que vas a instalar. Desactívalo al instalar k3s:
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown $UID ~/.kube/config
kubectl get nodes # should show Ready
Instalación, paso a paso
Crea el espacio de nombres y genera los secretos. El script genera valores aleatorios para la contraseña de la base de datos, las claves de cookie y de cifrado del servicio de identidad, la clave de ofuscación de slugs y el pepper de las claves de API, y crea marcadores para SMTP y LiqPay. Omite los secretos que ya existen salvo que pases --rotate.
kubectl create namespace elido
./deploy/helm/elido/scripts/bootstrap-secrets.sh elido
El script imprime la contraseña de Postgres al final. Guárdala. Luego sustituye el marcador de SMTP antes de que nadie se registre; el mismo patrón sirve para elido-liqpay si aceptas pagos:
kubectl -n elido create secret generic elido-smtp \
--from-literal=host=smtp.example.com \
--from-literal=port=587 \
[email protected] \
--from-literal=pass=YOUR_SMTP_KEY \
--from-literal=kratos_uri='smtps://postmaster%40your-domain.com:[email protected]:465/?disable_starttls=false' \
--dry-run=client -o yaml | kubectl apply -f -
Instala el controlador de ingress con el TLS bajo demanda activado:
helm repo add caddy https://caddyserver.github.io/charts
helm -n caddy-system upgrade --install caddy caddy/caddy-ingress-controller \
--create-namespace --set controller.config.onDemandTLS=true
Ahora instala Elido en sí. Fija image.tag a una versión que hayas elegido. El ejemplo del runbook usa latest, lo que hace difíciles de razonar las actualizaciones y los rollbacks.
helm -n elido upgrade --install elido ./deploy/helm/elido \
-f ./deploy/helm/elido/values-selfhost.yaml \
--set image.tag=YOUR_TAG \
--set ingress.hosts.dashboard=app.your-domain.com \
--set ingress.hosts.api=api.your-domain.com \
--set ingress.hosts.bio=bio.your-domain.com \
--set 'ingress.hosts.redirect={r.your-domain.com}' \
--set ingress.hosts.marketing=your-domain.com \
--set auth.kratos.publicHost=app.your-domain.com
kubectl -n elido get pods -w
Las migraciones se ejecutan como contenedores init para los servicios que las necesitan y como un trabajo de preinstalación para el servicio de identidad. Si una migración falla, los pods nuevos nunca reciben tráfico.
Primer usuario y dominios personalizados
Abre https://app.your-domain.com/signup y regístrate. El servicio de identidad crea la cuenta y api-core guarda una fila de usuario. Nada convierte todavía a ese usuario en propietario, así que crea un espacio de trabajo y una membresía a mano, que es lo que te indican las propias notas de instalación del chart:
kubectl -n elido exec -it sts/postgres -- psql -U elido -d elido <<'SQL'
INSERT INTO workspaces (slug, name, plan_tier)
VALUES ('default', 'Default', 'business') RETURNING id;
INSERT INTO workspace_members (workspace_id, user_id, role)
SELECT 1, id, 'owner' FROM users WHERE email = '[email protected]';
SQL
Los dominios personalizados usan TLS bajo demanda. Un cliente añade links.brand.com en el panel y luego apunta un CNAME al host que definas en EDGE_CNAME_TARGET (una variable de api-core cuyo valor por defecto es el nombre de host edge del propio Elido, así que cámbiala). En la primera petición HTTPS, el controlador de ingress llama a GET /v1/caddy/ask en api-core. Un 200 emite el certificado; un 403 significa que el dominio no está verificado. Depura con kubectl -n elido logs deploy/api-core | grep caddy/ask.
Copias de seguridad, actualizaciones y rollback
Las copias de seguridad son cosa tuya. La guía del runbook son instantáneas diarias del volumen de Postgres (data-postgres-0) y semanales del almacén de columnas (data-clickhouse-0), ya que los datos de clics pueden reproducirse desde el bus de eventos dentro de su ventana de retención. El volumen del bus de eventos no necesita copia de seguridad. Para usar un Postgres gestionado, define postgres.enabled=false y apunta la url del secreto elido-postgres a él. Ejecuta una restauración en un espacio de nombres de prueba antes de depender de nada de esto.
Las actualizaciones son un comando con una etiqueta nueva:
helm -n elido upgrade elido ./deploy/helm/elido \
-f ./deploy/helm/elido/values-selfhost.yaml --set image.tag=NEW_TAG
Las actualizaciones progresivas usan maxSurge: 1 y maxUnavailable: 0, y helm -n elido rollback elido <revision> devuelve los Deployments sin tocar volúmenes ni secretos. Con una réplica por servicio, espera breves interrupciones en las cargas de trabajo que no son sin estado.
Problemas conocidos
| Síntoma | Causa probable | Solución |
|---|---|---|
El trabajo de migración de identidad falla con database "kratos" does not exist | Postgres creó elido pero no esa base de datos | CREATE DATABASE kratos; mediante psql y luego helm upgrade de nuevo |
api-core entra en bucle de fallos pidiendo KRATOS_PUBLIC_URL | auth.kratos.enabled=false sin una sustitución | Vuelve a activar el servicio de identidad o define la variable con tu IdP |
| El panel da 502 en la primera carga | El certificado aún no se ha emitido | Vigila los registros del controlador de ingress; la primera emisión puede tardar unos 30 segundos |
| Las redirecciones devuelven 503 | La flota edge no puede llegar a Redis | Comprueba que la URL del secreto elido-redis apunte al servicio dentro del clúster |
| Todo entra en bucle de fallos tras un reinicio | PVC sin enlazar | kubectl get pv,pvc -n elido y confirma que el aprovisionador local-path está activo |
Si un DPO es la razón por la que estás aquí, la opción alojada quizá ya baste: sus datos principales están en la UE, y la guía de residencia en la UE lista lo que se procesa fuera de ella. Para el lado de la latencia de ejecutar tus propias redirecciones, consulta el artículo sobre edge POP.
Relacionado en el blog
Preguntas frecuentes
¿Puedo autoalojar Elido?
No como producto que ofrezcamos hoy. El repositorio tiene un chart de Helm y un runbook que usamos nosotros mismos, pero no tiene archivo de licencia, así que nadie fuera de Elido tiene licencia para ejecutar o modificar el código, y no hay un plan autoalojado ni soporte publicados. Si tienes un requisito firme de ubicación de datos, contáctanos y lo hablaremos como un acuerdo a medida.
¿Elido es de código abierto?
No. El repositorio no contiene archivo de licencia, lo que significa que todos los derechos están reservados. Algunos paquetes cliente (los SDK, los tipos de la API y el servidor MCP) llevan sus propios archivos LICENSE, pero la plataforma en sí, incluido el chart que describe este artículo, no. Cualquier texto de sitio que diga Apache 2.0 para el autoalojamiento es erróneo.
¿Qué necesita el preset de autoalojamiento para ejecutarse?
El runbook pide Kubernetes 1.27 o posterior, Helm 3.13 o posterior, DNS comodín para los hosts del panel, la API, la redirección y bio, un relé SMTP y un controlador de ingress de clase caddy. Se describe una VM de 4 núcleos y 8 GB como suficiente para una prueba de humo. Producción, según el mismo runbook, quiere tres o más nodos con 8 núcleos y 16 GB cada uno.
¿El chart incluye copias de seguridad, monitorización o alta disponibilidad?
No. El chart despliega Postgres, Redis, el almacén de columnas, el bus de eventos, el almacenamiento de objetos y la búsqueda como stateful sets de una sola réplica con volúmenes persistentes. Las copias de seguridad quedan a cargo de las herramientas de tu clúster, como Velero o k8up, y el chart no tiene objetos de monitorización, autoescalado ni conmutación por error. Versiones anteriores de este artículo los describían; no estaban en el chart.
¿Cómo funcionan los dominios personalizados en una instalación autoalojada?
El controlador de ingress pregunta a api-core en /v1/caddy/ask antes de emitir un certificado para un nombre de host desconocido, y api-core responde desde su lista de dominios verificados. Apuntas los CNAME de los clientes al host definido en EDGE_CNAME_TARGET. Si ese endpoint devuelve 403, el certificado nunca se emite, así que revisa primero los registros de api-core.
¿Cómo actualizo o hago rollback?
Ejecuta helm upgrade con el mismo archivo de valores y un nuevo image.tag. Los Deployments usan maxSurge 1 y maxUnavailable 0, y las migraciones de base de datos se ejecutan antes de que los nuevos pods sirvan tráfico, así que una migración fallida deja funcionando los pods antiguos. helm rollback a una revisión anterior intercambia los Deployments y deja en paz tus volúmenes de datos y secretos.
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Sin registro. Crea una cuenta gratis y obtén 50 enlaces al mes.