At the time of writing this, over 600 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. The first of your concerns may, or should, be regarding your login credentials. The good news is you don’t have to worry about that. We exclusively support GitHub SSO, and authentication is fully delegated to GitHub’s OAuth flow. So, in this specific scenario, if you already trust GitHub, you have a strong basis for trusting us.

Next, you must set up our GitHub integration for your GitHub organization. Naturally, your second concern is likely to be regarding the permissions granted to our GitHub integration. Immediately, it’s important for us to note that our GitHub integration has no ability to directly access organization or repository level secrets. In fact, GitHub doesn’t even allow us to request direct access! Moreover, we not only request the minimum necessary permissions to make your experience with CI much, much easier, but we also want to be transparent about exactly why we request each permission. So below is the complete list of permissions our GitHub integration requests, alongside the reasons for requesting them:

We’ve made it across the GitHub valley and landed in the heart of Blacksmith: the 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). All resource access is locked down, and all traffic is encrypted during transit through the enforcement of TLS. Moreover, before a request can even get a foot in the door, it must pass several security checkpoints: authenticated endpoints, rate limiting, input validation, and protection against SQL injection.

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. The payload is then handed off to our AWS-hosted Redis queue, waiting for a runner in our dataplane to take over.

We now descend into the lowest layer of Blacksmith: our dataplane. If the control plane is the brain, the dataplane is the muscle. This is where your GitHub Actions jobs actually run, on our hardware. More specifically, a fleet of 32 vCPU boxes, procured from data center providers in the US and EU. But this layer is not only filled with bare metal machines, but with Firecracker microVMs, GitHub Actions Runners, MinIO blob stores, Ceph storage clusters, Tailscale VPNs, and so much more. It is here, in the heat and pressure of the dataplane, that we isolate the execution of each GitHub Action job across three axes: CPU, Network, and Disk.

The path into our dataplane is intentionally a difficult one, and it begins with a strong first line of defense: our network. Our network is secured with Tailscale, a VPN service that utilizes WireGuard, an open-source framework for encrypted virtual private networks. With Tailscale, our fleet of bare metal machines lives behind a tight-knit, private network. Every one of them is part of a Tailscale Tailnet, meaning SSH access is entirely locked down to the outside world. No public ports, no guessable IPs, no surprises. What’s more, communication between services in the dataplane flows through a Tailscale VPN. But it doesn’t stop there — all deployments to our machines happen exclusively over Tailscale SSH, ensuring encrypted, identity-based access between trusted devices only.

Once in, each physical machine that is a part of our private network runs an agent that, among other responsibilities, is tasked with authenticating to our AWS-hosted Redis queue using Doppler-injected credentials and pulling job payloads from it. Once your job request is picked up by an agent, it runs your job in an ephemeral microVM managed by Firecracker — the same microVM technology used by AWS to run millions of untrusted workloads for AWS Lambda and Fargate. These microVMs leverage Kernel-based Virtual Machine (KVM) virtualization to run their own guest kernel and user space, isolated from both the host and other microVMs. This strong isolation lets us safely run multiple customer workloads on the same machine — unlike Docker, where containers share the host kernel and rely on a much thinner security boundary. Firecracker also allows us to use cgroups to enforce CPU and memory limits on each microVM to ensure fairness across jobs, and prevent noisy neighbor problems.

When booted up, each microVM gets a copy-on-write clone of the root file system from GitHub’s official GitHub Actions runner images, which we routinely update to acquire the latest dependency versions as GitHub releases them upstream. We also hydrate the microVM with GitHub’s official GitHub Actions runner binary, which contains the logic responsible for coordinating with GitHub’s control plane to adopt a job. The same runner binary GitHub provides automatically obfuscates any secrets in command-line output and logs.

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 since each microVM operates within its own network namespace.

If all this isn’t enough, you’ll be happy to know that after your job completes, the VM is destroyed, along with any of its state, including its filesystem, ensuring that modifications — benign or malicious — don’t persist beyond the life of the job. This, of course, does not include the caching artifacts that you can opt in to store on our disks so they can be shared across job runs — speeding up your Docker builds and more generally your GitHub Actions workflows.

For those not using our caching features (bad choice!), our journey is nearing its end, and you may skip the next section and go straight to the conclusion. For all others (good choice!), we have a few more things to cover regarding how we secure access to your cached artifacts across job runs.

For jobs that opt into caching (and really, they should), your artifacts are stored on either our self-hosted MinIO or Ceph clusters — depending on what you’re caching. Simple dependencies go to MinIO. Docker layers and other hefty artifacts land in Ceph. These clusters live on the same fleet of bare metal machines that host the agents, so they inherit the exact same security controls. But storing cache artifacts in a durable manner is only half the battle. Getting it safely in and out is where things get interesting.

It starts with indirect access. All storage requests originating from a microVM — the isolate environments your jobs run in — never talk directly to storage. Instead, all storage traffic is proxied through the agent running on the host machine. This proxying step isn’t just fun; it’s a deliberate control point that ensures all access to storage is authenticated, authorized, and auditable.

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. The host agent fetches this payload, associates the cache token with the microVM it’s about to launch, and injects that token directly into the microVM’s memory at creation time.

So, when your job attempts to access a cache artifact — whether to read or write — the microVM sends a request to the host agent, asking it to make an authenticated request to the control plane using the cache token. This request is signed with the cache token, allowing the agent to validate it against the in-memory metadata it knows about the microVM. This validation step is what helps prevent man-in-the-middle (MitM) attacks that could attempt to access cache artifacts outside the intended organization or repository scope.

If it all checks out, the agent makes the authenticated request to the control plane, acting on the microVM’s behalf. The control plane logs this action in its database for auditing, validates usage against throttling policies, and then replies with metadata about the artifacts: its name, its location, and nothing more than what the token was scoped to access.

With access granted and metadata in hand, the agent performs the final step: an authenticated query to either MinIO or Ceph. Authentication happens via credentials provided by Doppler — injected directly into the agent as environment variables. And, like all internal communication in our dataplane, this request flows over our Tailscale VPN.

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. These artifacts are encrypted-at-rest using KES with AWS KMS keys. Ceph goes further: each block device follows the same namespacing pattern, but benefits from Cephx authentication and smart data placement via CRUSH maps to ensure resilience against node failure.