O Elido distribui um chart do Helm que implanta toda a stack em um único cluster Kubernetes, e este post o percorre em um único nó k3s. Antes dos comandos, a parte que decide se você deve continuar lendo: o Elido não é código aberto e o self-hosting não é um produto que vendemos. O repositório não tem arquivo de licença, então ninguém fora da empresa tem licença para executá-lo ou modificá-lo. O chart é uma ferramenta de implantação que mantemos no repositório, e os comandos abaixo vêm dele e do runbook ao lado (acesso em 2026-10-25). Use este guia se você trabalha no Elido, se tem um acordo por escrito conosco ou se quer ver exatamente o que envolve rodar a plataforma.
Se você ainda está escolhendo entre projetos que realmente pode baixar, comece pela comparação de encurtadores self-hosted. Ela cobre YOURLS, Shlink, Kutt e Dub e não repete nenhum dos passos daqui.
O que o chart é e o que não é
O chart fica em deploy/helm/elido. Os metadados dele apontam para um repositório do GitHub sob a organização elidoapp; uma requisição não autenticada a esse endereço retornou 404 em 2026-10-25, então não espere cloná-lo pela internet. O arquivo de valores puxa imagens de ghcr.io/elidoapp, e um comentário nele chama o registro de público. Não consegui confirmar pulls anônimos, então trate isso como não verificado.
O chart também é jovem. A versão dele é 0.1.0, e a própria descrição chama o alvo de "cluster k3s de região única em uma VM parruda". Algumas coisas que as pessoas presumem vir com um chart de Kubernetes estão ausentes, e uma versão anterior deste post descreveu algumas delas por engano:
- Sem alta disponibilidade. Todo stateful set roda com uma réplica.
- Sem jobs de backup. O runbook diz isso e manda você usar Velero, k8up ou snapshots do provedor.
- Sem objetos de monitoramento, painéis ou autoescaladores.
- Sem borda multirregional. O preset reúne os redirecionamentos em uma só frota.
Se um regulador ou a sua própria política exige essas coisas, reserve orçamento para acrescentá-las você mesmo.
O que o preset de self-host implanta
O values-selfhost.yaml enxuga tudo para caber em um host de 4 núcleos e 8 GB. Ele roda uma réplica de cada carga de trabalho da aplicação: api-core, analytics-api, click-ingester, url-scanner, notification, bio-renderer, billing, o painel (web), o site de marketing e uma frota edge que responde por todos os hosts. Um serviço de identidade cuida do cadastro e das sessões.
Por trás deles ficam seis stateful sets com volumes persistentes: Postgres (20Gi no preset), Redis (2Gi), um armazenamento colunar para eventos de clique (30Gi), um barramento de eventos (10Gi), armazenamento de objetos (20Gi) e um índice de busca (5Gi). O Redis aqui é uma instância única com persistência append-only, não um cluster. Vários serviços que antes eram separados, incluindo gerenciamento de domínios, entrega de webhooks e indexação de busca, agora rodam dentro do api-core, e é por isso que a lista de cargas de trabalho é mais curta do que a documentação antiga sugere.
Pré-requisitos
O runbook pede Kubernetes 1.27 ou mais novo, Helm 3.13 ou mais novo e kubectl apontando para o cluster. Você também precisa de registros DNS para os hostnames do painel, da API, do redirecionamento e do bio, um relay SMTP que o cluster consiga alcançar e um controlador de ingress da classe caddy.
O k3s inclui o Traefik, que disputaria as portas 80 e 443 com o controlador que você está prestes a instalar. Desative-o ao instalar o 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
Instalação, passo a passo
Crie o namespace e gere os segredos. O script gera valores aleatórios para a senha do banco de dados, as chaves de cookie e de cifra do serviço de identidade, a chave de ofuscação de slugs e o pepper das chaves de API, e cria placeholders para SMTP e LiqPay. Ele pula segredos que já existem, a menos que você passe --rotate.
kubectl create namespace elido
./deploy/helm/elido/scripts/bootstrap-secrets.sh elido
O script imprime a senha do Postgres no final. Guarde-a. Depois substitua o placeholder de SMTP antes que alguém se cadastre; o mesmo padrão vale para elido-liqpay se você aceitar pagamentos:
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 -
Instale o controlador de ingress com o TLS sob demanda ativado:
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
Agora instale o próprio Elido. Fixe image.tag em um lançamento que você escolheu. O exemplo do runbook usa latest, o que dificulta raciocinar sobre atualizações e reversões.
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
As migrações rodam como init containers para os serviços que precisam delas e como um job de pré-instalação para o serviço de identidade. Se uma migração falha, os novos pods nunca recebem tráfego.
Primeiro usuário e domínios personalizados
Abra https://app.your-domain.com/signup e cadastre-se. O serviço de identidade cria a conta e o api-core grava uma linha de usuário. Nada torna esse usuário um proprietário ainda, então crie um workspace e uma associação à mão, que é o que as próprias notas de instalação do chart mandam fazer:
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
Os domínios personalizados usam TLS sob demanda. Um cliente adiciona links.brand.com no painel e depois aponta um CNAME para o host que você definiu em EDGE_CNAME_TARGET (uma variável do api-core cujo padrão é o hostname de borda do próprio Elido, então mude-a). Na primeira requisição HTTPS, o controlador de ingress chama GET /v1/caddy/ask no api-core. Um 200 emite o certificado; um 403 significa que o domínio não está verificado. Depure com kubectl -n elido logs deploy/api-core | grep caddy/ask.
Backups, atualizações e reversão
Os backups são por sua conta. A orientação do runbook é snapshots diários do volume do Postgres (data-postgres-0) e semanais do armazenamento colunar (data-clickhouse-0), já que os dados de cliques podem ser reproduzidos a partir do barramento de eventos dentro da janela de retenção dele. O volume do barramento de eventos não precisa de backup. Para usar um Postgres gerenciado, defina postgres.enabled=false e aponte a url do segredo elido-postgres para ele. Execute uma restauração em um namespace de teste antes de confiar em qualquer coisa disso.
As atualizações são um comando com uma nova tag:
helm -n elido upgrade elido ./deploy/helm/elido \
-f ./deploy/helm/elido/values-selfhost.yaml --set image.tag=NEW_TAG
As atualizações graduais usam maxSurge: 1 e maxUnavailable: 0, e helm -n elido rollback elido <revision> troca os Deployments de volta sem tocar nos volumes ou segredos. Com uma réplica por serviço, espere breves oscilações nas cargas de trabalho que não são stateless.
Problemas conhecidos
| Sintoma | Causa provável | Correção |
|---|---|---|
O job de migração de identidade falha com database "kratos" does not exist | O Postgres criou elido, mas não esse banco | CREATE DATABASE kratos; via psql e depois helm upgrade de novo |
O api-core entra em crash loop pedindo KRATOS_PUBLIC_URL | auth.kratos.enabled=false sem uma substituição | Reative o serviço de identidade ou defina a variável com o seu IdP |
| O painel dá 502 no primeiro carregamento | O certificado ainda não foi emitido | Acompanhe os logs do controlador de ingress; a primeira emissão pode levar cerca de 30 segundos |
| Os redirecionamentos retornam 503 | A frota de borda não consegue alcançar o Redis | Confira se a URL do segredo elido-redis aponta para o serviço dentro do cluster |
| Tudo entra em crash loop depois de uma reinicialização | PVCs sem vínculo | kubectl get pv,pvc -n elido e confirme que o provisionador local-path está de pé |
Se um DPO é a razão de você estar aqui, a opção hospedada pode já bastar: os dados principais dela ficam na UE, e o guia de residência na UE lista o que é processado fora dela. Para o lado da latência de rodar os seus próprios redirecionamentos, veja o post sobre POPs de borda.
Relacionados no blog
Perguntas frequentes
Posso hospedar o Elido por conta própria?
Não como um produto que oferecemos hoje. O repositório tem um chart do Helm e um runbook que nós mesmos usamos, mas não tem arquivo de licença, então ninguém fora do Elido tem licença para executar ou modificar o código, e não há plano self-hosted publicado nem suporte. Se você tem um requisito rígido de localização de dados, entre em contato e trataremos como um arranjo personalizado.
O Elido é de código aberto?
Não. O repositório não contém arquivo de licença, o que significa que todos os direitos são reservados. Alguns pacotes de cliente (os SDKs, os tipos da API e o servidor MCP) trazem seus próprios arquivos LICENSE, mas a plataforma em si, incluindo o chart que este post descreve, não. Qualquer texto de site que diga Apache 2.0 para self-hosting está errado.
O que o preset de self-host precisa para rodar?
O runbook pede Kubernetes 1.27 ou mais novo, Helm 3.13 ou mais novo, DNS curinga para os hosts do painel, da API, do redirecionamento e do bio, um relay SMTP e um controlador de ingress da classe caddy. Uma VM de 4 núcleos e 8 GB é descrita como suficiente para um teste rápido. A produção, segundo o mesmo runbook, quer três ou mais nós com 8 núcleos e 16 GB cada.
O chart inclui backups, monitoramento ou alta disponibilidade?
Não. O chart implanta Postgres, Redis, o armazenamento colunar, o barramento de eventos, o armazenamento de objetos e a busca como stateful sets de réplica única com volumes persistentes. Os backups ficam a cargo das ferramentas do seu cluster, como Velero ou k8up, e o chart não tem objetos de monitoramento, autoescalonamento nem failover. Versões anteriores deste post os descreviam; eles não estavam no chart.
Como funcionam os domínios personalizados em uma instalação self-hosted?
O controlador de ingress consulta o api-core em /v1/caddy/ask antes de emitir um certificado para um hostname desconhecido, e o api-core responde a partir da sua lista de domínios verificados. Você aponta os CNAMEs dos clientes para o host definido em EDGE_CNAME_TARGET. Se esse endpoint retornar 403, o certificado nunca é emitido, então confira primeiro os logs do api-core.
Como faço para atualizar ou reverter?
Execute helm upgrade com o mesmo arquivo de valores e um novo image.tag. Os Deployments usam maxSurge 1 e maxUnavailable 0, e as migrações de banco de dados rodam antes de os novos pods atenderem tráfego, então uma migração que falha deixa os pods antigos rodando. helm rollback para uma revisão anterior troca os Deployments e deixa seus volumes de dados e segredos intactos.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Sem registro. Crie uma conta grátis e obtenha 50 links por mês.