Can a self-hosted GitHub Actions Runner deploy an application on the same machine that is hosting the GitHub Runner?

I am currently trying to configure a GitHub Repository with GitHub Actions enabled, using a self-hosted GitHub Actions Runner running on a Ubuntu VM.

I would like to deploy my application to the same VM which is running the GitHub Runner.

Is this possible? Is this advisable?

Is this possible?

Yes, it is possible.

Is this advisable?

Not at all advisable. GitHub actions will potentially execute arbitrary code on the runner that is part of a potential pull request.

In most cases, runners are configured with administrative privileges in order to be able to install packages a workflow might need. This is, of course, not a hard requirement. You can have workflows run as a normal user with no sudo rights, but that would limit its usefulness.

You can also require approval before running a workflow, but once you do run it, it still executes the code in that PR on the same machine you application is running on.

If the goal is to use github actions to deploy your app on a server, you might want to have a look at github deployments.

That being said, there are options you can use to:

• Use the same machine to run actions in a safe(er) way
• Limit potential resource exhaustion from a long running, CPU/Memory/IO intensive workflow run
• Have repeatable runs on a clean environment each time

Use ephemeral runners

All of the points mentioned above can be addressed by using ephemeral runners inside a container or a virtual machine. Doing so gives you some segregation in terms of security and resource boundaries.

Ephemeral runners should be used in most cases. These runners only run one job, after which they're removed from GitHub and a new runner must be added.

This ensures that you get a clean environment for your workflows each time and that they are isolated from any other system, limiting the potential security impact of running arbitrary code.

However, ephemeral runners can be tricky to manage. They require the use of some sort of auto-scaler that listens for workflow events from GitHub and reacts by spinning up an ephemeral runner, and taring it down when the job is done.

Fortunately, there are several options in this regard:

• ARC - Actions Runner Controller. This is a Kubernetes controller that spins up runners in a k8s cluster and makes those runners available to your repo/org/enterprise. This is now an official GitHub project, maintained by GitHub and the community and is what GitHub recommends for most use cases. With some configuration, I suspect you could easily run virtual machines as well via Kubevirt, if a container runtime is not suitable for your use case.
• terraform-aws-github-runner - There are several terraform providers that can act as auto-scallers on various infrastructures. On such example is the AWS one.
• lxdrunner - LXDRunner is an autoscaller that spins up runners on LXD, but it seems to not have been updated in a while.
• GARM - GitHun Actions Runner Manager. Full disclosure, I am one of the authors of this auto-scaler. GARM was created to allow users to use any system you can write a provider for, as a destination for ephemeral runners. It currently has support for a range of cloud providers (AWS, Azure, OpenStack, Equinix, k8s, lxd, incus). LXD and Incus, are probably an easy fit for your needs, considering they can easily spin up containers on physical or virtual machines, for the purpose of running an ephemeral runner, without requiring you to set up a k8s cluster.

Whichever option you end up using, it should be much safer than running a persistent runner, especially on the same system you host your app on.