Code from some mountaintop

a black and white photo of a person sitting on a fence overlooking a mountain scene[1]

1: a black and white photo of a person sitting on a fence overlooking a mountain scene

In the last blog post[1], I had mentioned that I was looking to move away some of my personal code hosting away from GitHub (GH), to avoid being locked in into yet another tech giant. Instead, I wanted to move to a proper free alternative. On Mastodon, lots of folks recommended checking out Codeberg[2] as a potential alternative that is based on forgejo[3] and provides static page hosting[4].

1: last blog post
2: Codeberg
3: forgejo
4: static page hosting

Beyond actually running on open source software, I particularly like the idea of how they organize the governance of the platform[1]: Codeberg is structured as a registered non-profit association (or _eingetragener Verein_) in Berlin.

1: the governance of the platform

And while one doesn't have to become a (paying & active) member of the association to make an account, I love that this is an option. Beyond the financial support, the membership also means having a more active role in the governance, including the ability to vote on the presidium & board.

And so I made the switch over the last week, at least for the first two projects: This website you're currently reading and the _One Button Tracker_ for the Puck.js[1], which both are based on static hosting.

1: _One Button Tracker_ for the Puck.js

As Codeberg, unlike GH pages does not automatically integrate with static site generators like Jekyll a bit more manual setup was needed, but thanks to the extensive documentation[1] that was quite doable. To automate a build from a static site generator like Jekyll (which this site uses), one can use of Codeberg's deployment of the _Woodpecker CI_[2]. The CI can can create the build based on a `source` repository to then push the output into a `pages` repository that codeberg.page can then serve. Luckily, Codeberg even provides an example `yaml` Woodpecker config file[3] for this.

1: thanks to the extensive documentation
2: _Woodpecker CI_
3: even provides an example `yaml` Woodpecker config file

As this all worked like a charm, I flipped the DNS settings for my domain yesterday[1] and since then this page is being delivered through Codeberg.

1: flipped the DNS settings for my domain yesterday

The one thing I then noticed was that Codeberg does not handle custom domain settings in 100% the same way that GitHub does[1]: With GitHub, once you have setup `mydomain.tld` for the main user GH page, all further project-repositories will be accessible as `mydomain.tld/project_repo_name` (unless you setup a custom domain for them too), which does not happen with Codeberg.page.

1: Codeberg does not handle custom domain settings in 100% the same way that GitHub does

But luckily, there's an easy - albeit slightly inelegant - fix for it: Codeberg.page also looks for a `_redirects` file, in which one can specify redirects[1]. Which is what I did for the _one button tracker_, which before was accessible at `tzovar.as/one-button-tracker`, despite being hosted in a different repository. With the redirect that link will still work, despite now being at `https://gedankenstuecke.codeberg.page/one-button-tracker/`.

1: which one can specify redirects

When I started the process of moving even just these two repositories I was slightly worried about how many things could (and thus probably would) break. But it turns out that this was extremely painless! And, I'm super happy to have these pages and projects now be hosted in a place a lot more aligned to my own interests and values. Let's see if replacing Google as my email provider will be on the menu next!

--- Yes, I also use these posts to document this stuff for my forgetful self, so here are the links to the setup files:

- source repository[1]

1: source repository

- final pages repository[1]

- Woodpecker setup[2]

1: final pages repository
2: Woodpecker setup

- `_redirects`[1]

1: `_redirects`