Cloudflare on vanityURLs

Cloudflare products vanityURLs leaves out

Fri, 29 May 2026 00:00:00 +0000

Cloudflare has more useful products than a short-link redirector should use.

That is not a criticism of Cloudflare. It is an operating boundary. vanityURLs uses Cloudflare DNS, Cloudflare Workers, Cloudflare Access, SSL/TLS, and selected edge protections. The baseline product list lives in Cloudflare products. The detailed setup lives in Network protection.

This page records the other side of that decision: products that are visible, useful in the right deployment, and still not part of the default vanityURLs setup.

vanityURLs' secret sauce is a JSON ledger

Fri, 29 May 2026 00:00:00 +0000

The problem showed up in the usual small way: a Cloudflare dashboard label moved, a setup page still named the old path, and the next maintainer had to decide whether the documentation was stale or the product guidance had changed.

vanityURLs stands on Cloudflare’s shoulders. That is the point. A short-link redirector should not need a fleet of servers, a database, or a private control plane. It can run on Cloudflare’s serverless architecture and let Cloudflare stop noisy traffic before the Worker executes.

Do not turn every Cloudflare knob

Thu, 28 May 2026 00:00:00 +0000

The Cloudflare dashboard is not a checklist.

That is the rule. A vanityURLs instance has a narrow job: serve short links from a Worker, keep operational pages behind Access, and let Cloudflare reject obvious noise before application code runs. The baseline controls are documented in Network protection. The product inventory is documented in Cloudflare products.

This post is the negative space. It names the knobs that should stay off unless an operator has a reason that survives writing down.

vanityURLs compared with hosted and self-hosted shorteners

Wed, 27 May 2026 00:00:00 +0000

vanityURLs is for operators who want a branded short-link domain, operated from Git on Cloudflare Workers, without a shared hosted account, without a click database by default, and with configuration reviewed as code. It does not try to replace every hosted dashboard. It tries to make a small auditable redirector easy to own.

Comparison Table

Dimension	vanityURLs	Bitly	Dub	Short.io	YOURLS	Shlink
Custom domain	Operator-owned Cloudflare domain	Hosted plan feature	Hosted plan feature	Hosted plan feature	Self-hosted domain	Self-hosted domain
Analytics model	Disabled by default; optional server-side Umami or Fathom	Hosted analytics	Hosted analytics	Hosted analytics	Built-in self-hosted stats	Built-in visits
Account required	No visitor account; operator uses Cloudflare and GitHub	Hosted account	Hosted account	Hosted account	Admin account on the install	Admin/API access on the install
Data residence	Depends on operator choices for Cloudflare, Git, and analytics	Controlled by provider	Controlled by provider	Controlled by provider	Your hosting/database choices	Your hosting/database choices
ToS surface	Instance terms generated from config	Provider terms plus your link usage	Provider terms plus your link usage	Provider terms plus your link usage	Your terms	Your terms
Deployment model	Cloudflare Worker plus Static Assets from Git	Hosted software service	Hosted software service, open-source core	Hosted software service	PHP app and database	PHP service and database
Cost at scale	Cloudflare usage plus optional analytics provider	Per plan	Per plan	Per plan	Hosting and maintenance	Hosting and maintenance
Code visibility	MIT open source code and instance config in Git	Closed hosted service	Open-source product with hosted service	Closed hosted service	Open source	Open source
Link scheduling	Configured in Git and evaluated by the Worker	Depends on plan/product	Depends on product	Depends on product	Depends on plugins/custom code	Depends on built-in features
Bulk operations	Text file and `lnk` CLI workflow	Dashboard/API/import	Dashboard/API/import	Dashboard/API/import	Admin/API/database workflows	CLI/API workflows

Bitly

Bitly wins when a team wants a mature hosted product, a dashboard-centered workflow, brand/campaign features, and a vendor responsible for product operations. It is the safer choice when non-technical users need to create and inspect links without touching Git or Cloudflare.

Cloudflare Access is not a checkbox

Tue, 26 May 2026 00:00:00 +0000

The failure mode is ordinary. Someone opens /en/_stats/ from a private browser window and sees the dashboard instead of the Cloudflare Access login page.

That is the whole problem. Public redirects should stay public. Operational pages should not.

For vanityURLs, Cloudflare Access has one narrow job: keep localized stats paths such as /en/_stats/, localized test paths such as /en/_tests/, and similar operator surfaces private before the Worker serves them. Treat it as an access boundary, not a setup souvenir.

Keep scanner traffic out of the Worker

Fri, 22 May 2026 00:00:00 +0000

A short-link redirector looks simple: receive a slug, look up a destination, redirect.

The internet supplies the rest. PHP probes. WordPress paths. Odd methods. Bot traffic. Crawlers. Repeated misses for slugs nobody created.

The Worker should not be the first place that noise gets expensive. vanityURLs keeps the Worker small and deterministic, then uses Cloudflare edge controls for traffic that should never spend Worker CPU or analytics quota.

Block Before Runtime

The Worker still validates destinations and runtime policy. That is the last line of defense, not the first.

Migrating from Cloudflare Pages redirects to vanityURLs Workers

Fri, 22 May 2026 00:00:00 +0000

The first vanityURLs instances were intentionally simple: a domain, a _redirects file, and Cloudflare Pages. That was a good starting point. It made short links easy to keep in Git, easy to review, and easy to deploy.

The current runtime keeps the same spirit, but moves the redirect decision into a Cloudflare Worker. That change gives the instance a stronger runtime: protected operational pages, generated policy, localized public pages, server-side analytics, scanner protection, and a clearer split between product defaults and instance-owned files.

Release checklist for a vanityURLs instance

Fri, 22 May 2026 00:00:00 +0000

Use this checklist before launching a new instance or promoting a major upgrade. A vanityURLs instance is robust, but anything shiny on the internet attracts scanners, bots, and abuse attempts.

The code repository keeps the executable activity list in RELEASE_CHECKLIST.md. This post explains why those checks matter and adds operational context for Cloudflare and instance owners.

The strongest release posture is boring: a small Worker, reviewed generated files, narrow Cloudflare exposure, protected operational pages, and clear ownership of every destination.

Runtime security for a small redirector

Fri, 22 May 2026 00:00:00 +0000

Short-link domains are small targets with oversized consequences. A bad redirect can damage trust quickly, and scanner traffic can arrive before the domain is even public. That is why vanityURLs treats simplicity as a security feature, not an aesthetic preference.

The runtime is not a public link-submission service. It is not a database-backed web application. It is a Git-built redirect engine: validate the registry, deploy static assets, read generated data, and return a redirect, protected page, disabled page, expired page, or localized 404.

Start with one-time PIN, then earn the IdP

Fri, 22 May 2026 00:00:00 +0000

The first identity decision for a short-link domain should be boring.

Protect /en/_stats/, other localized stats paths, and /en/_tests/ before the instance goes public. Do not spend the first deploy designing an enterprise identity architecture unless the enterprise already exists.

For vanityURLs, Cloudflare Access protects the operational pages before the Worker serves them. The question is not “which IdP is best?” The question is “which access path can the operator review and revoke without ceremony?”

Wrangler Without Shooting Yourself in the Foot

Fri, 22 May 2026 00:00:00 +0000

Wrangler is Cloudflare’s command-line tool for Workers. wrangler.toml is the configuration file that tells Cloudflare exactly what Worker you are deploying, where your code lives, which static assets to publish, and which runtime values are part of the deployment.

It might be tempting to use this file to build a beautiful platform abstraction layer. Resist that urge. For a vanityURLs instance, wrangler.toml should be boring enough that your future self can open it in six months and immediately understand exactly what is deployed.

The current v8s architecture

Fri, 15 May 2026 00:00:00 +0000

The current v8s release is built around a small contract: keep the runtime simple, keep the source of truth in Git, and push abuse filtering as close to the edge as possible.

The instance model

An instance has two kinds of files:

defaults/ contains the product defaults, public operational pages, blocklist defaults, robots and LLM crawler guidance, and scripts that should be updated from upstream
custom/ contains the instance-owned links, schedules, policy replacement, branding, legal pages, and any intentionally local public files

That split is the upgrade story. If instance owners keep their work in custom/, future releases can refresh defaults/ and scripts/ without trampling local content.