NL EN

IT management
Microsoft 365
Network & security
Who for
Hosting & cloud
Magento
Websites & online shops
Managed applications

All services at a glance

Forgejo Actions: the runner is the work, not the workflow.

Your team can write a workflow. Making sure a runner is ready to run it safely, we handle.

Drawing of a git history: a branch is tested and merged back, the latest version is live.mainTestedRolled out

Short answer

Forgejo Actions is the built-in CI/CD system in Forgejo: with every change to the code, builds, tests or a deployment start automatically. The jobs are run by a runner, a separate program on a server. Jevana hosts the runners on its own hardware and keeps them up. Workflows have the same form as in GitHub Actions, so existing files are largely reusable.

From commit to deployment

  1. 01

    Push

    Someone puts a change in the repository or opens a pull request.

  2. 02

    Workflow

    Forgejo reads the workflow file in the repository and puts the jobs in the queue.

  3. 03

    Runner

    A runner picks up the job and runs each step in a clean container.

  4. 04

    Result

    Green or red at the commit, with the log alongside. On green the deployment can follow.

What we do for the runners

Capacity

  • How many jobs at once, matched to your team
  • More runners added when the queue gets too long
  • Kept apart from the server Forgejo itself runs on

Safety

  • Every job in its own container, which then disappears
  • Secrets available only to the workflows that need them
  • No runner that can reach systems it has no business with

Maintenance

  • The runner software updated along with Forgejo
  • Old container images and caches cleared
  • An alert when a runner stops responding

What is different from GitHub

The shape of a workflow is the same: a YAML file with jobs and steps. Many actions from the GitHub ecosystem work unchanged. Forgejo does not promise full equivalence, and the odd action that leans deeply on GitHub itself has to be replaced.

The biggest difference is where it runs. At GitHub your builds run on Microsoft's machines. Here they run on runners in the Netherlands that only your organisation uses. For code that has to be deployed to a server of your own, that is also practical: the runner is already on the right side of the firewall.

Questions

What is a runner in Forgejo?

A runner is the program that actually carries out the jobs from a workflow. Forgejo itself keeps the code and decides what has to happen; the runner fetches those jobs, starts a container and runs the build or the tests in it. Runners are separate from the Forgejo server and you can have several, for example a separate one for heavy builds.

Do the builds run on Jevana's hardware?

Yes. The runners sit on our own servers in the Netherlands, apart from the Forgejo installation. Source code and build results do not leave our environment unless a step in your workflow sends them somewhere. If a build must reach a system in your own network, we place a runner there, which only has to call out.

Will our GitHub Actions workflows work in Forgejo?

Largely. Forgejo Actions uses the same layout of workflow files and can use many existing actions directly. Small changes are often needed, such as the folder the workflows sit in and references to functions only GitHub knows. In a switch we go through the workflows with your team and move them across one by one.

How do you handle secrets in a workflow?

Passwords, keys and tokens are stored as secrets in Forgejo, per repository or per organisation, and not in the code. A workflow gets them only at the moment of running, and they are masked in the log. We advise using a separate key for each purpose with as few rights as possible, so a leaked key can do little.

Tell us what you run.

An introduction costs nothing. You talk straight away to one of the two people who will actually do the work.