Secure GitHub Actions | Blacksmith
Announcing our Series C led by Sequoia at a $1B valuation.
Last updated: August 8, 2025
TL;DR
Reading
Yeah, we're compliant
For the box checkers — we are SOC 2 Type 2, GDPR compliant, and our hardware runs in ISO 27001 data centers. Plus, we answer security questionnaires.
It all starts with our GitHub integration
Once integrated, GitHub forwards job requests to us. Our integration has no ability to directly access organization or repository level secrets. On top of that, login is available exclusively through GitHub SSO.
Permission
| Permission | Reason |
|---|---|
| Read access to members and metadata | To list users in our settings page |
| Read and write access to actions, code, pull requests, and workflows | For our migration wizard to make a pull request with all the required code changes |
| Read and write access to organization self-hosted runners | To mint just-in-time (JIT) tokens and enable our managed runners to run your jobs |
So we can later orchestrate incoming GitHub Actions jobs
Our control plane orchestrates the execution of all incoming GitHub Actions jobs. For each job, we mint a just-in-time (JIT) token — scoped specifically to that job and configured to expire after one hour — to adopt and execute that single job in one of our microVMs.
Add microVM isolation
Our jobs never share kernels. We run jobs in a secure, isolated Firecracker microVM on our own bare-metal hardware, protected by a private VPN. After a job completes, the microVM is destroyed, along with any of its state.
Then secure all the cache artifacts!
We securely cache artifacts on MinIO and Ceph storage clusters. These clusters live on the same fleet of bare-metal machines as your jobs, so they inherit the exact same security controls. As a result, access to data is always authenticated and audited, while the data itself remains encrypted and isolated by organization.
And yes, we're aggressively pentested
Just to sanity check ourselves, we pay hackers to pen test our system every quarter. So — what do you think? Can you trust us?
Here's how we did it
To have the information required to make a sound decision, we must begin with a single request and see what happens after you run git push to trigger a CI run. Following its journey, we'll see the interfaces it encounters, the boundaries it crosses, and the extensive measures we take to keep your GitHub secrets, code, and cache artifacts safe — across three axes: CPU, Network, and Disk.
It all starts with our GitHub integration
At the time of writing this, over 10000 organizations trust us with their CI, so our security needs to be hardcore — from job initialization to completion — for every request. But before you can even send us a single request, you must first sign up for Blacksmith.
Next, you must set up our GitHub integration for your GitHub organization. Immediately, it’s important for us to note that our GitHub integration has no ability to directly access organization or repository level secrets.
Once you’ve set up our integration, GitHub will begin forwarding your job requests to Blacksmith’s control plane via webhooks.
Directing traffic from Blacksmith’s control plane
This is our central command center — the brain that orchestrates all incoming GitHub Actions jobs. It’s built on AWS, with metadata stored in a Postgres database via Supabase. Only the control plane can access our Postgres database, and yes, everything is encrypted at rest.
One of the great things about hosting our control plane on AWS is that it allows us to easily setup AWS Identity and Access Management (IAM) policies — all following the Principle of Least Privilege (PoLP).
Only after your request has jumped all of our checkpoints do we construct your job’s payload. Part of this payload is a freshly minted JIT token, scoped to a single job and set to expire after 1 hour.
Into the depths of Blacksmith’s dataplane
We now descend into the lowest layer of Blacksmith: our dataplane. This is where your GitHub Actions jobs actually run, on our hardware — a fleet of 32 vCPU boxes.
The path into our dataplane begins with a strong first line of defense: our network. Our network is secured with Tailscale, a VPN service that utilizes WireGuard.
Once in, each physical machine runs an agent that authenticates to our AWS-hosted Redis queue using Doppler-injected credentials and pulls job payloads from it.
When booted up, each microVM gets a copy-on-write clone of the root file system from GitHub’s official GitHub Actions runner images.
Once the official GitHub Actions runner binary is up and running, we rely exclusively on the JIT token to adopt and execute a single job. While your job is running, your code and secrets are safe from the outside world.
If all this isn’t enough, after your job completes, the VM is destroyed, ensuring that modifications don’t persist beyond the life of the job.
Cache is most definitely king
For jobs that opt into caching, your artifacts are stored on either our self-hosted MinIO or Ceph clusters — depending on what you’re caching. These clusters live on the same fleet of bare metal machines that host the agents, so they inherit the exact same security controls.
When a job payload gets created, the control plane includes more than just a JIT token. It also mints a separate cache token, scoped to your organizations, and embeds it in the job payload.
With access granted and metadata in hand, the agent performs the final step: an authenticated query to either MinIO or Ceph.
But where your data ends up matters just as much as how it gets there. MinIO artifacts are namespaced by organization and repository, ensuring isolation between tenants.
Yeah, we're compliant and pentested
We are SOC 2 Type 2, GPDR compliant and are in the process of becoming HIPAA compliant in the coming weeks. If you'd like, you can request access to the reports via our trust center. And rest assured that, just to sanity check ourselves, we pay hackers to pen test our system every quarter. So — what do you think? Can you trust us?