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.

I haven’t used forgejo but I imagine you’d set a runner to trigger on merge or push to your main branch that does any build steps (if needed) and copies the artifact to the directory you’re serving

My SO outputs static HTML, moves it to a folder in Nextcloud, and a process syncs it to the server. I don’t version her content, just the app code, but the sync target is backed up. I use nginx to serve the HTML at /whatever-folder/some-file-name and inject other client content.

Git push to Forgejo -> automated build, package, and deploy pipeline -> use secured credentials to upload via scp or ssh or sftp

Alternatives to copy-upload or upload-package and then extract via command is stuff like rsync (reduce redundant, unchanged file uploads) or a simple receiver service (for example REST endpoint that receives a package with an identifier key and secret key, that it extracts to a configured target folder).

What solutions are simplest or easiest depend on the target environment, and how much of it you control. If you host the website on Forgejo itself it’s as simple as pushing the static files into the corresponding pages branch.