Auto-hospedar un acortador de URL solía ser un proyecto de fin de semana. PHP más MySQL más un controlador de redirección y tenías algo parecido a Bitly hacia 2010. La categoría no se ha quedado estática; las opciones modernas de código abierto son más capaces que YOURLS, más exigentes de operar que el proyecto de fin de semana y siguen estando significativamente por detrás de un producto alojado en cuanto a analítica. Este post es el panorama honesto: lo que cada opción de código abierto ofrece realmente, a qué renuncias frente a un proveedor alojado y dónde los cálculos vuelven a favorecer el pago a alguien más para que gestione la capa de redirección.
La audiencia son equipos de ingeniería u operadores técnicos que consideran si auto-hospedar. La piedra angular de alternativas a Bitly cubre la comparación más amplia; este post se centra específicamente en el lado del código abierto. El playbook de auto-hospedaje de Elido k3s cubre el caso en el que quieras auto-hospedar Elido mismo en lugar de una alternativa de terceros.
A qué te estás comprometiendo#
Un acortador de URL parece engañosamente pequeño. Una base de datos, un proceso de redirección, un panel para gestionar enlaces. En producción, la forma simple oculta cuatro superficies operativas:
La capa de redirección. Este es el camino crítico. Cada URL corta en la que se hace clic en cualquier lugar de internet eventualmente llega a este código. Debe ser rápida (p95 sub-15ms si te importa la experiencia del usuario), altamente disponible (el tiempo de inactividad aquí rompe cada enlace que hayas enviado) y distribuida globalmente si tus usuarios no están en una sola geografía. El post sobre redirección p95 < 15ms cubre lo que significa realmente ser rápido y cómo se logra.
El pipeline de analítica de clics. Registrar, almacenar y consultar eventos de clic. A gran escala, este es un sistema diferente de la capa de redirección; típicamente Kafka o Redpanda para la ingesta, ClickHouse o BigQuery para el almacenamiento, una API separada para las consultas. La mayoría de los acortadores de código abierto se saltan esto por completo y almacenan los clics en la misma base de datos relacional que contiene los enlaces, lo cual funciona a bajo volumen y falla una vez que superas unos pocos millones de clics al mes.
El panel de control. UI para crear, editar, organizar y analizar enlaces. Donde la mayoría de los proyectos de código abierto dedican la mayor parte de su trabajo en funciones, y donde la brecha con los productos alojados es más pequeña: la mayoría de los paneles de código abierto son decentes.
La maquinaria de dominios personalizados. Emisión de TLS, validación de DNS, renovación de certificados, provisión de certificados bajo demanda cuando un nuevo dominio apunta al clúster. Aquí es donde el coste operativo se acumula; ejecutar ACME a escala es genuinamente difícil.
Una configuración auto-hospedada significa que tú operas las cuatro superficies. Un producto alojado significa que no operas ninguna de ellas (a cambio de pagar a un proveedor y aceptar su postura de residencia de datos). La pregunta es qué conjunto de compensaciones resulta más adecuado para tu situación.
Las opciones actuales de código abierto#
Cinco proyectos que vale la pena considerar, en orden aproximado de actividad a fecha de 2026-05-22.
YOURLS#
El abuelo. PHP, MySQL, servidor único, arquitectura de plugins. YOURLS ha existido desde 2009 y sigue siendo el acortador de código abierto más desplegado por un amplio margen. Fortalezas: simple de instalar, se ejecuta en cualquier lugar donde funcione PHP, el ecosistema de plugins es maduro. Debilidades: la analítica es mínima (recuento de clics por enlace, geo IP a través de un servicio externo), no hay soporte integrado para dominios personalizados más allá de ejecutar múltiples instancias, no hay limitación de tasa de API, no hay concepto de equipos o roles.
YOURLS es una excelente opción si quieres una herramienta personal de enlaces cortos con un solo propietario y tráfico modesto. Es la elección equivocada si tienes un equipo, dominios personalizados para clientes o analítica que deba sobrevivir a la base de datos. El post de Elido vs YOURLS cubre la brecha de funciones en detalle.
Shlink#
PHP de nuevo pero más moderno. Shlink viene con una REST API, soporte multidominio, una UI web separada y actualizaciones en tiempo real basadas en Mercure. La analítica es más capaz que YOURLS — geo por visita, dispositivo, series temporales — pero se almacena en la misma base de datos MySQL/Postgres que los enlaces. El equipo de Shlink es receptivo y el proyecto ha lanzado versiones consistentes desde 2019.
Shlink es una opción razonable si estás dispuesto a operar una configuración PHP-FPM + MySQL/Postgres y no necesitas que la analítica escale más allá de unos pocos millones de clics al mes. La capa de redirección de proceso único se convierte en un cuello de botella a volúmenes más altos; el escalado horizontal es posible pero requiere que pongas delante un equilibrador de carga y una caché compartida.
Polr#
PHP ligero. Polr fue popular alrededor de 2017-2019 y el proyecto está mayormente inactivo ahora, aunque existen forks. Funcionalmente similar a YOURLS pero con una API más limpia. Si estás empezando hoy, la falta de mantenimiento reciente es una preocupación significativa: los parches de seguridad no llegan según un calendario.
Kutt#
Node.js, Postgres, Redis. Kutt es el acortador de "stack moderno" más activo. Viene con una función de dominio personalizado, enlaces protegidos por contraseña, expiración y analítica básica. La superficie analítica es más utilizable que YOURLS pero sigue estando respaldada por una base de datos relacional.
El perfil operativo de Kutt es más pesado que YOURLS — Node + Postgres + Redis significa tres servicios que ejecutar en lugar de uno — pero el stack moderno te da un mejor rendimiento por dólar a volúmenes moderados. Si tu equipo se siente cómodo con Node, Kutt es la opción más segura de "queremos un acortador moderno de código abierto" hoy en día.
Dub-self-hosted#
Dub.co publica una versión auto-hospedada de su producto alojado. Dub ofrece un stack de Next.js + Postgres + Redis + Tinybird con un panel pulido y analítica decente. La complejidad operativa es la más alta de las cinco: Tinybird es un servicio ClickHouse alojado en el despliegue por defecto, y reemplazarlo con ClickHouse auto-hospedado es un proyecto significativo.
Dub-self-hosted es la elección correcta si tienes un equipo cómodo operando un stack web moderno y quieres la apariencia de un producto alojado actual. Es la elección equivocada si tu presupuesto operativo es limitado o tu equipo no domina Next.js.
La matriz de proveedores#
Una calificación de cuatro ejes en analítica, operaciones, dominios personalizados y margen de escalado. Las calificaciones son aproximadas — de A a D — basadas en lo que el proyecto ofrece de serie, no en lo que es posible con trabajo personalizado.
| Proyecto | Analítica | Operaciones | Dominios personalizados | Escalado | 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 |
Dos patrones de la matriz. Primero, la analítica mejora con la complejidad del stack: los proyectos que almacenan los clics en una base de datos relacional junto a los enlaces obtienen una puntuación más baja que los proyectos que ofrecen un pipeline de analítica dedicado. Segundo, los dominios personalizados están razonablemente bien atendidos por todo excepto YOURLS, porque la automatización de ACME se ha convertido en un producto básico.
El coste oculto: analítica que escala#
Los eventos de clic se acumulan más rápido de lo que la gente espera. Un solo enlace con 100 clics al día genera 36,500 clics al año: manejable en cualquier base de datos relacional. Un solo enlace con 100,000 clics al día genera 36.5M de clics al año, y ahí es donde MySQL o Postgres empiezan a sufrir. Un pequeño producto SaaS con mil enlaces activos promediando 1,000 clics al día cada uno es mil millones de clics al año, y en ese punto cualquier almacenamiento relacional falla sin un ajuste significativo.
Los cinco proyectos de código abierto de arriba (excepto Dub y Elido) almacenan los clics en la misma base de datos que los enlaces. Los patrones de consulta también son diferentes de los típicos OLTP: "dame los recuentos de clics por día para este enlace durante los últimos 30 días" es un escaneo de rango con agregación, el peor caso para una base de datos ajustada para OLTP.
Puedes solucionar esto. ClickHouse maneja cargas de trabajo de analítica de mil millones de eventos cómodamente; el post de por qué ClickHouse cubre el razonamiento. Pero añadir ClickHouse a tu stack significa otro servicio que operar, otro pipeline de copias de seguridad, otra superficie de monitoreo. Si tu volumen de enlaces es pequeño (menos de 10M de clics al mes), el enfoque de base de datos relacional está bien durante años; si tu volumen es mayor, la capa de analítica se convierte en un proyecto por derecho propio.
El coste oculto: POPs en el edge y latencia#
Un acortador auto-hospedado en un solo servidor sirve redirecciones desde una ubicación geográfica. Si tus usuarios están en tres continentes, la latencia desde el lado lejano es de 200-300ms, visible en términos de experiencia del usuario.
Las soluciones:
- IPs Anycast frente a múltiples POPs. Práctico solo si tienes tu propio AS y configuración BGP. No es realista para la mayoría de los despliegues auto-hospedados.
- Enrutamiento geográfico basado en DNS. Cloudflare, Route53 o NS1 pueden enrutar a los usuarios al POP más cercano. Funciona pero añade una latencia de búsqueda de DNS además de la redirección.
- CDN delante. Cloudflare o Fastly frente al proceso de redirección. La CDN cachea las respuestas GET; las redirecciones son cacheables pero la lógica de invalidación de caché cuando el destino de un enlace cambia no es trivial.
- Un POP por región. Ejecutar el proceso de redirección en Frankfurt, Ashburn y Singapur, con una base de datos compartida o consistencia eventual entre ellos. Este es el camino de producción. También es significativamente más trabajo que el auto-hospedaje en una sola región.
El post de POPs en el edge vs enrutamiento solo por DNS cubre la elección en detalle. La mayoría de los despliegues auto-hospedados se detienen en una región porque el trabajo multirregión es un proyecto aparte.
Cuándo tiene sentido el auto-hospedaje#
Tres escenarios:
La soberanía de los datos es innegociable. Una industria regulada — salud, finanzas, gobierno — requiere que los datos residan en tu infraestructura. La postura del producto alojado (incluso uno residente en la UE) no es suficiente porque los datos tienen que vivir dentro de tu límite de seguridad. El auto-hospedaje es la respuesta correcta aquí. El coste de mantenimiento es el precio del cumplimiento.
El volumen es pequeño y eres técnico. Un equipo que ejecuta sus propios enlaces cortos para uso interno, con menos de un millón de clics al mes, sin dominios personalizados para clientes externos y un desarrollador que pueda mantener vivo un stack de Docker Compose. YOURLS o Shlink encajan perfectamente. El producto alojado es excesivo para este alcance.
Estás construyendo un producto derivado. Si tus enlaces cortos son el front-end de un producto más grande que estás construyendo — por ejemplo, una plataforma de venta de entradas para eventos donde la URL corta apunta a la entrada — el auto-hospedaje te permite acoplar la capa de redirección con tu lógica de negocio de formas que el proveedor alojado no puede igualar. La mayoría de los usuarios de Dub-self-hosted están en esta categoría.
Cuándo deja de tener sentido el auto-hospedaje#
Tres escenarios en el otro lado:
Necesitas analítica decente. Una vez que tus partes interesadas preguntan "¿cómo se desglosan los clics por país durante los últimos 90 días para estas 50 campañas?", el almacenamiento en base de datos relacional falla. O construyes el pipeline de analítica (un proyecto de varios meses) o pagas a un proveedor alojado que lo ofrezca de serie.
Necesitas dominios personalizados para muchos clientes. Ejecutar ACME para un dominio es trivial. Ejecutar ACME para 10,000 dominios suministrados por clientes, con revocación, renovación y emisión bajo demanda, es una superficie de ingeniería seria. El post de TLS en dominios personalizados cubre el mecanismo; construir esto internamente es un trimestre de trabajo, no una tarde.
El tiempo de tu equipo es el cuello de botella. Un acortador auto-hospedado cuesta aproximadamente 4-8 horas de ingeniero al mes en estado estable una vez configurado, más el tiempo de cada interrupción y cada actualización. Con una tarifa por hora de desarrollador de $100, eso son $400-800/mes antes de contabilizar la inevitable sesión de depuración de interrupciones de dos semanas cada trimestre. Un proveedor alojado a $300-500/mes empieza a parecer barato.
El cálculo del punto de equilibrio es sensible a dos factores: cuánto vale el tiempo de tu equipo y con qué frecuencia te encuentras con problemas operativos. Para un equipo que ya ejecuta su propio clúster k3s, el coste marginal de añadir un acortador es bajo. Para un equipo que no opera actualmente ninguna infraestructura, hospedar el acortador conlleva costes adyacentes (monitoreo, registro, copias de seguridad) que aumentan la factura.
Un árbol de decisión pragmático#
La decisión en cinco preguntas:
- ¿Estás obligado por regulación o política a mantener los datos de los enlaces en infraestructura que tú controlas? Si es así, auto-hospeda. Detente aquí.
- ¿Tu volumen de clics supera actualmente o se espera que supere los 50M de clics al mes en 24 meses? Si es así, planifica una capa de analítica dedicada, lo que inclina la balanza hacia Dub-self-hosted, Elido-self-hosted o un proveedor alojado con analítica respaldada por ClickHouse.
- ¿Necesitas dominios personalizados para más de 10 clientes? Si es así, el coste de automatización de ACME es significativo: los mismos proyectos que antes, o alojado.
- ¿Tu equipo opera actualmente otros servicios de producción con rotación de guardia? Si no, el coste operativo del auto-hospedaje es más alto de lo que parece.
- ¿Son los enlaces cortos una superficie estratégica de tu producto (por ejemplo, estás construyendo una plataforma de integración) o una utilidad de apoyo (por ejemplo, enlaces internos del equipo)? Superficie estratégica = auto-hospedaje o alojado con integración profunda; utilidad de apoyo = lo que sea más barato.
La mayoría de los equipos llegarán a la opción alojada tras recorrer este árbol. Eso está bien. El auto-hospedaje es la respuesta correcta cuando las restricciones están claras; es el valor por defecto incorrecto cuando no lo están.
Lecturas relacionadas#
- Alternativas a Bitly: la brecha real de funciones — la piedra angular más amplia de proveedores alojados.
- Auto-hospedaje de Elido en k3s: el playbook — el recorrido operativo para el lado de Elido.
- Elido vs YOURLS — el cara a cara contra la opción de código abierto más desplegada.
- Por qué ClickHouse para analítica de clics — el razonamiento de la capa de analítica.
- POPs en el edge vs enrutamiento solo por DNS — el camino multirregión.
- Superficie del producto:
/solutions/developersy/pricing. - Arquitectura: documentación de edge-redirect.