Sandboxing each workflow run in a self hosted runner

[RossComputerGuy]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

ARC (Actions Runner Controller)

Discussion Details

I'm needing to have a self-runner and I have security and practicality concerns. One of which is if we run an action, like the Nix deploy action, that touches the host system in some way. I've managed to sandbox the systemd service itself for the runner listener so the systemd service has an ephemeral rootfs. Now, I am wondering if multiple runs occur that do something like install Nix, how that would impact the other runs. I am doubting the Nix install action to handle installing Nix on something which already has Nix installed.

For security reasons, I also have concerns about multiple runs happening and other runs seeing each other. For this reason, I need to be able to sandbox each individual run and not just the runner listener. I did find pre/post hooks but that doesn't fit my model. I need to be able to sandbox an entire workflow run from the start. Is there any planned way to do this properly?

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[Talha-Dogan]

To achieve proper sandboxing on self-hosted runners and prevent side effects between workflow runs, the best approach is to treat your runners as ephemeral (disposable).

Here are the two most common strategies to achieve this isolation:

1. The Ephemeral Flag (For VM/Bare Metal): When you configure your runner, use the --ephemeral flag:

Bash
./config.sh --url <repo_url> --token --ephemeral
This tells the runner to accept only one job. Once the job finishes, the runner automatically removes itself. You simply need to wrap your runner startup command in a loop (or use a systemd service) to immediately register and start a fresh runner agent after the previous one exits. This ensures every job starts on a clean slate.

2. Actions Runner Controller (ARC) - For Kubernetes: If you have access to a Kubernetes cluster, ARC is the gold standard. It dynamically spins up a fresh Pod for every single workflow run and destroys it immediately after execution. This provides excellent isolation since every run gets its own pristine container environment.

If you are strictly on a single persistent server, using the jobs.<job_id>.container property in your workflow YAML can help isolate the build environment (dependencies), but using ephemeral runners is the only way to guarantee the entire workspace and runner state is wiped clean every time.

[RossComputerGuy]

I cannot run ARC since it doesn't fit the declarative & reproducible nature of my workflow & infra. Ephemeral is okay, we figured that we can do a lot of systemd sandboxing and get a cromulent CI with --ephemeral. It would be nice if ARC could run without Kubernetes and could just communicate with systemd to spawn ephemeral instances as needed rather than having to declare like 5 services.

[Talha-Dogan]

Glad to hear the ephemeral approach combined with systemd sandboxing is working out (a "cromulent" solution indeed!).

Regarding the friction of declaring multiple services manually: Have you looked into systemd template units (e.g., actions-runner@.service)?

This allows you to define the runner service logic once and then instantiate as many as you need (e.g., systemctl start actions-runner@{1..5}) without creating separate service files for each. It fits the declarative nature nicely while keeping the config minimal.