A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
IMO, Gitlab CI/CD blows Github out of the water. They're not even in the same league. I recommend Gitlab + self hosted runners (it's so easy).
I've been using Gitlab for many years and host my own runners as of the past 6 months because I nearly exhausted my monthly free tier runner minutes one month.
I second GitLab CI/CD - it's a CI/CD system that just makes sense to me. That doesn't mean it doesn't have its complexities depending on your needs, but I've overall enjoyed my time working with it.
Forgejo has their own runner: https://forgejo.org/docs/latest/admin/actions/runner-installation/
I've used it on my personal machine, was very easy to setup and mostly compatible with GitHub actions out-of-the-box (including things like actions/checkout@v4).
Forgejo runners are great! I found some simple actions to do docker in docker and now build all my images with them!
please share, I'm interested in doing the same
Sure! I use Kaniko (Although I see now that it's not maintained anymore). I'll probably pull the image in locally to protect it...
Kaniko does the Docker in Docker, and I found an action that I use, but it looks like that was taken down... Luckily I archived it! Make an action in Forgejo (I have an infrastructure group that I add public repos to for actions. So this one is called action-koniko-build and all it has is this action.yml file in it:
name: Kaniko
description: Build a container image using Kaniko
inputs:
Dockerfile:
description: The Dockerfile to pass to Kaniko
required: true
image:
description: Name and tag under which to upload the image
required: true
registry:
description: Domain of the registry. Should be the same as the first path component of the tag.
required: true
username:
description: Username for the container registry
required: true
password:
description: Password for the container registry
required: true
context:
description: Workspace for the build
required: true
runs:
using: docker
image: docker://gcr.io/kaniko-project/executor:debug
entrypoint: /bin/sh
args:
- -c
- |
mkdir -p /kaniko/.docker
echo '{"auths":{"${{ inputs.registry }}":{"auth":"'$(printf "%s:%s" "${{ inputs.username }}" "${{ inputs.password }}" | base64 | tr -d '\n')'"}}}' > /kaniko/.docker/config.json
echo Config file follows!
cat /kaniko/.docker/config.json
/kaniko/executor --insecure --dockerfile ${{ inputs.Dockerfile }} --destination ${{ inputs.image }} --context dir://${{ inputs.context }}
Then, you can use it directly like:
name: Build and Deploy Docker Image
on:
push:
branches:
- main
workflow_dispatch:
jobs:
build:
runs-on: docker
steps:
# Checkout the repository
- name: Checkout code
uses: actions/checkout@v3
- name: Get current date # This is just how I label my containers, do whatever you prefer
id: date
run: echo "::set-output name=date::$(date '+%Y%m%d-%H%M')"
- uses: path.to.your.forgejo.instance:port/infrastructure/action-koniko-build@main # This is what I said above, it references your infrastructure action, on the main branch
with:
Dockerfile: cluster/charts/auth/operator/Dockerfile
image: path.to.your.forgejo.instance:port/group/repo:${{ steps.date.outputs.date }}
registry: path.to.your.forgejo.instance:port/v1
username: ${{ env.GITHUB_ACTOR }}
password: ${{ secrets.RUNNER_TOKEN }} # I haven't found a good secret option that works well, I should see if they have fixed the built-in token
context: ${{ env.GITHUB_WORKSPACE }}
I run my runners in Kubernetes in the same cluster as my forgejo instance, so this all hooks up pretty easy. Lmk if you want to see that at all if it's relevant. The big thing is that you'll need to have them be Privileged, and there's some complicated stuff where you need to run both the runner and the "dind" container together.
Thanks for the write-up! I've been trying and failing to do DOOD and POOP runners via forgejo, but I haven't had the time or energy to really dig in and figure out the issue. At this point I just want something to work so I'll give your setup a try 😎
Of course! Let me know how you run your containers and I may be able to help on that side too
Please don’t take me as a GH shill because I’m not. I’m not sure we read the same email given your projects. Actions on GH runners are dropping in cost and there’s a new fractional cost for self-hosted. For the average user, especially those on GH runners, costs are going down. Looking at your repo, you haven’t run anything since July. Your workflow files use GH runners. Nothing in your history suggests you’re leaving the free tier so I don’t get this FUD at all. General Microsoft hate? Fuck yeah. Shitty GH service? Fuck yeah. Plenty of reasons to dunk but this was not one of them. M
Self-hosted Forgejo Actions on a Codeberg repository. It was relatively easy to setup and I don't even need a VPS through my dynamic IP 5G connexion. See also: https://codeberg.org/trougnouf/cfait
connexion
I'm imagining you saying "connex-yun", and it reminds me of Stewie saying "cool-hhhwip".
Forgejo and self hosted action workers.
Woodpecker CI
Git lab CI is my goto for git repo based things (unit tests, integration tests, etc). Fleet through Rancher for real deployments (manages and maintains state because kubernetes). Tekton is my in between catchall.
I'm using gitea which has CI compatible to GitHub actions with my own runner. It's pretty straightforward to set up and didn't give me any headaches yet. It's a very small instance just for my ownaybe dozen projects though.
This is what I was using till I switched to forgejo and never got around to setting up one of their runners.
I run their act binary on one of my servers. Can't remember much of the setup, so I can't be too bad. I did have to change the used images though, but I guess that comes with maintenance of you own runner anyway.
Magnetic needle. Steady hand.
Not butterflies?
We use Azure Devops at my current gig. It works pretty well for our setup. I've used GHA before; it definitely didn't "spark joy". I ~~wasted~~spent way too many hours in the "update yaml file, commit, push, wait 5 minutes for it to fail again" ~~spiral of despair~~feedback loop.
Nice thing with ADO is its release dashboard -- you get a really nice summary of recent builds and where they went:
$project - dev - test - prod
I didn't see anything similar for GHA.
Gitlab CI/CD pipelines are my go-to tool. At work we self host an instance, for personal projects I use gitlab.com.
Watching this thread because CI/CD is something that I'd like to get into.
Are you a programmer?
I..uh....I pretend I am from time to time.
I self-host https://woodpecker-ci.org/ and I love it. It was easy to set up, and I never have to worry about CI/CD minutes.
Jenkins is good enough to be widely used enough to be hated enough to be downvoted.
The sign of a mature product IMO.
You could do worse than Jenkins
Been using Jenkins since before it was called Jenkins. It's been in use at every corpo I've worked for. It can practically do anything. Especially coupled with Docker.
Hudson? Man, that's a blast from the past.
I was scrolling, looking for a Jenkins somewhere, to finally find that post with down votes.
Every company I go, it's a different CICD, and they all make me wish to use Jenkins instead.
Jenkins is better than many but IMO Gitlab pipelines are top tier.
I’m not entirely sure why all the hate : Jenkins can do the most things the must ways. And yes, it’s so much nicer defining a pipeline with a fully functional language than an assortment of yaml files
Actually that was my response when my company wanted to start using Gitlab ci. It only has one way of doing things so you can probably get a faster start if you had no ci, were a small company, and had simple builds. However we’re over 4,000 builds in many languages from 12 year old monoliths to modern micro services and containers….. and way too much godawful JavaScript. Do you want the quick and simple tool great for a small startup or the all powerful kitchen sink of tools?
I do devops at work and my experience is that really any CI/CD system works, they all have enough features to do what you want. They all fundamentally just run scripts on boxes. Therefore, I say pick the easiest one, likely the one that is built into whatever Git system you are using.
Try to keep your pipelines simple-ish when you can, they almost never need to be that complicated. 95% of the time it's just running a command or two. If a pipeline needs to do something complex, I'd recommend writing that script into the Git repo and calling it, rather than having a CI job that is 100 lines long.
I'm currently looking into Concourse.
It does have steeper-than-average learning curve, but I really like that it has well-defined fundamentals (resources, jobs, tasks) and isolation with OCI containers. Before I adopt it fully, I want it to run my nix flake dev shell.
GitHub Actions mostly.
The rest is usually plumbing and code to support it. The actions are just the automated execution environment.
So many these days. Actions are probably one of the best, but there are still plenty of others out there.
If I were to pick one, it would probably be dagger. Or really anything but Jenkins.
Gitea Actions, as well.
fwiw, you can self host a GitHub actions runner
Don't they want to monetize those as well?
yes, according to this morning’s email