this post was submitted on 10 Apr 2026
11 points (92.3% liked)

Programming

26464 readers
140 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

I have a small website with the git code hosted on my own Forgejo instance. I want to give my wife easy access to the code to update texts. I think using Forgejo is an easy enough interface for her to do that.

But how do I ensure that every commit is reflected on the website in a timely manner? I think webhooks are the usual answer. But do I add them to the website itself or do I run a separate service for that? If the latter, can you recommend one?

Or is there a better way? Seems kind of roundabout since the website and Forgejo run on the same hardware.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] cecilkorik@lemmy.ca 6 points 1 day ago* (last edited 1 day ago) (1 children)

This is typically called "continuous deployment" or "CD", a close neighbor to "continuous integration" or "CI", and you will find that this is a very deep rabbit hole.

It's intentionally roundabout, as it has security implications when you make that process too direct and automated. You don't really want to just give your forgejo repository root commandline access to the machine it's running on (and it doesn't want you to do that either). Good software like Forgejo doesn't trust itself nevermind its users, and sets things like this up in a way that it has to pass through various gates in the process that control what it's doing a little more carefully and explicitly. At the end of the day of course it's always potentially dangerous to be running automatic code deployments like this, but adding the extra hoops to jump through is one way of putting extra barriers against someone trying to profoundly violate your machine. There's a swiss cheese model of security going on here, where yes, there are holes in each of the slices, but unless all the holes of all the different slices line up exactly like they're supposed to, an attacker can't get through.

With that said, there are tons of CD options out there and it's totally possible to roll your own especially for a simple use-case like this, but forgejo runners are absolutely the easiest and most native way of handling this, they follow the github actions configuration almost perfectly (for better or worse, it's become the standard now, god save us all). The initial setup is a bit front-loaded, but once you've got your runner connected, you're laughing. Smooth as silk. Don't worry too much about the "risks" side of the setup, if this is truly a single-user Forgejo where you're not letting other people create repos and you're not blindly copying other people's repos or accepting dangerous PRs from people, the risks are minimal, you're the only one running github actions on it, you can give it access to the same machine Forgejo is on without too much worry. You're poking a few holes in the swiss-cheese security model but, us self-hosters have gotta do what we've gotta do with our limited resources.

Once the runner's connected, just pretend you're dealing with github actions from that point forward, set the "runs-on" attribute to point at whatever you tagged your runner with, and either use native github actions directly from github, or they're also mirrored on forgejo.org (for example https://code.forgejo.org/actions/setup-go) or you can mirror them yourself, or you can just avoid using pre-packaged actions at all and just script your heart out and run straight bash commands. It'll run and do whatever you tell it to. It'll pull down the latest copy of the repo and deploy it wherever you want, however you want, you can have it run deployment scripts you've saved inside the repo itself, whatever you need to do to get it deployed.

[โ€“] bjoern_tantau@swg-empire.de 1 points 17 hours ago

Thanks, setting up the runner and actions works great! Permissions are a bit wonky but not unsolvable.