Elido sur k3s : ce que le chart Helm déploie ou non

Elido livre un chart Helm qui déploie toute la pile sur un cluster Kubernetes, et cet article le parcourt sur un seul nœud k3s. Avant les commandes, la partie qui décide si vous devez continuer à lire : Elido n'est pas open source et l'auto-hébergement n'est pas un produit que nous vendons. Le dépôt n'a pas de fichier de licence : personne en dehors de l'entreprise n'a donc de licence pour l'exécuter ou le modifier. Le chart est un outil de déploiement que nous gardons dans le dépôt, et les commandes ci-dessous viennent de lui et du guide d'exploitation qui l'accompagne (consulté le 2026-10-25). Utilisez ce guide si vous travaillez sur Elido, si vous avez un arrangement écrit avec nous, ou si vous voulez voir exactement ce qu'implique l'exploitation de la plateforme.

Si vous hésitez encore entre des projets que vous pouvez réellement télécharger, commencez par la comparaison des raccourcisseurs auto-hébergés. Elle couvre YOURLS, Shlink, Kutt et Dub et ne répète aucune des étapes d'ici.

Ce qu'est le chart, et ce qu'il n'est pas

Le chart se trouve dans deploy/helm/elido. Ses métadonnées pointent vers un dépôt GitHub de l'organisation elidoapp ; une requête non authentifiée vers cette adresse a renvoyé 404 le 2026-10-25, ne comptez donc pas le cloner depuis Internet. Le fichier de valeurs récupère les images depuis ghcr.io/elidoapp, et un commentaire y qualifie le registre de public. Je n'ai pas pu confirmer les pulls anonymes, considérez donc cela comme non vérifié.

Le chart est aussi jeune. Sa version est 0.1.0, et sa propre description qualifie la cible de "cluster k3s monorégion sur une grosse VM". Quelques éléments que l'on suppose fournis avec un chart Kubernetes manquent, et une version antérieure de cet article en décrivait certains à tort :

• Pas de haute disponibilité. Chaque StatefulSet tourne avec une réplique.
• Pas de tâches de sauvegarde. Le guide le dit et vous renvoie à Velero, k8up ou aux instantanés du fournisseur.
• Pas d'objets de supervision, de tableaux de bord ni de mise à l'échelle automatique.
• Pas d'edge multirégion. Le preset regroupe les redirections en une seule flotte.

Si un régulateur ou votre propre politique en a besoin, prévoyez le travail pour les ajouter vous-même.

Ce que déploie le preset d'auto-hébergement

values-selfhost.yaml réduit tout pour tenir sur un hôte de 4 cœurs et 8 Go. Il exécute une réplique de chaque charge applicative : api-core, analytics-api, click-ingester, url-scanner, notification, bio-renderer, billing, le tableau de bord (web), le site marketing, et une flotte edge qui répond pour tous les hôtes. Un service d'identité gère l'inscription et les sessions.

Derrière se trouvent six StatefulSets avec volumes persistants : Postgres (20Gi dans le preset), Redis (2Gi), un magasin en colonnes pour les événements de clic (30Gi), un bus d'événements (10Gi), un stockage d'objets (20Gi) et un index de recherche (5Gi). Redis est ici une instance unique avec persistance append-only, pas un cluster. Plusieurs services autrefois séparés, dont la gestion des domaines, la livraison des webhooks et l'indexation de recherche, s'exécutent désormais dans api-core, ce qui explique que la liste des charges soit plus courte que ne le suggèrent les anciennes docs.

Prérequis

Le guide demande Kubernetes 1.27 ou plus récent, Helm 3.13 ou plus récent et kubectl pointé sur le cluster. Il vous faut aussi des enregistrements DNS pour les noms d'hôte du tableau de bord, de l'API, de la redirection et du bio, un relais SMTP joignable depuis le cluster, et un contrôleur d'ingress de classe caddy.

k3s embarque Traefik, qui entrerait en concurrence pour les ports 80 et 443 avec le contrôleur que vous allez installer. Désactivez-le à l'installation de 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

Installation pas à pas

Créez l'espace de noms et générez les secrets. Le script génère des valeurs aléatoires pour le mot de passe de la base de données, les clés de cookie et de chiffrement du service d'identité, la clé d'obfuscation des slugs et le pepper des clés d'API, et il crée des valeurs de substitution pour SMTP et LiqPay. Il ignore les secrets qui existent déjà, sauf si vous passez --rotate.

kubectl create namespace elido
./deploy/helm/elido/scripts/bootstrap-secrets.sh elido

Le script affiche le mot de passe Postgres à la fin. Notez-le. Remplacez ensuite la valeur de substitution SMTP avant que quiconque s'inscrive ; le même schéma fonctionne pour elido-liqpay si vous encaissez des paiements :

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 -

Installez le contrôleur d'ingress avec le TLS à la demande activé :

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

Installez maintenant Elido lui-même. Épinglez image.tag sur une version que vous avez choisie. L'exemple du guide utilise latest, ce qui rend les mises à jour et les retours en arrière difficiles à raisonner.

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

Les migrations s'exécutent comme init containers pour les services qui en ont besoin et comme job de pré-installation pour le service d'identité. Si une migration échoue, les nouveaux pods ne prennent jamais de trafic.

Premier utilisateur et domaines personnalisés

Ouvrez https://app.your-domain.com/signup et inscrivez-vous. Le service d'identité crée le compte et api-core stocke une ligne utilisateur. Rien ne fait encore de cet utilisateur un propriétaire : créez donc un espace de travail et une appartenance à la main, ce que les notes d'installation du chart vous disent de faire :

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

Les domaines personnalisés utilisent le TLS à la demande. Un client ajoute links.brand.com dans le tableau de bord, puis fait pointer un CNAME vers l'hôte que vous avez défini dans EDGE_CNAME_TARGET (une variable d'api-core qui vaut par défaut le nom d'hôte edge d'Elido lui-même, changez-la donc). À la première requête HTTPS, le contrôleur d'ingress appelle GET /v1/caddy/ask sur api-core. Un 200 émet le certificat ; un 403 signifie que le domaine n'est pas vérifié. Déboguez avec kubectl -n elido logs deploy/api-core | grep caddy/ask.

Sauvegardes, mises à jour et retour arrière

Les sauvegardes vous incombent. La recommandation du guide est des instantanés quotidiens du volume Postgres (data-postgres-0) et hebdomadaires pour le magasin en colonnes (data-clickhouse-0), puisque les données de clics peuvent être rejouées depuis le bus d'événements dans sa fenêtre de rétention. Le volume du bus d'événements n'a pas besoin de sauvegarde. Pour utiliser un Postgres géré, définissez postgres.enabled=false et faites pointer le champ url du secret elido-postgres vers lui. Lancez une restauration dans un espace de noms de test avant de vous fier à tout cela.

Les mises à jour tiennent en une commande avec un nouveau tag :

helm -n elido upgrade elido ./deploy/helm/elido \
  -f ./deploy/helm/elido/values-selfhost.yaml --set image.tag=NEW_TAG

Les mises à jour progressives utilisent maxSurge: 1 et maxUnavailable: 0, et helm -n elido rollback elido <revision> remet les Deployments en place sans toucher aux volumes ni aux secrets. Avec une réplique par service, attendez-vous à de brèves interruptions sur les charges qui ne sont pas sans état.

Pièges connus

Si un DPO est la raison de votre présence, l'option hébergée suffit peut-être déjà : ses données principales sont dans l'UE, et le guide de la résidence dans l'UE liste ce qui est traité en dehors. Pour le volet latence de l'exploitation de vos propres redirections, voir l'article sur les POP edge.

À lire aussi sur le blog

• Comparatif des raccourcisseurs d'URL auto-hébergés
• Alternatives à Bitly et écart de fonctionnalités
• Tenir un p95 sous 15 ms pour les redirections
• Résidence des données dans l'UE pour les outils marketing
• POP edge contre routage DNS seul