6 Min. LesezeitEngineering

Elido auf k3s: Was das Helm-Chart deployt und was nicht

Konkrete Anleitung zum Elido-Helm-Chart auf einem k3s-Knoten: Secrets, Ingress, Installation, erster Nutzer, Upgrades, Lizenz und was das Chart auslässt

Marius Voß
DevRel · edge infra

Elido liefert ein Helm-Chart, das den gesamten Stack auf einem Kubernetes-Cluster deployt, und dieser Beitrag geht es auf einem einzelnen k3s-Knoten durch. Vor den Befehlen der Teil, der entscheidet, ob Sie weiterlesen sollten: Elido ist nicht Open Source, und Self-Hosting ist kein Produkt, das wir verkaufen. Das Repository hat keine Lizenzdatei, sodass außerhalb des Unternehmens niemand eine Lizenz hat, es auszuführen oder zu ändern. Das Chart ist Deployment-Werkzeug, das wir im Repo halten, und die Befehle unten stammen daraus und aus dem Runbook daneben (abgerufen am 2026-10-25). Nutzen Sie diesen Leitfaden, wenn Sie an Elido arbeiten, wenn Sie eine schriftliche Vereinbarung mit uns haben oder wenn Sie genau sehen wollen, was der Betrieb der Plattform bedeutet.

Wählen Sie noch zwischen Projekten, die Sie tatsächlich herunterladen können, beginnen Sie mit dem Vergleich selbst gehosteter Shortener. Er behandelt YOURLS, Shlink, Kutt und Dub und wiederholt keinen der Schritte hier.

Was das Chart ist und was nicht

Das Chart liegt unter deploy/helm/elido. Seine Metadaten zeigen auf ein GitHub-Repository unter der Organisation elidoapp; eine nicht authentifizierte Anfrage an diese Adresse lieferte am 2026-10-25 404, erwarten Sie also nicht, es aus dem Internet klonen zu können. Die Values-Datei zieht Images aus ghcr.io/elidoapp, und ein Kommentar darin nennt die Registry öffentlich. Anonyme Pulls konnte ich nicht bestätigen, behandeln Sie das also als ungeprüft.

Das Chart ist außerdem jung. Seine Version ist 0.1.0, und seine eigene Beschreibung nennt das Ziel "single-region k3s cluster on a beefy VM." Einige Dinge, die man bei einem Kubernetes-Chart voraussetzt, fehlen, und eine frühere Fassung dieses Beitrags hat manche davon fälschlich beschrieben:

  • Keine Hochverfügbarkeit. Jedes zustandsbehaftete Set läuft mit einem Replikat.
  • Keine Backup-Jobs. Das Runbook sagt es und verweist Sie auf Velero, k8up oder Snapshots des Anbieters.
  • Keine Monitoring-Objekte, Dashboards oder Autoscaler.
  • Kein Multi-Region-Edge. Das Preset fasst Weiterleitungen in einer Flotte zusammen.

Brauchen eine Aufsichtsbehörde oder Ihre eigene Richtlinie diese, planen Sie die Arbeit ein, sie selbst zu ergänzen.

Was das Self-Host-Preset deployt

values-selfhost.yaml stutzt alles auf einen Host mit 4 Kernen und 8 GB zurecht. Es fährt ein Replikat jedes Anwendungs-Workloads: api-core, analytics-api, click-ingester, url-scanner, notification, bio-renderer, billing, das Dashboard (web), die Marketing-Site und eine edge-Flotte, die für jeden Host antwortet. Ein Identitätsdienst übernimmt Registrierung und Sitzungen.

Dahinter stehen sechs zustandsbehaftete Sets mit persistenten Volumes: Postgres (20Gi im Preset), Redis (2Gi), ein Spaltenspeicher für Klick-Ereignisse (30Gi), ein Event-Bus (10Gi), Objektspeicher (20Gi) und ein Suchindex (5Gi). Redis ist hier eine einzelne Instanz mit Append-only-Persistenz, kein Cluster. Mehrere frühere eigenständige Dienste, darunter Domain-Verwaltung, Webhook-Zustellung und Suchindexierung, laufen jetzt innerhalb von api-core, weshalb die Workload-Liste kürzer ist, als ältere Doku nahelegt.

Schichten des Self-Host-Presets auf einem k3s-Knoten: ein Ingress-Controller, eine Edge-Redirect-Flotte, zehn Anwendungs-Workloads mit einem Replikat und sechs zustandsbehaftete Sets mit einem Replikat für die Datenspeicher

Voraussetzungen

Das Runbook verlangt Kubernetes 1.27 oder neuer, Helm 3.13 oder neuer und kubectl, auf den Cluster gerichtet. Außerdem brauchen Sie DNS-Einträge für die Hostnamen von Dashboard, API, Weiterleitung und Bio, ein SMTP-Relay, das der Cluster erreicht, und einen Ingress-Controller der Klasse caddy.

k3s bringt Traefik mit, das mit dem Controller, den Sie gleich installieren, um die Ports 80 und 443 konkurrieren würde. Deaktivieren Sie es bei der Installation von 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 Schritt für Schritt

Fünf Installationsschritte für das Elido-Chart auf k3s: Namespace und Secrets, Ersetzen der Platzhalter, Ingress-Controller, helm upgrade install mit dem Self-Host-Preset und Hochstufen des ersten Nutzers in Postgres

Legen Sie den Namespace an und erzeugen Sie die Secrets. Das Skript generiert Zufallswerte für das Datenbankpasswort, die Cookie- und Cipher-Schlüssel des Identitätsdienstes, den Schlüssel zur Slug-Verschleierung und den Pepper der API-Schlüssel und legt Platzhalter für SMTP und LiqPay an. Bereits vorhandene Secrets überspringt es, sofern Sie nicht --rotate übergeben.

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

Das Skript gibt am Ende das Postgres-Passwort aus. Speichern Sie es. Ersetzen Sie dann den SMTP-Platzhalter, bevor sich jemand registriert; dasselbe Muster funktioniert für elido-liqpay, wenn Sie Zahlungen annehmen:

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 -

Installieren Sie den Ingress-Controller mit aktiviertem On-Demand-TLS:

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

Installieren Sie nun Elido selbst. Pinnen Sie image.tag auf ein von Ihnen gewähltes Release. Das Beispiel des Runbooks nutzt latest, was Upgrades und Rollbacks schwer nachvollziehbar macht.

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

Migrationen laufen als Init-Container für die Dienste, die sie brauchen, und als Pre-Install-Job für den Identitätsdienst. Schlägt eine Migration fehl, bedienen die neuen Pods nie Traffic.

Erster Nutzer und eigene Domains

Öffnen Sie https://app.your-domain.com/signup und registrieren Sie sich. Der Identitätsdienst legt das Konto an, und api-core speichert eine Nutzerzeile. Nichts macht diesen Nutzer bisher zum Owner, legen Sie also Workspace und Mitgliedschaft von Hand an, was Ihnen auch die Installationshinweise des Charts selbst sagen:

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

Eigene Domains nutzen On-Demand-TLS. Ein Kunde fügt im Dashboard links.brand.com hinzu und lenkt dann einen CNAME auf den Host, den Sie in EDGE_CNAME_TARGET setzen (eine api-core-Variable, die standardmäßig auf Elidos eigenen Edge-Hostnamen steht, ändern Sie sie also). Bei der ersten HTTPS-Anfrage ruft der Ingress-Controller GET /v1/caddy/ask auf api-core auf. Ein 200 stellt das Zertifikat aus; ein 403 bedeutet, die Domain ist nicht verifiziert. Debuggen Sie mit kubectl -n elido logs deploy/api-core | grep caddy/ask.

Backups, Upgrades und Rollback

Backups liegen bei Ihnen. Die Empfehlung des Runbooks sind tägliche Snapshots des Postgres-Volumes (data-postgres-0) und wöchentliche für den Spaltenspeicher (data-clickhouse-0), da Klickdaten innerhalb ihres Aufbewahrungsfensters aus dem Event-Bus wiederholt werden können. Das Volume des Event-Bus braucht kein Backup. Um ein verwaltetes Postgres zu nutzen, setzen Sie postgres.enabled=false und lenken die url des Secrets elido-postgres darauf. Führen Sie eine Wiederherstellung in einen Scratch-Namespace durch, bevor Sie sich auf irgendetwas davon verlassen.

Upgrades sind ein Befehl mit einem neuen Tag:

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

Rolling Updates nutzen maxSurge: 1 und maxUnavailable: 0, und helm -n elido rollback elido <revision> tauscht die Deployments zurück, ohne Volumes oder Secrets anzufassen. Mit einem Replikat pro Dienst sind kurze Aussetzer bei Workloads zu erwarten, die nicht zustandslos sind.

Bekannte Stolpersteine

SymptomWahrscheinliche UrsacheLösung
Der Identitäts-Migrationsjob scheitert mit database "kratos" does not existPostgres legte elido an, aber nicht diese DatenbankCREATE DATABASE kratos; per psql, dann erneut helm upgrade
api-core läuft in eine Absturzschleife und fragt nach KRATOS_PUBLIC_URLauth.kratos.enabled=false ohne OverrideDen Identitätsdienst wieder aktivieren oder die Variable auf Ihren IdP setzen
Das Dashboard liefert beim ersten Laden 502Zertifikat noch nicht ausgestelltLogs des Ingress-Controllers beobachten; die erste Ausstellung kann etwa 30 Sekunden dauern
Weiterleitungen liefern 503Die Edge-Flotte erreicht Redis nichtPrüfen, dass die URL im Secret elido-redis auf den clusterinternen Dienst zeigt
Nach einem Neustart laufen alle Dienste in AbsturzschleifenPVCs nicht gebundenkubectl get pv,pvc -n elido und prüfen, ob der local-path-Provisioner läuft

Ist ein Datenschutzbeauftragter der Grund, warum Sie hier sind, genügt die gehostete Option womöglich bereits: Ihre primären Daten liegen in der EU, und der Leitfaden zur EU-Residenz listet, was außerhalb verarbeitet wird. Zur Latenzseite beim Betrieb eigener Weiterleitungen siehe den Beitrag zu Edge-POPs.

Weitere Artikel im Blog

Häufig gestellte Fragen

Kann ich Elido selbst hosten?

Nicht als Produkt, das wir heute anbieten. Das Repository hat ein Helm-Chart und ein Runbook, die wir selbst nutzen, aber es hat keine Lizenzdatei, sodass außerhalb von Elido niemand lizenziert ist, den Code auszuführen oder zu ändern, und es gibt weder einen veröffentlichten Self-Hosted-Plan noch Support. Haben Sie eine harte Anforderung an den Datenstandort, kontaktieren Sie uns, und wir besprechen es als individuelle Vereinbarung.

Ist Elido Open Source?

Nein. Das Repository enthält keine Lizenzdatei, was bedeutet, dass alle Rechte vorbehalten sind. Einige Client-Pakete (die SDKs, die API-Typen und der MCP-Server) tragen eigene LICENSE-Dateien, die Plattform selbst, einschließlich des Charts, das dieser Beitrag beschreibt, aber nicht. Jede Seite, die für Self-Hosting Apache 2.0 nennt, ist falsch.

Was braucht das Self-Host-Preset, um zu laufen?

Das Runbook verlangt Kubernetes 1.27 oder neuer, Helm 3.13 oder neuer, Wildcard-DNS für die Hosts von Dashboard, API, Weiterleitung und Bio, ein SMTP-Relay und einen Ingress-Controller der Klasse caddy. Eine VM mit 4 Kernen und 8 GB wird als ausreichend für einen Smoke-Test beschrieben. Die Produktion will laut demselben Runbook drei oder mehr Knoten mit je 8 Kernen und 16 GB.

Enthält das Chart Backups, Monitoring oder Hochverfügbarkeit?

Nein. Das Chart deployt Postgres, Redis, den Spaltenspeicher, den Event-Bus, den Objektspeicher und die Suche als zustandsbehaftete Sets mit einem Replikat und persistenten Volumes. Backups bleiben Ihrem Cluster-Tooling überlassen, etwa Velero oder k8up, und das Chart hat keine Monitoring-Objekte, kein Autoscaling und kein Failover. Frühere Fassungen dieses Beitrags beschrieben sie, sie waren nicht im Chart.

Wie funktionieren eigene Domains bei einer selbst gehosteten Installation?

Der Ingress-Controller fragt api-core unter /v1/caddy/ask, bevor er ein Zertifikat für einen unbekannten Hostnamen ausstellt, und api-core antwortet aus seiner Liste verifizierter Domains. Sie lenken die CNAMEs Ihrer Kunden auf den in EDGE_CNAME_TARGET gesetzten Host. Liefert dieser Endpunkt 403, wird das Zertifikat nie ausgestellt, prüfen Sie daher zuerst die api-core-Logs.

Wie führe ich ein Upgrade oder Rollback durch?

Führen Sie helm upgrade mit derselben Values-Datei und einem neuen image.tag aus. Deployments nutzen maxSurge 1 und maxUnavailable 0, und Datenbankmigrationen laufen, bevor neue Pods Traffic bedienen, sodass eine fehlgeschlagene Migration die alten Pods weiterlaufen lässt. helm rollback auf eine frühere Revision tauscht die Deployments und lässt Ihre Daten-Volumes und Secrets unberührt.

Elido testen

URL einfügen, kurzer Link in Sekunden

Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.

Keine Anmeldung nötig. Kostenlos registrieren für 50 Links im Monat.

Elido testen

URL-Shortener mit EU-Hosting: eigene Domains, tiefe Analytik und eine offene API. Kostenloser Tarif - keine Kreditkarte nötig.

Tags
self host elido
k3s
helm chart
kubernetes url shortener
self hosted url shortener
data residency

Weiterlesen