Slash: a self-hosted shortcut server for team links

The problem Slash targets: links that nobody can remember

The README opens with a specific complaint. Important information in a workplace is scattered across email, chat and web pages, and the links that point to it are long, hard to recall and easy to lose. Slash's answer is to replace those URLs with a readable shortcut of the form s/shortcut, so a person can type or paste a short string instead of hunting through a thread.

The intended user is a team that already self-hosts something and wants link sharing to sit next to it, not inside a third-party service. The topics list on the repository includes self-hosted, bookmarks and link-sharing, which matches that reading. If you only need a personal bookmark bar, the feature set here is larger than the problem.

Shortcuts, tags and collections: how the data is organised

The README describes three layers. A shortcut is a customizable s/ link that points at any URL. Tags categorise those shortcuts. A collection groups shortcuts so they can be shared with anyone, on any browser, or kept visible only to teammates. Analytics on link traffic and sources are listed as a feature, so the server records visits rather than only resolving redirects.

The repository layout supports a conventional split. There is a frontend/ directory alongside internal/, server/, store/ and proto/, and the Dockerfile builds both halves: a Node stage compiles the web frontend with pnpm, and a Go stage compiles the binary with the frontend dist copied into server/route/frontend/dist. The result is a single Alpine image that serves the API and the UI from one process. Storage is SQLite, per the repository topics, and the Dockerfile declares /var/opt/slash as the volume where data lives.

That single-binary, single-file design is the main architectural decision. It keeps deployment small, and it also means the database is a file you back up by copying, not a service you scale out. The README does not discuss running multiple Slash instances against one database.

Installing Slash with Docker and creating a first shortcut

The README gives a one-line Docker command. It publishes port 5231, names the container slash, and mounts the host directory ~/.slash as /var/opt/slash inside the container, which is where the data directory is declared in the Dockerfile.

docker run -d --name slash -p 5231:5231 -v ~/.slash/:/var/opt/slash yourselfhosted/slash:latest

If you prefer Compose, the repository ships a docker-compose.yml that does the same thing with a named volume instead of a host path, and restart: unless-stopped so the container comes back after a reboot.

services:
  slash:
    image: yourselfhosted/slash:latest
    container_name: slash
    ports:
      - 5231:5231
    volumes:
      - slash:/var/opt/slash
    restart: unless-stopped

After the container is up, the UI is reachable on port 5231 of the host. The Dockerfile sets SLASH_MODE to prod and SLASH_PORT to 5231 as environment variables, so the defaults need no configuration. The README points to docs/getting-started/shortcuts.md for the first real task, creating a shortcut, and to docs/getting-started/collections.md for grouping them. Those two documents are where the actual creation flow lives; the README itself only states that shortcuts take the form s/shortcut.

For browser use, the README lists an extension for Chromium-based browsers on the Chrome Web Store and one for Firefox on Firefox Add-ons, with the stated purpose of reaching a shortcut from the search bar.

Where Slash is the wrong tool

Slash is a self-hosted service, not a public shortener. Nothing in the README promises a custom domain, a CDN, or a redirect endpoint you can hand to people outside your network. The shortcuts are meant for you and your teammates, with an option to share a collection publicly, which is a different thing from operating a shortener for anonymous traffic.

There is also a documentation gap around operations. The README covers installation and the two getting-started guides, but it does not document upgrade or rollback procedure. The Dockerfile pins nothing beyond the image tag latest, and the most recent release listed is v0.5.3 from 2024-02-06, so anyone running latest is tracking a moving image while the tagged releases sit further back. If your environment requires an auditable change process, that mismatch between the image tag and the release list is the first thing to resolve.

Finally, analytics on traffic and sources implies the server sees every click on a shortcut. For a team that treats link metadata as sensitive, that is a deliberate trade to accept or reject before deployment, and the README does not describe what is recorded or for how long.

How Slash differs from a plain bookmark manager

A browser bookmark manager stores links locally and syncs them through a vendor account. Slash stores them on a server you control and resolves them through an s/ prefix, which makes the link shareable by pasting a short string rather than exporting a bookmark file. The collection feature is the clearest expression of that difference: the README describes sharing a collection with anyone, on any browser, which a bookmark folder cannot do without an account on the same sync service.

The cost is operational. A bookmark manager has no port, no volume and no container to keep running. Slash has all three, and the repository's last push was on 2026-08-24, so the codebase is moving even though the newest tagged release predates that by more than two years. Anyone comparing the two should weigh a hosted sync account against a container they patch themselves.

Licence and the cost of keeping Slash running

Slash is licensed AGPL-3.0. For a team running the unmodified image internally, that is the same practical position as most self-hosted tools. The copyleft obligation becomes relevant if you modify the code and let users interact with it over a network, because the AGPL extends source disclosure to that case. That is a description of the licence text, not legal advice; read the LICENSE file in the repository and involve counsel if you plan to fork.

Upgrade cost is the other ongoing item. The Dockerfile builds from alpine:latest, golang:1.23-alpine and node:22-alpine, so a rebuild pulls newer base images each time. Because the README does not document a migration step between versions, the safe habit is to back up the /var/opt/slash volume before changing the image, since that directory holds the SQLite data. The tagged releases stop at v0.5.3, so pinning to that tag is the only way to avoid tracking latest, and the release notes are the place to check whether a schema change is described.

What to check before you commit to Slash

Three things decide whether Slash fits. First, whether the s/ shortcut form works for your team's habits; the README's example is s/shortcut, and the browser extension is the intended fast path for reaching it. Second, whether you want click analytics at all, since the feature is listed but its data handling is not described. Third, whether you can live with the release cadence: the newest tagged release is v0.5.3, while the repository's last push was on 2026-08-24.

The docs directory is the place to read before deploying. docs/install.md covers self-hosting with Docker, and the two getting-started files cover shortcuts and collections. If those three pages answer your questions about creating, sharing and organising links, the one-command install makes the trial cheap. If they leave upgrade and data handling open, that is the gap to close first.

Editorial conclusion

Adopt Slash if your team keeps pasting the same long URLs into chat and you want an s/ prefix that resolves inside your own network. Do not adopt it if you need a public shortener with custom domains, or if you need a documented upgrade path: the README does not cover rollback or migration between versions, so verify the release notes for v0.5.3 before replacing a running instance. Check the licence file first, because AGPL-3.0 changes what you can do with a modified fork.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. yourselfhosted/slash on GitHub