Most URL shortener tutorials stop at “store a link and redirect it.”
I wanted to go a little further and show how you can build something that actually feels production-ready:
- fast redirects
- edge deployment
- click analytics
- QR support
- custom aliases
- rate limiting ideas
- scalable architecture
This is very close to the architecture I use for my own project, AlShorty.
Not sharing every production detail obviously 😄 — but enough that you can genuinely build your own version and understand how these systems work.
⸻
Why Cloudflare Workers?
I tried traditional VPS setups before.
But for a URL shortener specifically, edge runtimes make a LOT of sense:
- redirects happen close to the user
- extremely fast cold starts
- globally distributed
- low infrastructure overhead
- simple deployments
For link redirects, latency matters.
Workers are honestly a great fit for this category of app.
⸻
What we’re building
A mini URL shortener with:
- short links
- redirect handling
- KV storage
- analytics logging
- custom aliases
- QR-ready structure
- API endpoints
Example:
- Long URL: https://example.com/blog/some-very-long-article
- Short URL: https://yourapp.com/abc123
⸻
Tech Stack
- Cloudflare Workers
- Cloudflare KV
- Hono (optional but recommended)
- TypeScript
- Cloudflare Analytics Engine / D1 (optional)
- React frontend (optional)
⸻
Architecture Overview
User
↓
Cloudflare Edge Worker
↓
Lookup short code in KV
↓
Return redirect response
↓
Log analytics async
Step 1 — Create the Worker
Step 2 — Create KV Namespace
Step 3 — Basic Redirect Logic
export default {
async fetch(request, env) {
const url = new URL(request.url)
const slug = url.pathname.slice(1)
if (!slug) {
return new Response("Homepage")
}
const longUrl = await env.LINKS.get(slug)
if (!longUrl) {
return new Response("Link not found", { status: 404 })
}
return Response.redirect(longUrl, 302)
}
}
That’s the core engine.
Tiny amount of code.
Massive scale potential.
Step 4 — Create Short Links
app.post("/api/shorten", async (c) => {
const body = await c.req.json()
const slug = crypto.randomUUID().slice(0, 6)
await c.env.LINKS.put(slug, body.url)
return c.json({
shortUrl: `https://yourdomain.com/${slug}`
})
})
Step 5 — Analytics
This is where most tutorials become unrealistic.
DO NOT block redirects while writing analytics.
The redirect should happen instantly.
Analytics can happen asynchronously afterward.
Track things like:
- country
- device
- browser
- referrer
- timestamp
Cloudflare already gives useful request metadata.
Step 6 — Prevent Abuse
Very important.
Public shorteners get abused FAST.
Minimum protections:
- rate limiting
- domain validation
- phishing checks
- bot filtering
- max requests/IP
- captcha on anonymous creation
This is honestly one of the hardest parts of running a real shortener.
⸻
Step 7 — Add QR Codes
Simple improvement:
every short link can automatically generate a QR code.
Step 8 — Frontend
You honestly don’t need much.
A simple form:
- paste URL
- shorten
- copy button
That alone is already useful.
Real-world lessons I learned
1. Redirect speed matters more than fancy UI
Users forgive simple UI.
They do NOT forgive slow redirects.
⸻
2. Analytics becomes expensive fast
Logging every click sounds simple.
At scale it becomes infrastructure-heavy.
Design carefully early.
⸻
3. Abuse handling is endless
Spammers LOVE shorteners.
You’ll spend more time preventing abuse than writing redirect logic.
⸻
4. SEO matters
If you’re building publicly:
- create landing pages
- write tutorials
- build alternatives pages
- document APIs
That traffic compounds over time.
⸻
Final thoughts
The interesting thing about modern development is:
the barrier to building has become incredibly low.
But the barrier to maintaining, scaling, marketing, and growing a real product is still very high.
That’s where the real work starts.
If you want a production-ready version with analytics, QR codes, Link-in-Bio pages, SmartPages, APIs, and more — that’s basically what I’m building with AlShorty
Would also love to hear how others are handling:
Top comments (0)