Slash: self-hosted s/ short links for teams that keep losing URLs
An open source, self-hosted platform for sharing and managing your most frequently used links. Easily create customizable, human-readable shortcuts to streamline your link management.
At a glance
- What is it?
- Slash turns long URLs into readable s/shortcut links, stored in your own deployment and shared through Collections. It is a small, focused tool, and the material available on it is thin in a few places worth knowing before you adopt it.
- Who is it for?
- Adopt Slash if your team keeps re-pasting the same long URLs into chat and you want a private s/ namespace you control, and if you are comfortable running a container against a SQLite volume. Do not adopt it if you need a URL shortener with a public redirect domain for external audiences, or if you require a documented upgrade path: the release history shows v0.5.3 in February 2024 and the README says nothing about migrating between versions.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Slash picks: links that get lost in chat instead of living in a namespace
The README frames the problem in workplace terms: essential information sits scattered across the cloud as links, and those links are awkward to remember and awkward to pass on. Slash's answer is to give each one a human-readable shortcut with an s/ prefix, so a long URL becomes something like s/shortcut. That is a narrower goal than a general bookmark manager. The unit of value is the shortcut string itself, and the product assumes you will type or paste it rather than browse a folder tree. Tags exist for categorising links, and Collections exist for sharing a group of shortcuts with anyone, on any browser, according to the feature list. The intended user is a team that already has a shared chat channel and a habit of dropping URLs into it. If your problem is personal bookmarking on one machine, Slash is heavier than the job needs. If your problem is that five people keep asking for the same staging dashboard URL, the shortcut model fits.
How a shortcut becomes a redirect: what the repository actually tells you
The README describes Slash as self-hosted and lists the stack indirectly through the repository topics: Go, React, SQLite. The Docker command mounts a host directory at /var/opt/slash and publishes port 5231, which is the strongest architectural signal in the supplied material. A single container, a single data directory, a single port. SQLite in the topics list means the persistence layer is a file inside that mounted volume rather than an external database service, so backup and migration are file operations, not connection-string changes. Beyond that, the material does not spell out the request flow. It does not say whether the s/ prefix is resolved by a web route, a browser-side lookup, or both, and it does not describe how the extension talks to a self-hosted instance. Those are the two questions I would want answered before committing, and the README does not answer them. What is confirmed is the shape: a Go backend serving a React front end, backed by SQLite, containerised, with a browser extension as a second client.
Getting it running: one docker run, one volume, one port
The README gives a single command for deployment: docker run -d --name slash -p 5231:5231 -v ~/.slash/:/var/opt/slash yourselfhosted/slash:latest. That is the whole quick start. The volume mount is the part that matters, because /var/opt/slash is where state lives; skip the -v flag and you lose your shortcuts when the container is replaced. The README points to docs/install.md for what it calls self-hosting with Docker, so that file is the place to look for anything the one-liner omits, such as reverse proxy configuration or environment variables. It also links docs/getting-started/shortcuts.md and docs/getting-started/collections.md, which are the two concepts you need to understand before the tool is useful. For the browser extension, the README separates Chromium-based browsers (Chrome, Edge, Arc) from Firefox and gives store links for both. Installing the extension is not optional if you want the search-bar behaviour the feature list advertises; the web interface and the extension are described as different entry points to the same shortcuts.
Collections and the public/private split are the real access-control surface
Two features carry most of the sharing semantics. The first is the choice to share a short link publicly or only with teammates. The second is Collections, which the README describes as a way to share your shortcuts with anyone, on any browser. That phrasing hints at a boundary worth understanding before you deploy: a Collection is designed to be reachable without an account, while the default sharing posture for individual links is narrower. The README does not state how authentication works, what distinguishes a teammate from an anonymous visitor, or whether Collections are public by default. Those are exactly the details that determine whether Slash is safe to expose on the open internet, and the supplied material does not settle them. Treat the access model as something to verify in docs/install.md and in the application itself rather than something to assume. Link traffic and source analytics are listed as a feature, which implies the server records click events, but the README says nothing about retention, storage growth, or whether analytics can be turned off.
Where Slash is the wrong tool, and what to use instead
Slash assumes a private namespace. The s/ prefix is a convention your team types, not a domain the whole internet resolves. If you need a public shortener where an arbitrary visitor clicks a link and lands on the destination, Slash is the wrong shape, and so is any self-hosted tool built around an internal prefix. For that job the conventional choice is a dedicated shortener such as Shlink, which is designed around public short domains and HTTP redirects rather than around an s/ lookup your colleagues remember. The difference in approach is where the identifier lives: Shlink's short code is the URL you hand out, while Slash's s/shortcut is a token you type into a browser you already control, with the extension or the web app resolving it. If your actual need is a team wiki with stable page URLs, neither tool is right and a wiki is. The honest framing is that Slash competes with the pinned-message habit, not with link shorteners, and it wins only if your team will actually use the prefix.
Maintenance, licence, and the upgrade question the README does not answer
Slash is licensed AGPL-3.0. That is a copyleft licence with a network clause: if you modify Slash and let users interact with it over a network, the licence's terms about offering source to those users come into play. I am not giving legal advice, and whether that matters depends on whether you fork the code or run it unmodified. Running the published container as-is is the common case and the one the README documents. On maintenance, the release history is the useful signal: v0.5.1 in December 2023, v0.5.2 in January 2024, v0.5.3 in February 2024. Three patch-level releases in three months, then nothing in the release list after that, even though the repository shows a push in August 2026. The README does not describe a migration process, schema versioning, or a backup procedure beyond the volume mount. With SQLite in a mounted directory, your upgrade safety net is a copy of that directory, and the docs do not tell you to make one. That is a gap, not a dealbreaker, but it is the kind of gap that turns a routine image pull into an afternoon.
Who should run Slash, and what to check before the first container starts
Slash fits a small team that already shares links in chat, wants a private s/ namespace, and has someone willing to run a container and own a volume. It does not fit anyone who needs a public redirect domain, anyone who wants a hosted service with no operational surface, or anyone who needs documented upgrade and backup procedures before they will put a tool in front of colleagues. The verification list is short and specific. Read docs/install.md for the configuration the README's docker run command leaves out. Read docs/getting-started/shortcuts.md and docs/getting-started/collections.md to confirm the sharing model matches your expectations about who can see what. Decide whether the s/ prefix works in the browsers your team uses, and confirm how the extension is configured to point at your instance rather than at a default. Then take a copy of the directory you mounted at /var/opt/slash before you pull a newer tag, because nothing in the supplied documentation says the project will do that for you.
Editorial conclusion
Adopt Slash if your team keeps re-pasting the same long URLs into chat and you want a private s/ namespace you control, and if you are comfortable running a container against a SQLite volume. Do not adopt it if you need a URL shortener with a public redirect domain for external audiences, or if you require a documented upgrade path: the release history shows v0.5.3 in February 2024 and the README says nothing about migrating between versions. Before deploying, read docs/install.md, decide whether the s/ prefix is reachable from the browsers your team actually uses, and confirm how the browser extension resolves shortcuts against your own instance rather than someone else's.
Community notes