Golang and vanity domains; mitigating git forge lock-in

One Sunday I decided to finally tackle the question of setting up a golang vanity domain.

The source code for my forum software Cerca has historically been hosted at Github. Cerca has a useful package called util consisting of little utilities I’ve written which are useful in my other projects. The util package can be imported from one of these other projects as:

import (
        "github.com/cblgh/cerca/util"
)

Having set up a “golang vanity domain”, it can instead be imported as:

import (
        "gomod.cblgh.org/cerca/util"
)

At a glance it seems like it’s only useful for showing off my own domain. But the reason I set it up is less out of vanity and more about avoiding git forge lock-in.

With that in place, it doesn’t matter if i decide to switch my git forge later. This will make it a lot easier to get off Github for my projects (increasingly important these days). It also lets me flexibly move my projects around as needed, if say the community-run Codeberg.org implodes or if I want to keep the source code somewhere else or even spread projects across different forges.

Now that I have the puzzle pieces for setting up a vanity domain for one project, I have the ability to direct any of my projects’ packages to be imported as:

import "gomod.cblgh.org/<project>"

Below are instructions on how I set this up. I use a test project called gomod-test-redirect as an example.

I’ll end this section by noting that it was all very quick and frictionless to set up!

Setting up a vanity domain with `gomod-test-redirect`

I can import the module pack in the Github-hosted repository https://github.com/cblgh/gomod-test-redirect/ by specifiying:

import (
"gomod.cblgh.org/gomod-test-redirect/pack"
)

This works because my web server is serving the following file, called gomod-test-redirect (note: no .html file extension!).

<!DOCTYPE html>
<html>
    <head>
	
	<meta name="go-import" content="gomod.cblgh.org/gomod-test-redirect git https://github.com/cblgh/gomod-test-redirect">
	<meta http-equiv="refresh" content="0;URL='https://github.com/cblgh/gomod-test-redirect'">
    </head>
    <body>
	Redirecting you to the <a href="https://github.com/cblgh/gomod-test-redirect">project page</a>...
    </body>
</html>

I generate the above html for any migrated projects using a template and a static site generator I’ve written, but more about that in another post!

The file above basically says “hey, if you came here looking for package gomod-test-redirect you can get the source code for that from https://github.com/cblgh/gomod-test-redirect, which is where the code is currently hosted.

When I switch the git host away from Github to something else, I just have to change this html file. However, everyone who imports the package in their go files won’t have to do anything - their imports stay the same i.e. gomod.cblgh.org/gomod-test-redirect!

The nginx entry (i.e. my web server) that makes this possible by serving the file looks like:

server {
    listen      443 ssl http2;      # serve over https

    server_name  gomod.cblgh.org;   # the good sauce

    include tls_settings;           # this is just a file i have that contains all the tls stuff needed

    root /var/www/html/_gomod;      # the directory on my webserver being served is called `_gomod`
                                    # but you can call it anything
}

Many thanks to https://gianarb.it/blog/go-mod-vanity-url which provided a great tutorial for how to set this all up.

Golang and vanity domains; mitigating git forge lock-in

Setting up a vanity domain with gomod-test-redirect

Setting up a vanity domain with `gomod-test-redirect`