Self-hosted URL shorteners in 2026: revisit Shlink, YOURLS and Kutt before you share another link through a public shortener

A short link looks like a small thing. It goes into a printed brochure, a QR code on a shop counter, an SMS to customers, a slide in a conference talk. Then the link outlives the campaign, the team and sometimes the shortener itself. When the shortening service changes its terms, starts showing interstitial pages or simply goes away, every printed copy points to nothing.

That is why many teams revisit the question: should short links live on our own domain, served by software we run? In this post we revisit three mature open-source options, Shlink, YOURLS and Kutt, and look at history, licences, stack, operations and security. No hands-on drill was run for this post; the facts below come from each project’s own repository, release notes and documentation as of early November 2026.

Why a short link is an operational asset

Before comparing tools, it helps to unlearn the idea that a short link is disposable. A short link is a redirect you promise to keep working. Three things follow from that:

• The domain matters more than the tool. If the links use your own domain, you can change the software behind it later. If they use someone else’s domain, you cannot.
• The database is the product. The mapping from short code to long URL is the only thing that must survive. Backups of that table are more important than the UI.
• Redirects are a security surface. An open shortener can be abused to hide phishing links behind your brand name.

Kutt’s own history is a good lesson here. The project’s README and the v3.2.4 release notes say the team no longer owns the kutt.it domain; it was deactivated by the Italian registrar and is now owned by someone else, and users were asked to move to kutt.to. The software was fine. The domain was the weak point.

Shlink

History and licence. The Shlink repository on GitHub was created in April 2016. It is licensed under MIT and describes itself as a PHP-based self-hosted URL shortener for serving short URLs under your own domain. The latest release at the time of writing is v5.1.8, published on 21 October 2026.

Stack. Shlink needs PHP 8.4 or 8.5 with extensions such as json, curl, pdo, intl, gd and gmp or bcmath. It supports MySQL, MariaDB, PostgreSQL, Microsoft SQL Server and SQLite. The Docker image can start with SQLite, but the documentation recommends an external database for production.

How it feels to run. Shlink is API-first. The core service handles redirects and visit tracking, and you manage links through its REST API, a CLI or a separate web client. This fits teams that want to generate short links from other systems, for example from a CRM, a ticketing tool or a release script.

Points to note:

• Good fit when short links are created by code, not only by people clicking in a UI.
• Multiple domains are supported, so one instance can serve more than one brand.
• Keep the API keys scoped and stored like any other secret; anyone with a key can create redirects on your domain.

YOURLS

History and licence. YOURLS (Your Own URL Shortener) is the oldest of the three and is MIT licensed. It calls itself “a set of PHP scripts” and has a long-standing plugin system. The latest release is 1.10.6 from 30 August 2026, which only fixed a wrong version string in 1.10.5.

Recent security work. The 1.10.5 release notes list useful hardening: md5 phased out in the passwordless API and credentials, hash_equals() used to resist timing attacks, cookie prefixes on HTTPS installs, an unpredictable cookie key when none is set, restricted remote title fetching for private IP addresses on public installs, and better trusted proxy support. If you run an older YOURLS, this alone is a reason to plan an upgrade.

Stack. Classic PHP with a MySQL or MariaDB database. It runs well on ordinary shared hosting or a small VM, which is why it is still common.

Points to note:

• Best fit for one owner, one domain and moderate traffic.
• The plugin ecosystem is large, but each plugin is third-party PHP code running next to your link data. Review before installing.
• Keep the install private unless you truly want a public shortener; a public YOURLS needs rate limiting and abuse handling.

Kutt

History and licence. The Kutt repository was created in February 2018 and is MIT licensed. It describes itself as a modern URL shortener with custom domain support. The latest release is v3.2.6 from 5 July 2026, which added configurable OIDC prompt options, replaced a user agent parsing library to fix reported vulnerabilities, updated nodemailer and set SameSite: Lax on signed-in cookies.

Stack. Kutt needs Node.js 20 or above. The default database is SQLite, with optional PostgreSQL or MySQL/MariaDB, and optional Redis as a cache. The repository ships several Docker Compose files for these combinations.

Features worth knowing. Custom domains, link passwords, descriptions and expiry times, private statistics, an admin page for users and links, a REST API, OIDC login, and switches to disable registration and anonymous links.

Points to note:

• Good fit for teams already comfortable running Node.js services.
• Turn off anonymous links and open registration on day one if the instance is internal.
• OIDC support means you can put it behind your existing identity provider instead of managing separate passwords.

Comparing the three in plain terms

Licence. All three are MIT. There is no licence trap here, which is not true in every category we have revisited on this blog.

Who creates the links.

• Mostly systems and scripts: Shlink, because of its API and CLI first design.
• Mostly one person or a small marketing team: YOURLS, because it is simple and familiar.
• Several users with their own logins: Kutt, because of user management and OIDC.

Database and backup.

• Shlink: pick PostgreSQL or MySQL/MariaDB for production and back it up like any other business database.
• YOURLS: one MySQL or MariaDB database; a nightly dump is usually enough.
• Kutt: SQLite is fine for small use, but then the backup is a file copy that must be taken safely; move to PostgreSQL when more people depend on it.

Performance. We did not find independent, method-documented benchmarks comparing these three, and we did not run one. For most teams the redirect path is a single indexed lookup, so the database, any cache and the reverse proxy in front will matter more than the choice of shortener. Measure with your own traffic pattern before you worry about it.

A practical checklist before you switch

1. Choose a short domain you will own for years. Renew it for multiple years and keep the registrar account under team control, not one person’s email. Kutt’s experience shows why.
2. Decide who may create links. Disable anonymous creation unless you really mean to run a public service.
3. Block abuse. Rate limit creation, log who created each link, and keep a way to disable a link quickly if it points to something harmful.
4. Avoid tracking you do not need. Visit statistics often include IP addresses and user agents. Decide retention, and anonymise where the tool allows it, keeping the Digital Personal Data Protection Act in mind if your users are in India.
5. Back up the mapping table and test a restore. A restored redirect table on a new server is the real disaster recovery test.
6. Plan the migration from your old shortener. Export old codes and import them with the same short codes where possible, so printed links keep working.
7. Put it behind your normal reverse proxy and TLS automation, and monitor the redirect endpoint like any public service.

Closing thought

A short link is a small promise to everyone who will ever click it. Revisit where that promise lives. If it lives on your own domain, with a simple database you back up, any of these three tools can keep it. Shlink suits API-driven teams, YOURLS suits small and simple setups, and Kutt suits multi-user teams with an identity provider. Pick the one that matches how your team actually creates links, not the one with the longest feature list.