Yes and no. Depends on tenancy requirements. I know with docker and other common Linux container strategies you would want to keep each tenant on their own VM. A container isn’t safe enough.

So if this is your org’s only action. Then you’re probably spinning up a VM. If you have other options. You’re probably not adding any overhead.

(Edit: grammar)

Ya, but I doubt that is the case with actions, because I don't think you really have full access to everything. You provide a yaml file and their software runs that yaml which could easily exclude any dangerous commands. Plus, github offers a hosted runner service where you pay for a dedicated VM to run your actions in. So that makes it seem like actions are probably run together on larger VMs by default.

It is definitely the case with Actions.

> I don't think you really have full access to everything

You do.

> their software runs that yaml which could easily exclude any dangerous commands

Categorizing dangerous commands is impossible to do accurately by just looking at a yaml file.

> Plus, github offers a hosted runner service where you pay for a dedicated VM to run your actions in. So that makes it seem like actions are probably run together on larger VMs by default.

I'm not sure what this means. The paid hosted runners are not any different from the free hosted runners, but free runners can only be used on public repos.

You can also use more secure containarization technologies than native docker, like gVisor, to achieve both lightness and isolation.

I'm pretty sure GitHub actions do use a whole (though probably lightweight) VM. And I think AWS lamdas do as well, or at least used to.

Well, if lambdas are using VMs and have sub-second launch times, I don't think using a lot of github actions would cause much overhead.

This is a common misconception about Lambda and Functions. They don't always give you a fresh container/VM, but Actions does.

https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

https://docs.microsoft.com/en-us/azure/azure-functions/funct...

They support Linux, Windows, and macOS. Surely that cannot be covered just with containers. On Linux, they allow workflows with a large number of different containers involved and I don't think GH would be happy to debug all Docker-inside-Docker problems. So, I guess there is a control algorithm that keeps up to N (100?) VMs spinned up in a free VM pool with the KPI of VM allocation from the pool to be under X s (5?).

Edit: from https://docs.github.com/en/free-pro-team@latest/actions/crea... "Actions can run directly on a machine or in a Docker container".