Bastian Greshake Tzovaras

[![a black and white photo of a swarm of pigeons
mid-flight](/assets/images/2024-09-10-birds.jpg)](/assets/images/2024-09-10-birds.jpg)

I have recently [started to move my personal code repositories away from
GitHub](/from-codeberg), in favor of hosting them with a [smaller,
independent and collectively managed
alternative](https://codeberg.org/) - including for this static website.
In the same spirit, I was also interested in whether I could be doing my
small part to diversify my overall web hosting approach. Because, as
nicely outlined in [*Any Technology Indistinguishable From Magic is
Hiding
Something*](https://www.fromjason.xyz/p/notebook/any-technology-indistinguishable-from-magic-is-hiding-something/)
by Jason, the cloud is not only just other people's computers, but 3/4th
of those computers are owned by Google, Amazon & Microsoft.

So, I wanted to get started with non-essential services that I could
potentially self-deploy on some small hoster (i.e. I didn't want to run
my own mail server just yet). As a simple and affordable,
pay-what-you-want hoster, I went with
[*Uberspace*](https://uberspace.de/en/), which provides a simple but
well-equipped Linux shell to run your things on.

I decided to start off with
[*FreshRSS*](https://github.com/FreshRSS/FreshRSS/)^[\[1\]](#fn1)^ -
which is an RSS reader that can be accessed from the web, but also
through an API to tie in with my RSS-reader programs on my computers and
phone - and a *[Wallabag](https://github.com/wallabag)*, a read-later
service to jot down things to read. And luckily, the [collectively
written experimental documentation of
Uberspace](https://lab.uberspace.de/) helpfully provided instructions
for easily setting up both tools!

At about the same time I also [moved the code for my little
*PersonalAPI* Django-app to
*Codeberg*](https://codeberg.org/gedankenstuecke/personal-api). As part
of that move, I had to figure out how to get
*[Woodpecker](https://woodpecker-ci.org/)*, the CI that Codeberg kindly
provides, to automatically deploy any changes to *Heroku* - where the
little Django-app lived so far. In the end, [I managed to write a little
CI
script](https://codeberg.org/gedankenstuecke/personal-api/src/commit/b2058c9d617cea07d42015e63683f9ecd04963ff/.woodpecker.yaml)
that used the Heroku API to push changes.

But that made me wonder: Instead of using Heroku, could I just get that
Django-app to run on Uberspace too? [Heroku was bought by Salesforce in
2010](https://en.wikipedia.org/wiki/Heroku), and while for a while it
used to be free for small hobby projects like my *Personal API* project,
just using their smallest database by now costs a good bit of money. And
remember how 75% of all "cloud" services are just Amazon, Google or
Microsoft? Heroku is also just Amazon's AWS with a fake mustache.

Just as for *Wallabag* and *FreshRSS*, the Uberspace Lab docs have a
good [starting point on how to get Django apps running on their
infrastructure](https://lab.uberspace.de/guide_django/). I just made
some minor tweaks to that, to re-use the `pipenv`{.language-plaintext
.highlighter-rouge}-setup of the existing deployment to encapsulate the
dependency/Python versions. But even with that, it was extremely quick
and painless to get it up and running! It led to the next problem
though: How to automate the deployment on the Uberspace?

The Uberspace lab docs didn't provide a best pathway for CI deployments
that weren't just based on `rsync`{.language-plaintext
.highlighter-rouge}-ing files over. But with some research I found
[`webhook`{.language-plaintext
.highlighter-rouge}](https://github.com/adnanh/webhook), which can
provide a quite simple way to setup your own webhooks that can be
triggered by sending `GET`{.language-plaintext .highlighter-rouge} or
`POST`{.language-plaintext .highlighter-rouge} requests. It turned out
to be quite easy to install even. In the spirit of giving back to the
great *lab*-documentation, I've already [made a successful PR to expand
the documentation on a section on how to install
`webhook`{.language-plaintext
.highlighter-rouge}](https://lab.uberspace.de/guide_webhook/).

When triggered, my webhook for deploying the *PersonalAPI* fetches the
latest version of the code from *Codeberg*, applies any potential
database migrations, re-collects the static files and restarts the
web-server for good measure. With that in place, I just needed to [adapt
the CI-script that is triggered on
Codeberg](https://codeberg.org/gedankenstuecke/personal-api/src/commit/f083ef8ed01777c1ecc797684d38a9d2a6cb9e33/.woodpecker.yaml)
to be good to go.

I'm really happy with that strung-together solution (and the other small
bits of self-deployed solutions). First of all, it lets me take some
more control over things, while learning a few new things in the process
and hopefully also lessening the burden on others that kindly host
publicly accessible tools. Secondly, it helps me to move away from the
over-reliance on big-tech hosters. Instead of throwing too much money
each month at Heroku/Salesforce/AWS (or some *Software as a
Service*-provider), I'd much rather throw about the same amount of money
at a small, independent hoster.

------------------------------------------------------------------------

Links to the respective how-tos/configs:

- [Installing Webhooks on
  Uberspace](https://lab.uberspace.de/guide_webhook/)
- [My *Woodpecker* CI
  pipeline](https://codeberg.org/gedankenstuecke/personal-api/src/commit/f083ef8ed01777c1ecc797684d38a9d2a6cb9e33/.woodpecker.yaml)

My `redeploy.sh`{.language-plaintext .highlighter-rouge} simply consists
of:

:::: {.language-plaintext .highlighter-rouge}
::: {.highlight}
``` highlight
#!/bin/env bash

REPO="${HOME}/personal-api/"

git -C ${REPO} fetch && git -C ${REPO} rebase
cd ${REPO}
pipenv run ./manage.py migrate
pipenv run ./manage.py collectstatic --noinput

supervisorctl restart myapi
```
:::
::::

------------------------------------------------------------------------

[[\[1\]](#fn1-anchor) I already switched to another free FreshRSS
instance back when *Feedly* had [started its union-busting
services](https://www.citationneeded.news/feedly-launches-strikebreaking-as/),
but thought I could just as well deploy it myself.]{.small}


I have recently started to move my personal code repositories away from GitHub, in favor of hosting them with a smaller, independent and collectively managed alternative - including for this static website. In the same spirit, I was also interested in whether I could be doing my small part to diversify my overall web hosting approach.

Self-deploying more of my own small web

[![a black and white photo of a person sitting on a fence overlooking a
mountain
scene](/assets/images/2024-07-22-hagiang.jpg)](/assets/images/2024-07-22-hagiang.jpg)

In the [last blog post](/seizing-means-of-computation/), 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](https://codeberg.org/)
as a potential alternative that is based on
[forgejo](https://forgejo.org/) and provides [static page
hosting](https://codeberg.page/).

Beyond actually running on open source software, I particularly like the
idea of how they organize [the governance of the
platform](https://docs.codeberg.org/getting-started/what-is-codeberg/#what-is-codeberg-e.v.%3F):
Codeberg is structured as a registered non-profit association (or
*eingetragener Verein*) in Berlin. 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](https://tzovar.as/one-button-tracker/), which
both are based on static hosting.

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](https://docs.codeberg.org/codeberg-pages/) 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*](https://woodpecker-ci.org/). The CI can can create the
build based on a `source`{.language-plaintext .highlighter-rouge}
repository to then push the output into a `pages`{.language-plaintext
.highlighter-rouge} repository that codeberg.page can then serve.
Luckily, Codeberg [even provides an example `yaml`{.language-plaintext
.highlighter-rouge} Woodpecker config
file](https://codeberg.org/Codeberg-CI/examples/src/branch/main/Jekyll/.woodpecker)
for this.

As this all worked like a charm, I [flipped the DNS settings for my
domain
yesterday](https://scholar.social/@gedankenstuecke/112823968573749986)
and since then this page is being delivered through Codeberg. The one
thing I then noticed was that [Codeberg does not handle custom domain
settings in 100% the same way that GitHub
does](https://codeberg.org/Codeberg/Community/issues/1525): With GitHub,
once you have setup `mydomain.tld`{.language-plaintext
.highlighter-rouge} for the main user GH page, all further
project-repositories will be accessible as
`mydomain.tld/project_repo_name`{.language-plaintext .highlighter-rouge}
(unless you setup a custom domain for them too), which does not happen
with Codeberg.page.

But luckily, there's an easy - albeit slightly inelegant - fix for it:
Codeberg.page also looks for a `_redirects`{.language-plaintext
.highlighter-rouge} file, in [which one can specify
redirects](https://docs.codeberg.org/codeberg-pages/redirects/). Which
is what I did for the *one button tracker*, which before was accessible
at `tzovar.as/one-button-tracker`{.language-plaintext
.highlighter-rouge}, 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/`{.language-plaintext
.highlighter-rouge}.

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](https://codeberg.org/gedankenstuecke/pages-source)
- [final pages repository](https://codeberg.org/gedankenstuecke/pages)
- [Woodpecker
  setup](https://codeberg.org/gedankenstuecke/pages-source/src/branch/master/.woodpecker.yaml)
- [`_redirects`{.language-plaintext
  .highlighter-rouge}](https://codeberg.org/gedankenstuecke/pages-source/src/branch/master/_redirects)


In the last blog post, 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 as a potential alternative that is based on forgejo and provides static page hosting.

Messaggi di Rogue Scholar

Self-deploying more of my own small web

Code from some mountaintop