Autohospedar um encurtador de URL costumava ser um projeto de fim de semana. PHP mais MySQL mais um controlador de redirecionamento e você tinha algo parecido com o Bitly de 2010. A categoria não parou no tempo; as opções open source modernas são mais capazes que o YOURLS, mais exigentes para operar do que o projeto de fim de semana, e ainda significativamente atrás de um produto hospedado em termos de superfície de análise de dados. Este post é o panorama honesto — o que cada opção open source realmente entrega, o que você abre mão em comparação com um fornecedor de serviço hospedado e onde os números tornam vantajoso pagar outra pessoa para operar a camada de redirecionamento.
O público-alvo são equipes de engenharia ou operadores técnicos considerando a autohospedagem. O artigo base sobre alternativas ao bitly cobre a comparação mais ampla; este post foca especificamente no lado open source. O guia de autohospedagem do Elido no k3s cobre o caso em que você deseja autohospedar o próprio Elido em vez de uma alternativa de terceiros.
O que você está assumindo#
Um encurtador de URL parece deceptivamente pequeno. Um banco de dados, um processo de redirecionamento, um dashboard para gerenciar links. Em produção, o formato simples esconde quatro superfícies operacionais:
A camada de redirecionamento. Este é o caminho crítico. Cada URL encurtada clicada em qualquer lugar na internet eventualmente acessa este código. Ele precisa ser rápido (p95 abaixo de 15ms se você se importa com a experiência do usuário), altamente disponível (tempo de inatividade aqui quebra todos os links que você já enviou) e distribuído globalmente se seus usuários não estiverem em uma única geografia. O post sobre p95 de redirecionamento < 15ms cobre o que realmente significa ser rápido e como isso é alcançado.
O pipeline de análise de cliques. Gravar, armazenar e consultar eventos de cliques. Em volume, este é um sistema diferente da camada de redirecionamento — normalmente Kafka ou Redpanda para ingestão, ClickHouse ou BigQuery para armazenamento, uma API separada para consultas. A maioria dos encurtadores open source ignora isso completamente e armazena os cliques no mesmo banco de dados relacional que mantém os links, o que funciona em pequenos volumes e falha assim que você ultrapassa alguns milhões de cliques por mês.
O dashboard. Interface para criar, editar, organizar e analisar links. Onde a maioria dos projetos open source gasta a maior parte do seu trabalho em funcionalidades, e onde a lacuna para produtos hospedados é a menor — a maioria dos dashboards open source é decente.
A mecânica de domínios personalizados. Emissão de TLS, validação de DNS, renovação de certificado, provisionamento de certificado sob demanda quando um novo domínio aponta para o cluster. É aqui que o custo operacional se complica; executar ACME em escala é genuinamente difícil.
Uma configuração autohospedada significa que você opera todas as quatro superfícies. Um produto hospedado significa que você não opera nenhuma delas (em troca de pagar um fornecedor e aceitar sua postura de residência de dados). A questão é qual conjunto de compensações funciona melhor para sua situação.
As opções open source atuais#
Cinco projetos que valem a pena considerar, em ordem aproximada de atividade em 22/05/2026.
YOURLS#
O pioneiro. PHP, MySQL, servidor único, arquitetura de plugins. O YOURLS existe desde 2009 e continua sendo o encurtador open source mais utilizado por uma ampla margem. Pontos fortes: simples de instalar, roda onde quer que o PHP rode, ecossistema de plugins maduro. Pontos fracos: a análise de dados é mínima (contagem de cliques por link, IP geográfico via serviço externo), não possui suporte nativo a domínios personalizados além de rodar múltiplas instâncias, não tem limitação de taxa de API, não possui conceito de equipes ou funções.
O YOURLS é uma boa escolha se você deseja uma ferramenta de links curtos pessoal com um único proprietário e tráfego modesto. É a escolha errada se você tem uma equipe, domínios personalizados para clientes ou análises de dados que precisam sobreviver ao banco de dados. O post Elido vs YOURLS cobre a diferença de funcionalidades em detalhes.
Shlink#
PHP novamente, mas mais moderno. O Shlink vem com uma API REST, suporte a múltiplos domínios, uma interface web separada e atualizações em tempo real baseadas em Mercure. A análise de dados é mais capaz que a do YOURLS — geolocalização por visita, dispositivo, séries temporais — mas armazenada no mesmo banco de dados MySQL/Postgres que os links. A equipe do Shlink é receptiva e o projeto tem lançado versões consistentes desde 2019.
O Shlink é uma escolha razoável se você estiver disposto a operar uma configuração PHP-FPM + MySQL/Postgres e não precisar que a análise de dados escale para além de alguns milhões de cliques por mês. A camada de redirecionamento de processo único torna-se um gargalo em volumes maiores; o escalonamento horizontal é possível, mas exige que você coloque um balanceador de carga e cache compartilhado na frente.
Polr#
PHP leve. O Polr era popular por volta de 2017-2019 e o projeto está em grande parte inativo agora, embora existam forks. Funcionalmente semelhante ao YOURLS, mas com uma API mais limpa. Se você estiver começando hoje, a falta de manutenção recente é uma preocupação significativa — patches de segurança não chegam dentro de um cronograma.
Kutt#
Node.js, Postgres, Redis. O Kutt é o encurtador de "stack moderna" mais ativo. Vem com recurso de domínio personalizado, links protegidos por senha, expiração e análise básica. A superfície de análise de dados é mais utilizável que a do YOURLS, mas ainda baseada em banco de dados relacional.
O perfil operacional do Kutt é mais pesado que o do YOURLS — Node + Postgres + Redis significa três serviços para rodar em vez de um — mas a stack moderna oferece melhor desempenho por dólar em volumes moderados. Se sua equipe estiver confortável com Node, o Kutt é a escolha mais segura de "queremos um encurtador open source moderno" hoje.
Dub-self-hosted#
A Dub.co publica uma versão autohospedada do seu produto comercial. O Dub utiliza uma stack de Next.js + Postgres + Redis + Tinybird com um dashboard elegante e análise de dados decente. A complexidade operacional é a mais alta das cinco — Tinybird é um serviço ClickHouse hospedado na implantação padrão, e substituí-lo por um ClickHouse autohospedado é um projeto significativo.
O Dub-self-hosted é a escolha certa se você tem uma equipe confortável operando uma stack web moderna e deseja a aparência e a sensação de um produto comercial atual. É a escolha errada se seu orçamento operacional for restrito ou se sua equipe não for fluente em Next.js.
A matriz dos fornecedores#
Uma classificação em quatro eixos sobre análise de dados, operações, domínios personalizados e capacidade de escalonamento. As notas são grosseiras — A a D — baseadas no que o projeto entrega pronto para uso, não no que é possível com trabalho personalizado.
| Projeto | Análise de dados | Operações | Domínios personalizados | Escalabilidade | Stack |
|---|---|---|---|---|---|
| YOURLS | D | A | C (manual) | D | PHP + MySQL |
| Shlink | C | B | B | C | PHP + Postgres |
| Polr | D | B | C | D | PHP + MySQL |
| Kutt | C | C | B | C | Node + Postgres + Redis |
| Dub-self-hosted | B | D | A | B | Next.js + Postgres + Redis + Tinybird |
| Elido-self-hosted | A | C | A | A | Go + Postgres + Redis + ClickHouse + Redpanda |
Dois padrões surgem da matriz. Primeiro, a análise de dados melhora com a complexidade da stack — projetos que armazenam cliques em um banco de dados relacional junto com os links pontuam menos do que projetos que entregam um pipeline de análise de dados dedicado. Segundo, domínios personalizados são razoavelmente bem atendidos por todos, exceto pelo YOURLS, porque a automação ACME tornou-se comoditizada.
O custo oculto: análise de dados que escala#
Eventos de clique acumulam-se mais rápido do que as pessoas esperam. Um único link com 100 cliques por dia gera 36.500 cliques por ano — gerenciável em qualquer banco de dados relacional. Um único link com 100.000 cliques por dia gera 36,5 milhões de cliques por ano, e é aí que o MySQL ou Postgres começa a sofrer. Um pequeno produto SaaS com mil links ativos com média de 1.000 cliques por dia cada é um bilhão de cliques por ano, e nesse ponto qualquer armazenamento relacional falha sem um ajuste significativo.
Os cinco projetos open source acima (exceto Dub e Elido) armazenam cliques no mesmo banco de dados que os links. Os padrões de consulta também são diferentes do OLTP típico — "me dê a contagem de cliques por dia para este link nos últimos 30 dias" é uma verificação de intervalo com agregação, o pior cenário para um banco de dados ajustado para OLTP.
Você pode resolver isso. O ClickHouse lida confortavelmente com cargas de trabalho de análise de bilhões de eventos; o post sobre por que o ClickHouse cobre o raciocínio. Mas adicionar o ClickHouse à sua stack significa outro serviço para operar, outro pipeline de backup, outra superfície de monitoramento. Se o seu volume de links for pequeno (menos de 10 milhões de cliques por mês), a abordagem de banco de dados relacional funciona por anos; se o seu volume for maior, a camada de análise de dados torna-se um projeto por si só.
O custo oculto: POPs de borda (Edge POPs) e latência#
Um encurtador autohospedado em servidor único atende redirecionamentos a partir de uma única localização geográfica. Se seus usuários estão em três continentes, a latência do lado distante é de 200-300ms — visível em termos de experiência do usuário.
As correções:
- Anycast IPs na frente de múltiplos POPs. Prático apenas se você tiver seu próprio sistema autônomo (AS) e configuração BGP. Não é realista para a maioria das implantações autohospedadas.
- Roteamento geográfico baseado em DNS. Cloudflare, Route53 ou NS1 podem rotear usuários para o POP mais próximo. Funciona, mas adiciona uma latência de busca de DNS sobre o redirecionamento.
- CDN na frente. Cloudflare ou Fastly na frente do processo de redirecionamento. A CDN faz cache de respostas GET; redirecionamentos são armazenáveis em cache, mas a lógica de invalidação de cache quando um destino de link muda não é trivial.
- Um POP por região. Execute o processo de redirecionamento em Frankfurt, Ashburn e Singapura, com um banco de dados compartilhado ou consistência eventual entre eles. Este é o caminho de produção. Também é significativamente mais trabalho do que autohospedar em uma única região.
O post sobre Edge POPs vs roteamento apenas por DNS cobre a escolha em detalhes. A maioria das implantações autohospedadas para em uma região porque o trabalho multirregional é um projeto separado.
Quando a autohospedagem faz sentido#
Três cenários:
A soberania de dados é inegociável. Um setor regulado — saúde, finanças, governo — exige que os dados vivam em sua infraestrutura. A postura do produto hospedado (mesmo um residente na UE) não é suficiente porque os dados precisam viver dentro do seu limite de segurança. Autohospedar é a resposta correta aqui. O custo de manutenção é o preço da conformidade.
O volume é pequeno e você é técnico. Uma equipe gerenciando seus próprios links curtos para uso interno, com menos de um milhão de cliques por mês, sem domínios personalizados para clientes externos e um desenvolvedor que pode manter uma stack Docker Compose ativa. YOURLS ou Shlink se encaixam perfeitamente. O produto hospedado é um exagero para esse escopo.
Você está construindo um produto derivado. Se seus links curtos são a interface de um produto maior que você está construindo — digamos, uma plataforma de venda de ingressos onde a URL curta aponta para o ingresso — a autohospedagem permite acoplar a camada de redirecionamento com sua lógica de negócios de maneiras que o fornecedor hospedado não consegue igualar. A maioria dos usuários que autohospedam o Dub está nesta categoria.
Quando a autohospedagem deixa de fazer sentido#
Três cenários do outro lado:
Você precisa de uma análise de dados decente. Quando seus stakeholders perguntam "como os cliques se dividem por país nos últimos 90 dias para estas 50 campanhas?", o armazenamento em banco de dados relacional falha. Você ou constrói o pipeline de análise de dados (um projeto de vários meses) ou paga a um fornecedor hospedado que entrega isso pronto para uso.
Você precisa de domínios personalizados para muitos clientes. Executar ACME para um domínio é trivial. Executar ACME para 10.000 domínios fornecidos pelo cliente, com revogação, renovação e provisionamento sob demanda, é uma superfície de engenharia séria. O post sobre TLS de domínio personalizado cobre o mecanismo; construir isso internamente é um trimestre de trabalho, não uma tarde.
O tempo da sua equipe é o gargalo. Um encurtador autohospedado custa aproximadamente 4 a 8 horas de engenheiro por mês em estado estacionário depois de configurado, além do tempo de cada interrupção e cada atualização. A uma taxa horária de desenvolvedor de $100, isso representa $400-800/mês antes de contabilizar a inevitável sessão de depuração de interrupção de duas semanas a cada trimestre. Um fornecedor hospedado a $300-500/mês começa a parecer barato.
O cálculo do ponto de equilíbrio é sensível a dois insumos: quanto vale o tempo da sua equipe e com que frequência você enfrenta problemas operacionais. Para uma equipe que já executa seu próprio cluster k3s, o custo marginal de adicionar um encurtador é baixo. Para uma equipe que atualmente não opera nenhum serviço de produção, hospedar o encurtador atrai custos adjacentes (monitoramento, registro, backups) que aumentam a conta.
Uma árvore de decisão pragmática#
A decisão em cinco perguntas:
- Você é obrigado por regulamentação ou política a manter os dados de link na infraestrutura que você controla? Se sim, autohospede. Pare por aqui.
- Seu volume de cliques atual ou esperado excede 50 milhões de cliques por mês dentro de 24 meses? Se sim, planeje uma camada dedicada de análise de dados — o que tende para o Dub-self-hosted ou Elido-self-hosted, ou um fornecedor hospedado com análise de dados baseada em ClickHouse.
- Você precisa de domínios personalizados para mais de 10 clientes? Se sim, o custo da automação ACME é significativo — mesmos projetos acima, ou hospedado.
- Sua equipe opera atualmente outros serviços de produção com escala de plantão (on-call)? Se não, o custo operacional da autohospedagem é maior do que parece.
- Links curtos são uma superfície estratégica do seu produto (ex: você está construindo uma plataforma de integração) ou uma utilidade de suporte (ex: links internos da equipe)? Superfície estratégica = autohospedagem ou hospedado com integração profunda; utilidade de suporte = o que for mais barato.
A maioria das equipes acabará escolhendo a opção hospedada após passar por essa árvore. Isso é aceitável. A autohospedagem é a resposta certa quando as restrições são claras; é o padrão errado quando não são.
Leitura relacionada#
- Alternativas ao Bitly — a lacuna real de funcionalidades — o artigo base sobre fornecedores hospedados.
- Autohospedando o Elido no k3s — o guia — o passo a passo operacional para o lado do Elido.
- Elido vs YOURLS — o comparativo direto contra a opção open source mais utilizada.
- Por que o ClickHouse para análise de cliques — o raciocínio sobre a camada de análise de dados.
- Edge POPs vs roteamento apenas por DNS — o caminho multirregional.
- Superfície do produto:
/solutions/developerse/pricing. - Arquitetura: documentação de edge-redirect.