GitHub Actions Runs on
The github actions runs on setting tells a workflow job which machine to use. You write a runner label in your workflow file to pick the host. Most engineering teams start by picking a standard cloud machine for every build. That default setup works well for simple code checks and unit tests. Soon, teams need to deploy code to private servers or internal databases. They often give the runner broad cloud roles or static database keys. If a bad script runs in that job, it can use those wide permis
GitHub Actions Security + Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The github actions runs on setting tells a workflow job which machine to use. You write a runner label in your workflow file to pick the host. Most engineering teams start by picking a standard cloud machine for every build. That default setup works well for simple code checks and unit tests. Soon, teams need to deploy code to private servers or internal databases. They often give the runner broad cloud roles or static database keys. If a bad script runs in that job, it can use those wide permissions.
How the github actions runs on setting routes your jobs
Every workflow file contains one or more jobs that run your automation steps. Each job needs a compute host, which the platform calls a runner. The github actions runs on rule matches your job with an active runner. When a developer pushes code, the platform reads the labels in this setting. It then places the job in a queue until a matching machine is free.
You can choose between two main types of machines for your jobs. First, you can use cloud machines that the platform manages for you. You pick an operating system label like Linux, Windows, or macOS. The platform boots a fresh virtual machine for the job and deletes it after. Second, you can run your own machines inside your private network. You install the runner agent on your server and give it custom labels. When a job asks for those labels, your private server picks up the work.
Teams also use matrix builds to test code across many systems at once. A matrix lets you pass a list of machine labels into the job. The platform then starts one job for each label in your list. You can also group your private runners into separate pools for each team. This prevents a test job from landing on a machine meant for production releases.
Choosing between cloud runners and private runners
Cloud runners give you a clean machine for every single workflow run. You do not have to patch servers or clean up leftover files. Still, cloud runners sit outside your private cloud network by default. To reach a private database, teams often open firewall ports or store static keys. Anyone who can edit the workflow file might trigger a job that uses those keys.
Private runners sit inside your network, so they can reach internal systems directly. This setup avoids opening public firewall ports to your data stores. Yet private runners bring their own security risks if you are not careful. Files and keys from one job can stay on the disk for the next job. Also, a machine role attached to that server applies to every job it runs. If a pull request runs untrusted code on that server, it gets full network reach.
GitHub Actions Security + Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What runner labels solve and the gap they leave open
Runner labels and groups do a great job of routing work to the right host. They help you separate public test builds from internal release jobs. You can lock down which code repos are allowed to use a specific runner group. You can also require a human to approve a job before it starts running.
Still, runner settings only decide where a job runs and which role logs in. Once the job starts, the runner has full use of its assigned keys or roles. Native runner rules cannot inspect the actual database queries or shell commands in flight. A flawed deploy script can drop a table or read bulk customer rows. Even if a job only needs to run one safe command, the runner holds full permissions. And if a job reads a table, raw emails or card numbers can spill into build logs.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can one workflow job use multiple runner labels?
Yes, you can pass a list of labels to a single job. The job will only run on a machine that has every label in your list. This helps you pick a private server with a specific operating system and hardware size.
What happens if no runner matches my job label?
The job stays in a waiting state inside the platform queue. If no matching machine comes online within the platform time limit, the job fails. You should check that your runner agent is active and has the exact same label spelling.
Are self-hosted runners safer than cloud runners for production jobs?
Self-hosted runners keep traffic inside your private network, which avoids public firewall holes. Still, they keep state between jobs unless you wipe them after every single run. You must still limit what commands and queries the runner can execute once connected.