DEV Community: FRANCISCO LINO

I built a serverless URL shortener for $4.68/year (total)

FRANCISCO LINO — Thu, 23 Jul 2026 00:10:05 +0000

I wanted two things: short links under my own brand (every link I share points traffic back to my site), and a real excuse to run a complete system on the edge — DNS, distributed compute, storage, auth and a dashboard — in production, at zero infrastructure cost.

The result is flino.link: a shortener that responds in under 10 ms from 300+ locations, runs entirely on Cloudflare's free tier, and whose only expense is the domain: $4.68 a year. This post covers the design decisions, which is where the interesting parts are.

The architecture in 30 seconds

A single Cloudflare Worker serves the whole domain:

GET /<slug> — the hot path. One read from Workers KV (globally replicated) and a 302 redirect. Nothing else touches that path.
/api/links — a REST API with Bearer auth to create, list and delete links.
/admin — a single-page dashboard served as inline HTML from the Worker itself. No framework, no build step.
A Durable Object with embedded SQLite keeps per-slug click counts.

No servers, no containers, no database to manage. The whole Worker is three TypeScript files and zero runtime dependencies.

Why a dedicated domain?

My first idea was to hang the shortener off a route on flino.dev. Bad idea: shorteners attract abuse — spam, phishing — and their domains sooner or later end up on blocklists. If that happens, I don't want it dragging my main domain down with it. A separate domain isolates that reputation risk completely, and a short .link costs less than a coffee per year.

KV for links, a Durable Object for counters

This is the central design decision. Workers KV is perfect for a shortener's access pattern — read-heavy, write-light, reads served from the edge — but its writes are eventually consistent: two concurrent increments in different datacenters would clobber each other. For counting clicks, it's useless.

A Durable Object solves exactly that: it's a single global instance with transactional SQLite storage. Every increment, no matter which datacenter it comes from, serializes through one consistent point:

export class ClickCounter extends DurableObject<unknown> {
  private sql = this.ctx.storage.sql;

  increment(slug: string): void {
    const now = Date.now();
    this.sql.exec(
      "INSERT INTO clicks (slug, count, last_click) VALUES (?, 1, ?) " +
        "ON CONFLICT(slug) DO UPDATE SET count = count + 1, last_click = ?",
      slug, now, now,
    );
  }
}

Doesn't that single point become a bottleneck for redirects? No — because of what comes next.

The `waitUntil` trick: click counting with zero latency

A shortener's contract is to redirect fast. If the redirect had to wait for the Durable Object write, every click would pay an extra round-trip. The solution is ctx.waitUntil(): it hands the runtime a promise that executes after the response has been sent to the visitor.

const target = await env.LINKS.get(slug);
if (target !== null) {
  // Runs after the response is sent — adds no latency to the redirect.
  ctx.waitUntil(counter(env).increment(slug));
  return Response.redirect(target, 302);
}

The visitor gets their 302 after a single KV read; the counting happens in the background. Free analytics, in the literal sense of the word.

Fail toward the brand

What happens when someone visits a slug that doesn't exist, or the domain root? Never a 404: always a redirect to flino.dev. A broken or deleted link never shows an ugly error page — it shows my site. Every dead path in the system becomes a touchpoint.

// Unknown slug, root, or anything else:
return Response.redirect("https://flino.dev", 302);

The dashboard: inline HTML, no framework

The admin panel is a TypeScript constant holding a complete HTML page that the Worker serves at /admin. The API key lives in localStorage, dark mode comes free with prefers-color-scheme, and creating a link auto-copies the short URL to the clipboard. Zero dependencies, zero build, and it deploys together with the Worker in the same wrangler deploy.

For a project this size, a frontend framework would have been more infrastructure than product.

The numbers


Redirect latency	< 10 ms from 300+ locations
Capacity (free tier)	~100,000 requests/day
Infrastructure cost	$0/mo
Total cost	$4.68/yr (the domain)
Runtime dependencies	0

What I'm taking away

The edge changes the defaults. For a read-heavy service, the question is no longer "how close do I put the server?" but "why would there be a server?".
Pick storage by semantics, not by habit. KV and Durable Objects coexist in the same Worker, each doing the one thing it's good at: global replication for reads, strong consistency for counting.
waitUntil is the most underrated pattern in Workers. Anything the visitor doesn't need — metrics, logs, counters — can move off the critical path.

The full code is on GitHub, and if you want to see the system in action, this link goes through it: flino.link/devto-en. (Yes — your click is already on my dashboard 😄)

Where would you have hosted this? Workers, a $5 VPS, Deno Deploy, fly.io? I'd genuinely like to read other approaches in the comments. 👇

Construí un acortador de URLs sin servidores por $4.68 al año

FRANCISCO LINO — Wed, 22 Jul 2026 23:42:49 +0000

Quería dos cosas: links cortos bajo mi propia marca (cada link que comparto apunta tráfico hacia mi sitio) y una excusa real para operar un sistema completo en el edge — DNS, cómputo distribuido, storage, autenticación y un dashboard — en producción y con costo cero de infraestructura.

El resultado es flino.link: un acortador que responde en menos de 10 ms desde más de 300 ubicaciones, corre enteramente en el tier gratuito de Cloudflare, y cuyo único gasto es el dominio: $4.68 al año. En este artículo explico las decisiones de diseño, que es donde está lo interesante.

La arquitectura en 30 segundos

Un solo Cloudflare Worker atiende todo el dominio:

GET /<slug> — el camino caliente. Una lectura a Workers KV (replicado globalmente) y un redirect 302. Nada más toca ese camino.
/api/links — API REST con autenticación Bearer para crear, listar y borrar links.
/admin — un dashboard de una sola página HTML servida inline desde el propio Worker. Sin framework, sin build step.
Un Durable Object con SQLite embebido lleva el conteo de clicks por slug.

Sin servidores, sin contenedores, sin base de datos que administrar. El Worker completo son tres archivos TypeScript y cero dependencias en runtime.

¿Por qué un dominio dedicado?

Mi primera idea fue colgar el acortador de una ruta de flino.dev. Mala idea: los acortadores atraen abuso — spam, phishing — y sus dominios terminan tarde o temprano en blocklists. Si eso pasa, no quiero que arrastre a mi sitio principal. Un dominio separado aísla esa reputación de riesgo por completo, y un .link corto cuesta menos que un café al año.

KV para los links, Durable Object para los contadores

Aquí está la decisión de diseño central. Workers KV es perfecto para el patrón de un acortador — muchas lecturas, pocas escrituras, lecturas servidas desde el edge — pero sus escrituras son eventualmente consistentes: dos incrementos concurrentes en datacenters distintos se pisarían entre sí. Para contar clicks es inservible.

Un Durable Object resuelve exactamente eso: es una instancia única global con almacenamiento SQLite transaccional. Todos los incrementos, vengan del datacenter que vengan, se serializan en un solo punto consistente:

export class ClickCounter extends DurableObject<unknown> {
  private sql = this.ctx.storage.sql;

  increment(slug: string): void {
    const now = Date.now();
    this.sql.exec(
      "INSERT INTO clicks (slug, count, last_click) VALUES (?, 1, ?) " +
        "ON CONFLICT(slug) DO UPDATE SET count = count + 1, last_click = ?",
      slug, now, now,
    );
  }
}

¿Y no se convierte ese punto único en un cuello de botella para los redirects? No, por lo que viene ahora.

El truco de `waitUntil`: contar clicks con latencia cero

El contrato de un acortador es redirigir rápido. Si el redirect tuviera que esperar la escritura en el Durable Object, cada click pagaría un round-trip extra. La solución es ctx.waitUntil(): le entrega al runtime una promesa que se ejecuta después de enviar la respuesta al visitante.

const target = await env.LINKS.get(slug);
if (target !== null) {
  // Se ejecuta después de responder — no añade latencia al redirect.
  ctx.waitUntil(counter(env).increment(slug));
  return Response.redirect(target, 302);
}

El visitante recibe su 302 con una sola lectura a KV; el conteo ocurre en segundo plano. Analytics gratis, en el sentido literal de la palabra.

Fallar hacia la marca

¿Qué pasa si alguien visita un slug que no existe, o la raíz del dominio? Nunca un error 404: siempre un redirect a flino.dev. Un link roto o borrado no muestra una página fea — muestra mi sitio. Cada camino muerto del sistema se convierte en un touchpoint.

// Slug inexistente, raíz, o cualquier otra cosa:
return Response.redirect("https://flino.dev", 302);

El dashboard: HTML inline, sin framework

El panel de administración es una constante de TypeScript con un HTML completo que el Worker sirve en /admin. La API key se guarda en localStorage, el dark mode sale gratis con prefers-color-scheme, y crear un link copia el resultado al portapapeles automáticamente. Cero dependencias, cero build, y se despliega junto con el Worker en el mismo wrangler deploy.

Para un proyecto de este tamaño, un framework de frontend habría sido más infraestructura que producto.

Los números


Latencia de redirect	< 10 ms desde 300+ ubicaciones
Capacidad (tier gratuito)	~100.000 requests/día
Costo de infraestructura	$0/mes
Costo total	$4.68/año (el dominio)
Dependencias en runtime	0

Lo que me llevo

El edge cambia los defaults. Para un servicio de lectura intensiva, la pregunta ya no es "¿qué tan cerca pongo el servidor?" sino "¿por qué habría un servidor?".
Elegir el storage por semántica, no por costumbre. KV y Durable Objects conviven en el mismo Worker haciendo cada uno lo que sabe hacer: replicación global para leer, consistencia fuerte para contar.
waitUntil es el patrón más subestimado de Workers. Todo lo que no necesita el visitante — métricas, logs, contadores — puede salir del camino crítico.

El código completo está en GitHub, y si quieres ver el sistema funcionando, este link pasa por él: flino.link/devto.

¿Tú dónde habrías hospedado esto? ¿Workers, una VPS de $5, Deno Deploy? Me interesa leer otros enfoques en los comentarios. 👇