Update blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md

blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md

@@ -24,7 +24,7 @@ When I made the [Git-Repo-Updater docker container stack](https://git.bunny-lab.
 In addition to the above, I had security concerns with the method of how I was interacting with the underlying container storage folders.  I was running the containers as `privileged: true`, which was not safe nor secure if the container itself was breached (not likely, but you never know).  I also didn't like the idea that was using my own CI/CD pipeline for something that I was certain existed elsewhere with much more hardening built-in, and I felt that I was intellectually "*falling-behind*" if I didn't figure out how to use them and migrate away from my Git-Repo-Updater project.
 
 ## Introduction to Gitea Runners
-When I finally got around to figuring out the general architecture of how [Gitea Act "Runners"](https://docs.gitea.com/usage/actions/act-runner) operate, it seemed so much more intuitive than the method I was using in Git-Repo-Updater.  The runners can run as a standalone packages, docker containers, or can exist in other forms.  The general idea of how the Runners operate is as-follows:
+When I finally got around to figuring out the general architecture of how [Gitea Act "Runners"](https://docs.gitea.com/usage/actions/act-runner) operate, it seemed so much more intuitive than the method I was using in Git-Repo-Updater.  The runners can run as a standalone packages, docker containers, or can exist in other forms.  The general idea of how the Runners operate (*within my specific GitOps code-to-server use-case*) is as-follows:
 
 - You spin up a Gitea runner docker container on a server that can access the server files that need to be overwritten/modified
 - The Gitea runner container registers itself to the Gitea server using a registration token generated by a specific Gitea repository