I’ve used FluxCD in the past and have looked into ArgoCD, but honestly, I’ve not seen any big benefit from either to be honest. I use k8s both at home and at work, and in both cases, we do “imperative” deploys: you run helm install ... either directly or via the CI and stuff is deployed.

So for example at my last job, our GitLab CI just had a section triggered exclusively for merges into master that ran helm install ... for all three environments. We had three values.yaml files, one for each environment, and when we wanted to deploy a new version, the process was:

1. Create a tag for our release version (ie. 1.2.3) and push it to the repo. This would trigger a build and push the resulting image into the container registry.
2. Push an update to the repo with the new tag set in the appropriate Helm values file. If we wanted to deploy 1.2.3 to development but not yet to staging or production, then the tag: value in each of the environment files would look like this:

• k8s/chart/environments/development.yaml: tag: 1.2.3
• k8s/chart/environments/staging.yaml: tag: 1.2.2
• k8s/chart/environments/production.yaml: tag: 1.2.2

Once that change is pushed, the CI will automatically apply it with helm install ... and make sure that all three environments are what they’re supposed to be.

As for dependent services, that should all be in your Helm chart so they’re stood up and torn down together. The specific case you mention about “Service A” being dependent on “Service B” but stood up before “Service B” is ready is a classic problem, but easily solved:

The dependent service (“A” in this case) should have an entrypoint that checks for everything else before starting. Here’s what I’m using right now in a project:

#!/bin/sh

while ! nc -z postgres 5432; do
  echo "Waiting for postgres..."
  sleep 0.1
done
echo "PostgreSQL started"

touch /tmp/ready

exec "$@"

I’ve even got some code that checks that all the Django migrations have run first for the same situation. The Kubernetes philosophy is that any container should be able to die at any time and be eventually be brought back up and that every container needs to be prepared for this. Typically this means that your containers should operate on the basis of “if I can’t work, die, and hope the problem is solved by the time Kubernetes redeploys me”.

Kubernetes. For a homelab, the stripped-down k3s is fantastic and surprisingly easy to get going.

Once you’ve got Kubernetes set up, you can lean on all the many tools already out there for things like deploying complex projects (Helm) and monitoring (Prometheus/Grafana). OpenLens is a nice piece of software you can use to monitor and control your cluster too, as is k9s.

I’ll just leave this here.

As this is a new project, have you considered hosting your code somewhere other than GitHub? Codeberg and GitLab are similarly user-friendly platforms without the many downsides of supporting Microsoft.

A platform that’s down 10% of the time and that now has a reputation of locking people out of their accounts without reason for weeks at a time cannot, under any definition of the word, be considered “stable”.

I just… don’t get it. This whole community, we’re supposed to be building stuff for ourselves and each other, and for some reason people keep going to bat for a company that demonstrably holds every one of us in contempt.

Just… stop using their shitty tools already.

Why hasn’t he migrated to something more stable?

Oh I didn’t know this was available in Codeberg! Thanks for sharing.

It’s true. They’re for-profit, so the motivations are still there. Fragmentation helps a lot though. If a third of us move to one, and another third to the other, that would cripple any party’s ability to enshittify.

That’s a worthy goal, but the problem isn’t so insurmountable that we have to wait for some theoretical new feature to be available and adopted. There are three dominant players out there, one of which has demonstrated a willingness to screw everyone and the “it’s not perfect yet” excuse is getting pretty thin.

Switch to Codeberg today and there’s a good chance that this federated login will be supported there when/if it’s ever available. GitLab could do it too, and moving there will give you a bunch of nice things you don’t even get in GitHub let alone Codeberg.

But it’s long passed time to move. Microsoft has stolen our code to feed into their slop machine and enshittified the platform. Sticking around because a perfect alternative isn’t available only serves to harden the network effect that keeps GitHub dominant.

What is it going to take to push FLOSS software out of GitHub? Everyone here can move their projects literally anywhere else today. I did it for my own (roughly 10 projects) five years ago and it only took about an hour:

1. Create an account with Codeberg, GitLab, or whatever you like.
2. Use their built-in tools to copy your repo over to your new account. In GitLab’s case, this will even migrate over some of the additional features, like issues.
3. Update the places where you publish the project: PyPI, npm, whatever, with the new project home URL.
4. Archive the old project on GitHub, with a pointing link to the new project home.
5. (Optional) announce the above in any of the social spaces where people care about your project.

Oh don’t misunderstand me. I’m an atheist and think the idea of your god is ridiculous. I just think it’s even more ridiculous that a theocracy like the US could get tripped up and torn between its two favourite things: religiosity and property rights.

It points out the absurdity of both.

I love this so much.

Fun! But if you’re going to post to OpenSource, you should be sharing the code too.

I’d never heard of this list, so thanks for sharing. I have to say while some of the projects seem to have been included due to minor offences, I’m really disappointed in some of my favourite FOSS projects.

I didn’t understand what you meant by Joplin not being “fully FOSS”, so I went looking for the license. Is really quite strange. Basically they’ve used a “personal license” for some parts and the AGPL for the rest. That’s… annoying.

If the work is a “clean room” reverse engineering job, as in: you didn’t read the original source to produce your version but rather looked at the input and output and wrote new software that had the same behaviour, the this new software is not a derivative work and you can use whatever license you like.

The easy option is public domain, which effectively is a “this belongs to everyone” thing. There’s not much of a practical difference between this or MIT in my understanding.

Another option would be something that preserves the freedoms you attach to the software like the GPL or LGPL if youre feeling less aggressive. These licences compel would-be modifiers to share their changes with everyone else, preventing (for example) companies that want to build their business on top of your work and then charging you for it.

But basically, if you wrote it without referencing the original, it’s your work and you can do as you like. If you were referencing the original source though, then that’s a derivative work and you may be in violation of the copyright holder’s rights.

Or, https://justuse.org/curl/

Buy two 4tb extern drives. Copy your photos onto both. Leave on at your mom’s house in a closet. Leave the other in a locker at work or a safety deposit box.

No monthly fees, no techbro cloud capitalists.

Honestly, I’d buy 6 external 20tb drives and make 2 copies of your data on it (3 drives each) and then leave them somewhere-safe-but-not-at-home. If you have friends or family able to store them, that’d do, but also a safety deposit box is good.

If you want to make frequent updates to your backups, you could patch them into a Raspberry Pi and put it on Tailscale, then just rsync changes every regularly. Of course means that wherever youre storing the backup needs room for such a setup.

I often wonder why there isn’t a sort of collective backup sharing thing going on amongst self hosters. A sort of “I’ll host your backups if you host mine” sort of thing. Better than paying a cloud provider at any rate.

From a read of that issue, it looks like it never was.