Ospitare autonomamente un abbreviatore di URL (self-hosting) era solitamente un progetto da weekend. PHP più MySQL più un controller di redirect e avevi qualcosa che somigliava a Bitly intorno al 2010. La categoria non è rimasta ferma; le moderne opzioni open source sono più capaci di YOURLS, più esigenti da gestire rispetto al progetto del weekend e ancora significativamente indietro rispetto a un prodotto hosted per quanto riguarda l'area degli analytics. Questo post analizza onestamente il panorama: cosa offre realmente ogni opzione open source, a cosa si rinuncia rispetto a un vendor hosted e quando i calcoli tornano a favorire il pagamento di qualcuno che gestisca il livello di redirect.
Il pubblico di riferimento è composto da team di ingegneria o operatori tecnici che stanno valutando se ricorrere al self-hosting. Il cornerstone sulle alternative a Bitly copre il confronto più ampio; questo post si concentra specificamente sul lato open source. Il playbook per il self-hosting di Elido su k3s copre invece il caso in cui si voglia ospitare Elido stesso piuttosto che un'alternativa di terze parti.
Cosa comporta questa scelta#
Un abbreviatore di URL sembra ingannevolmente semplice. Un database, un processo di redirect, una dashboard per la gestione dei link. In produzione, questa forma semplice nasconde quattro aree operative:
Il livello di redirect. Questo è l'hot path. Ogni URL breve cliccato ovunque su Internet colpisce infine questo codice. Deve essere veloce (p95 inferiore a 15ms se ti interessa l'esperienza utente), altamente disponibile (i tempi di inattività qui interrompono ogni link che hai mai distribuito) e distribuito globalmente se i tuoi utenti non si trovano in un'unica area geografica. Il post sul redirect p95 < 15ms spiega cosa significa realmente "veloce" e come si ottiene.
La pipeline di analisi dei clic. Registrazione, archiviazione e interrogazione degli eventi di clic. A volumi elevati, questo è un sistema diverso dal livello di redirect — tipicamente Kafka o Redpanda per l'ingestion, ClickHouse o BigQuery per lo storage, e un'API separata per le query. La maggior parte degli abbreviatori open source salta completamente questo passaggio e memorizza i clic nello stesso database relazionale che contiene i link, il che funziona a bassi volumi ma crolla una volta superati i pochi milioni di clic al mese.
La dashboard. UI per creare, modificare, organizzare e analizzare i link. È qui che la maggior parte dei progetti open source concentra il lavoro sulle funzionalità, ed è dove il divario con i prodotti hosted è minore: la maggior parte delle dashboard open source è discreta.
Il meccanismo dei domini personalizzati. Emissione TLS, validazione DNS, rinnovo dei certificati, provisioning dei certificati on-demand quando un nuovo dominio punta al cluster. È qui che il costo operativo aumenta; gestire ACME su scala è realmente difficile.
Una configurazione self-hosted significa gestire tutte e quattro le aree. Un prodotto hosted significa non gestirne nessuna (in cambio del pagamento di un vendor e dell'accettazione della loro postura sulla residenza dei dati). La domanda è quale set di compromessi sia più adatto alla tua situazione.
Le attuali opzioni open source#
Cinque progetti degni di nota, in ordine approssimativo di attività alla data del 22-05-2026.
YOURLS#
Il veterano. PHP, MySQL, server singolo, architettura a plugin. YOURLS esiste dal 2009 e rimane l'abbreviatore open source più distribuito con un ampio margine. Punti di forza: semplice da installare, funziona ovunque giri PHP, l'ecosistema dei plugin è maturo. Punti deboli: gli analytics sono minimi (conteggio clic per link, geo IP tramite un servizio esterno), nessun supporto integrato per domini personalizzati oltre all'esecuzione di più istanze, nessun rate limiting per le API, nessun concetto di team o ruoli.
YOURLS è un'ottima scelta se desideri uno strumento personale per link brevi con un unico proprietario e traffico modesto. È la scelta sbagliata se hai un team, domini personalizzati per i clienti o analytics che devono sopravvivere al database. Il post Elido vs YOURLS copre dettagliatamente il divario di funzionalità.
Shlink#
Ancora PHP, ma più moderno. Shlink include un'API REST, supporto multi-dominio, una UI web separata e aggiornamenti in tempo reale basati su Mercure. Gli analytics sono più capaci rispetto a YOURLS — geo per visita, dispositivo, serie temporali — ma memorizzati nello stesso database MySQL/Postgres dei link. Il team di Shlink è reattivo e il progetto ha rilasciato aggiornamenti costanti dal 2019.
Shlink è una scelta ragionevole se sei disposto a gestire una configurazione PHP-FPM + MySQL/Postgres e non hai bisogno che gli analytics scalino oltre i pochi milioni di clic al mese. Il livello di redirect a processo singolo diventa un collo di bottiglia a volumi più elevati; la scalabilità orizzontale è possibile ma richiede di posizionare davanti un load balancer e una cache condivisa.
Polr#
PHP leggero. Polr era popolare intorno al 2017-2019 e il progetto è ora ampiamente inattivo, sebbene esistano dei fork. Funzionalmente simile a YOURLS ma con un'API più pulita. Se inizi oggi, la mancanza di manutenzione recente è una preoccupazione significativa — le patch di sicurezza non arrivano regolarmente.
Kutt#
Node.js, Postgres, Redis. Kutt è l'abbreviatore "modern stack" più attivo. Include una funzione per domini personalizzati, link protetti da password, scadenza e analytics di base. L'area degli analytics è più utilizzabile rispetto a YOURLS ma è comunque basata su un database relazionale.
Il profilo operativo di Kutt è più pesante di quello di YOURLS — Node + Postgres + Redis significa tre servizi da gestire invece di uno — ma lo stack moderno offre prestazioni migliori per dollaro a volumi moderati. Se il tuo team si sente a proprio agio con Node, Kutt è oggi la scelta più sicura come "abbreviatore open source moderno".
Dub-self-hosted#
Dub.co pubblica una versione self-host del proprio prodotto hosted. Dub offre uno stack Next.js + Postgres + Redis + Tinybird con una dashboard rifinita e analytics discreti. La complessità operativa è la più alta tra i cinque — Tinybird è un servizio ClickHouse hosted nella distribuzione predefinita, e sostituirlo con un ClickHouse self-hosted è un progetto significativo.
Dub-self-hosted è la scelta giusta se hai un team a suo agio nella gestione di un moderno stack web e desideri il look-and-feel di un attuale prodotto hosted. È la scelta sbagliata se il tuo budget operativo è limitato o se il tuo team non ha familiarità con Next.js.
La matrice dei vendor#
Una valutazione su quattro assi tra analytics, operazioni, domini personalizzati e margine di scalabilità. I voti sono indicativi — da A a D — basati su ciò che il progetto offre di serie, non su ciò che è possibile con lavoro personalizzato.
| Progetto | Analytics | Operazioni | Domini personalizzati | Scalabilità | Stack |
|---|---|---|---|---|---|
| YOURLS | D | A | C (manuale) | 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 |
Dalla matrice emergono due pattern. Primo, gli analytics migliorano con la complessità dello stack — i progetti che memorizzano i clic in un database relazionale insieme ai link ottengono punteggi più bassi rispetto ai progetti che includono una pipeline di analytics dedicata. Secondo, i domini personalizzati sono serviti ragionevolmente bene da tutto tranne che da YOURLS, poiché l'automazione ACME è diventata una commodity.
Il costo nascosto: analytics che scalano#
Gli eventi di clic si accumulano più velocemente di quanto ci si aspetti. Un singolo link con 100 clic al giorno genera 36.500 clic all'anno — gestibili in qualsiasi database relazionale. Un singolo link con 100.000 clic al giorno genera 36,5 milioni di clic all'anno, ed è qui che MySQL o Postgres iniziano a soffrire. Un piccolo prodotto SaaS con mille link attivi che mediano 1.000 clic al giorno ciascuno produce un miliardo di clic all'anno, e a quel punto qualsiasi archivio relazionale cede senza una sintonizzazione significativa.
I cinque progetti open source sopra citati (eccetto Dub ed Elido) memorizzano i clic nello stesso database dei link. Anche i pattern di query sono diversi dal tipico OLTP — "dammi il conteggio dei clic per giorno per questo link negli ultimi 30 giorni" è una scansione di intervallo con aggregazione, il caso peggiore per un database ottimizzato per OLTP.
È possibile risolvere questo problema. ClickHouse gestisce comodamente carichi di lavoro di analisi da miliardi di eventi; il post sul perché usare ClickHouse ne spiega le ragioni. Ma aggiungere ClickHouse al tuo stack significa un altro servizio da gestire, un'altra pipeline di backup, un'altra superficie di monitoraggio. Se il volume dei tuoi link è ridotto (sotto i 10 milioni di clic al mese), l'approccio con database relazionale va bene per anni; se il volume è maggiore, il livello di analytics diventa un progetto a sé stante.
Il costo nascosto: POP edge e latenza#
Un abbreviatore self-hosted su un singolo server gestisce i redirect da un'unica posizione geografica. Se i tuoi utenti si trovano in tre continenti, la latenza dal lato opposto è di 200-300ms — percepibile in termini di esperienza utente.
Le soluzioni:
- IP Anycast davanti a più POP. Pratico solo se hai il tuo AS e una configurazione BGP. Non realistico per la maggior parte delle installazioni self-hosted.
- Routing basato sulla geolocalizzazione tramite DNS. Cloudflare, Route53 o NS1 possono indirizzare gli utenti al POP più vicino. Funziona, ma aggiunge una latenza di lookup DNS sopra il redirect.
- CDN davanti. Cloudflare o Fastly davanti al processo di redirect. La CDN memorizza nella cache le risposte GET; i redirect sono memorizzabili in cache, ma la logica di invalidazione della cache quando cambia la destinazione di un link non è banale.
- Un POP per regione. Eseguire il processo di redirect a Francoforte, Ashburn e Singapore, con un database condiviso o consistenza eventuale tra di loro. Questo è il percorso di produzione. È anche significativamente più impegnativo rispetto al self-hosting in una singola regione.
Il post su POP edge vs routing solo DNS copre la scelta in dettaglio. La maggior parte delle installazioni self-hosted si ferma a una singola regione perché il lavoro multi-regione è un progetto a parte.
Quando il self-hosting ha senso#
Tre scenari:
La sovranità dei dati non è negoziabile. Un settore regolamentato — sanità, finanza, pubblica amministrazione — richiede che i dati risiedano sulla tua infrastruttura. La postura del prodotto hosted (anche se residente in EU) non è sufficiente perché i dati devono vivere all'interno del tuo confine di sicurezza. Il self-hosting è la risposta corretta in questo caso. Il costo di manutenzione è il prezzo della compliance.
Il volume è ridotto e sei una persona tecnica. Un team che gestisce i propri link brevi per uso interno, con meno di un milione di clic al mese, senza domini personalizzati per clienti esterni e uno sviluppatore che può tenere in vita uno stack Docker Compose. YOURLS o Shlink si adattano perfettamente. Il prodotto hosted è eccessivo per questo scopo.
Stai costruendo un prodotto derivato. Se i tuoi link brevi sono il front-end di un prodotto più ampio che stai costruendo — ad esempio, una piattaforma di biglietteria per eventi in cui l'URL breve punta al biglietto — il self-hosting ti permette di accoppiare il livello di redirect con la tua logica di business in modi che un vendor hosted non può eguagliare. La maggior parte degli utilizzatori della versione self-host di Dub appartiene a questa categoria.
Quando il self-hosting smette di avere senso#
Tre scenari dall'altra parte:
Hai bisogno di analytics adeguati. Una volta che i tuoi stakeholder chiedono "come si distribuiscono i clic per paese negli ultimi 90 giorni per queste 50 campagne?", l'archiviazione su database relazionale fallisce. O costruisci la pipeline di analytics (un progetto di più mesi) o paghi un vendor hosted che la offra di serie.
Hai bisogno di domini personalizzati per molti clienti. Gestire ACME per un solo dominio è banale. Gestire ACME per 10.000 domini forniti dai clienti, con revoca, rinnovo ed emissione on-demand, è una superficie ingegneristica seria. Il post sul TLS per domini personalizzati copre il meccanismo; costruire questo internamente richiede un trimestre di lavoro, non un pomeriggio.
Il tempo del tuo team è il collo di bottiglia. Un abbreviatore self-hosted costa circa 4-8 ore-uomo al mese a regime una volta configurato, più il tempo di ogni interruzione e ogni aggiornamento. Con una tariffa oraria per sviluppatore di 100 $, parliamo di 400-800 $/mese prima di contare l'inevitabile sessione di debugging di due settimane per un'interruzione ogni trimestre. Un vendor hosted a 300-500 $/mese inizia a sembrare economico.
Il calcolo del punto di pareggio è sensibile a due input: quanto vale il tempo del tuo team e quanto spesso incontri problemi operativi. Per un team che gestisce già il proprio cluster k3s, il costo marginale di aggiungere un abbreviatore è basso. Per un team che attualmente non gestisce alcuna infrastruttura, ospitare l'abbreviatore trascina con sé costi adiacenti (monitoraggio, logging, backup) che aggravano il conto.
Un albero decisionale pragmatico#
La decisione in cinque domande:
- Sei obbligato da regolamentazioni o policy a mantenere i dati dei link su infrastrutture che controlli? Se sì, vai con il self-hosting. Fermati qui.
- Il tuo volume di clic attuale o previsto supererà i 50 milioni al mese entro 24 mesi? Se sì, pianifica un livello di analytics dedicato — il che orienta verso Dub-self-hosted o Elido-self-hosted, oppure un vendor hosted con analytics basati su ClickHouse.
- Hai bisogno di domini personalizzati per più di 10 clienti? Se sì, il costo dell'automazione ACME è significativo — stessi progetti di cui sopra, o hosted.
- Il tuo team gestisce attualmente altri servizi in produzione con turni di reperibilità? Se no, il costo operativo del self-hosting è più alto di quanto appaia.
- I link brevi sono una superficie strategica del tuo prodotto (es. stai costruendo una piattaforma di integrazione) o un'utility di supporto (es. link interni al team)? Superficie strategica = self-hosting o hosted con integrazione profonda; utility di supporto = quello che costa meno.
La maggior parte dei team approderà alla soluzione hosted dopo aver seguito questo schema. Va bene così. Il self-hosting è la risposta giusta quando i vincoli sono chiari; è il default sbagliato quando non lo sono.
Letture correlate#
- Alternative a Bitly — l'effettivo divario di funzionalità — il cornerstone più ampio sui vendor hosted.
- Self-hosting di Elido su k3s — il playbook — la guida operativa per il lato Elido.
- Elido vs YOURLS — il testa a testa con l'opzione open source più diffusa.
- Perché ClickHouse per gli analytics dei clic — il ragionamento sul livello di analytics.
- POP edge vs routing solo DNS — il percorso multi-regione.
- Superficie del prodotto:
/solutions/developerse/pricing. - Architettura: documentazione edge-redirect.