kellegous/go: a corporate short-link service written in Go

The go link, and why companies keep building them

The Background section of the README is the best part of the documentation, and it is about the idea rather than the code. The author first encountered go links at Google, where anyone on the corporate network could register a URL shortcut that redirected to the appropriate page, so that http://go/bigtable took you to something about the BigTable data storage system.

The origin story is specific. The first go service at Google was written by Benjamin Staffin, and the author says he described it as AOL keywords for the corporate network, and that it was built to end the never-ending stream of requests for internal CNAME entries. That last clause is the real argument. A shortcut service replaces a queue of DNS change requests and wiki edits with a single registry that anyone on the network can update.

The author also notes that this is contagious: Etsy made one after seeing that Twitter had one, and many former Googlers built or contributed to similar systems after leaving.

One functional difference from Google's version is called out. This go service is also capable of generating short links for you, so it does the internal shortcut registry and the public style shortener in one binary.

One Go binary, one data directory, port 8067

Installation is the classic Go workflow, and the README notes the irony that the tool is written in Go:

GOPATH=`pwd` go install github.com/kellegous/go
bin/go

Setting GOPATH to the current directory is what keeps the build out of your global module path, and the resulting binary lands in `bin/go`.

By default the service puts all of its data in the directory `data` and listens on the port `8067`. Both are configurable, with the `--data=/path/to/data` and `--addr=:80` command line flags. So the operational surface of the service is two flags and a directory, which is about as small as a network service gets.

The container image follows the same minimalism. The Dockerfile builds in a prepared build image, copies the source in, and produces a binary in a `scratch` image with nothing else in it:

FROM scratch

COPY --from=build /src/bin/go /

EXPOSE 8067

ENTRYPOINT [ "/go" ]
CMD ["--data=/data"]

A static binary on a scratch base, with the data directory mounted at `/data` by the container runtime, is a deployment that carries no operating system with it at all.

The deployment trick is DNS, not the service

The DNS Setup section is the part that makes the whole idea work, and it is not a detail of the application.

To get the most benefit from the service you should set up a DNS entry on your local network, `go.corp.mycompany.com`, and make sure that `corp.mycompany.com` is in the search domains for each user on the network. The README says this is usually easily accomplished by configuring your DHCP server.

That is the mechanism. The search domain is what lets someone type `go/bigtable` rather than a full hostname, so the browser resolves `go` inside the corporate suffix, the DNS entry points at the service, and the path after the slash is the shortcut name. The convenience is not in the software at all, it is in the network configuration, and that has a practical consequence for anyone evaluating the project: the deployment is not just running a binary, it is also touching DHCP and DNS.

The README also spells out what you get once it is set up. Typing `go` into the browser takes you to the service where you can register shortcuts, and those shortcuts are also available by typing `go/shortcut`. The root path is therefore the registry page, which is the piece that makes the system usable by everyone rather than by one person with configuration access.

Three URL shapes: register, follow, shorten

The Using the Service section is three sentences long, and they cover the whole feature set.

To create a new shortcut, type `go/edit/my-shortcut` and enter the URL. To visit a shortcut, type `go/my-shortcut` and you are redirected to the URL. And to shorten a URL, type `go` and enter the URL.

The `go/edit/` prefix is the interesting part. It means the editing interface is a path in the same namespace as the shortcuts themselves, so there is no separate admin interface, no separate login and no separate hostname to remember. The redirect and the editor live at the same origin, and anyone who can reach the service can create a shortcut.

That last point is the design decision with the most consequence for a deployment. There is no mention in the documentation of an authentication layer or of roles, and the background section describes the original Google service as being open to anyone on the corporate network. The implicit assumption is that being on the network is the authorisation. In a flat corporate network that may be fine, and in any environment where not everyone on the network should be able to publish shortcuts, something has to be added around it.

A Go service with a React front end baked into the binary

The repository layout shows a project that has grown well past a single Go file. There is a `cmd` directory with the binaries, an `internal` directory for the packages, a `ui` directory holding the front-end source, an `etc` directory, a `v2` directory, and the Go module files `go.mod` and `go.sum`.

The front end is a separate application. The `package.json` is named `go-ui`, is marked private, and uses React 19 with react-dom, Vite 6, TypeScript around 5.7, sass, and eslint with the react-hooks and react-refresh plugins. There are separate tsconfig files for the app and the node tooling, and a vite.config.ts at the root.

The interesting part is how the two halves are joined, and the Makefile shows it. The Go binary depends on the built UI assets:

bin/go: cmd/go/main.go $(ASSETS) $(shell find internal -name '*.go')
	go build -o $@ ./cmd/go

where the assets are `internal/ui/assets/index.html` and `internal/ui/assets/edit/index.html`, each produced by `npm run build` from the `ui` directory. The UI is therefore compiled into the binary, which is why the container image can be a single file on a scratch base. There is no web server, no separate asset host and no version skew between an API and a client, at the cost of a Node toolchain in the build.

A `develop` target exists for local work, running the binary with a different address and with metrics and dev mode enabled:

develop: bin/go
	bin/go --addr=:4025 --metrics=true --dev-mode=.:4026

Configuration through viper, storage in leveldb, and a Firestore dependency

The module file is where the design decisions show up. The module is `github.com/kellegous/go` and it targets go 1.27.2.

The direct dependencies include `spf13/pflag` and `spf13/viper` for configuration, `syndtr/goleveldb` for storage, `github.com/kellegous/glue` for the HTTP routing, `golang.org/x/oauth2` for authentication flows, `cloud.google.com/go/firestore` and `google.golang.org/api` and `google.golang.org/grpc` for Google Cloud access, and `github.com/spf13/pflag` again for flags.

LevelDB is the local store, which fits a service whose data is a directory of shortcuts and which is meant to be run on a machine you control. The Google Cloud dependencies are for the parts of the service that talk to Google, and the oauth2 dependency suggests the sign-in flow for the Google side of things. The `glue` router, from the same author, is the HTTP layer, and the `prometheus/client_golang` indirect dependency is where the `--metrics=true` flag in the develop target gets its endpoint.

Two things are worth flagging for an adopter. The Google Cloud dependencies are in the module even for a purely local deployment, so the binary is not as self-contained as a scratch image suggests at the dependency level. And the presence of several storage and auth related libraries means the configuration decides which path is taken, and the README does not document the configuration file format.

MIT licensed, no releases, and a publish target for two architectures

The licence is MIT, with the LICENSE file at the root of the repository. The repository is not archived and the last push was on 2026-10-18, so the branch is current, but the repository has no GitHub releases, so there is no tagged version to pin and the release history is only visible in the commit log.

The publishing story is in the Makefile rather than in the documentation. A `bin/publish` command is built from `cmd/publish/main.go`, and the `publish` target runs it with a `latest` tag, a tag built from the short commit SHA, two platform arguments for linux/arm64 and linux/amd64, and the image name `kellegous/go`:

publish: bin/publish
	bin/publish \
		--tag=latest \
		--tag=$(shell git rev-parse --short $(SHA)) \
		--platform=linux/arm64 \
		--platform=linux/amd64 \
		--image=kellegous/go

So the deployment target is a container image published for both amd64 and arm64, tagged both by a friendly name and by the exact commit it was built from. The commit tag is the useful one for a team that wants to pin, since there is no release tag to point at.

The Makefile also carries a `nuke` target that removes `bin`, `internal/ui/assets` and `node_modules`, and a `clean` target that stops short of the node modules. Between them they cover the two build systems the project carries, Go and Node.

Editorial conclusion

This service fits an organisation with an internal network and a set of destinations everyone keeps asking about, where a shared shortcut beats another wiki page or a DNS CNAME request. It is the wrong tool for a public link shortener, since the design assumes a controlled network and a search domain that resolves to it. Verify first that your DNS setup can add a hostname and push a search domain to clients, that the data directory is on storage that persists, and which of the storage backends the configuration selects, since the dependency list points at several.

Frequently asked questions

Official sources

1. Issues
2. kellegous/go on GitHub
3. License: MIT
4. README