Senior DevOps Engineer, CI/CD Platform (Developer Experience)
Senior DevOps engineer owning Factorial's CI/CD platform end to end: a self-hosted Kubernetes fleet on bare metal running GitHub Actions runners for a large Rails monorepo. Day to day involves capacity planning, cluster upgrades, build caching, observability, and incident response using Kubernetes, Terraform, Flux/Argo CD, and scripting in Bash, Python, or Go.
- Compensation
- Not disclosed
- Location
- Barcelona, Spain
- Work setup
- Not specified
- Seniority
- Senior
- Employment
- Not specified
- Experience
- 5+ years
- Category
- Devops
- Posted
Skills
Must have
- 5+ years running production infrastructure, with Kubernetes at the centre
- Real depth in Kubernetes: scheduling, requests and limits, evictions, node pressure, DaemonSets, controllers and operators
- Strong Linux and container fundamentals: containerd or Docker internals, cgroups, namespaces, storage drivers, networking
- Terraform and infrastructure as code, with module design and state hygiene
- CI/CD at the platform level: shared workflows, reusable templates, runner architecture, build caching
- Comfortable with GitHub Actions, including self-hosted runners
- Scripting to automate: Bash plus at least one of Python or Go
- Observability as a working method: metrics, logs, traces, dashboards and alerts with OpenTelemetry and Prometheus style tooling
- Operational maturity: on-call, incident command, postmortems, chasing causes
- Capacity and cost awareness: sizing a fleet and explaining the bill
- Clear written English and documentation habits
Nice to have
- Large Ruby on Rails test suites and parallelising them
- Operating MySQL, Redis or ClickHouse yourself
- Bare metal: provisioning, hardware failure handling
- Overlay and WireGuard style mesh networking, VLANs, and Kubernetes CNIs such as Cilium
- Building internal developer tooling, portals or platform APIs
- Supply chain and build security: runner isolation, secret scoping, image provenance
- Working across more than one cloud (AWS, Azure, Cloudflare)
- Contributions to open source infrastructure projects
Full description
Hey there, Kubernetes people!
Every engineer here waits on CI several times a day. We want someone who finds that wait personally annoying.
Why this role exists?
Hundreds of developers push to a large Ruby on Rails monorepo, and every push lands on a runner fleet that the Developer Experience team builds, runs and keeps fast.
That fleet is self-hosted Kubernetes on bare metal in European datacentres, in the low hundreds of machines, running eternal GitHub Actions runners that peak above a thousand concurrent pods. We own all of it: the hardware, the clusters, the runner images, the caches and the delivery pipelines on top. We add nodes by hand rather than letting an autoscaler do it, so capacity planning is genuinely part of the job.
The leverage is unusual. Shave a minute off the average build and every engineer in the company gets that minute back, several times a day.
The mission
- Own the CI and CD Kubernetes clusters end to end: capacity, reliability, upgrades, security and cost.
- Run the self-hosted GitHub Actions platform at scale with Actions Runner Controller. Runner scale sets, ephemer pods, docker-in-docker, and the runner images themselves.
- Keep the data services our tests depend on fast and healthy. MySQL, Redis and ClickHouse come up per job, alongside Rails application containers.
- Design and tune the caching that makes builds quick: node-local overlay, image and artifact caches we build ourselves, plus pull-through registry mirrors.
- Bring queue wait and build duration down, with measurement behind it. Instrument the platform, set targets, and show the improvement.
- Manage it all as code. Terraform planned and applied from pull requests, GitOps delivery with Flux and Argo CD, Kustomize and Helm for manifests.
- Provision and operate bare metal. Linux, networking across datacentre segments, and troubleshooting that sometimes ends up at the disk or the kernel.
- Lead incident response for the platform, run blameless postmortems, and turn each one into an alert, a guardrail or a runbook.
- Treat the platform as a product whose users are engineers. Talk to them, watch where they get stuck, and build paths that make the right thing easy.
Your day to day
- Rightsizing runner tiers against a week of CPU and memory data, then opening the pull request that changes them.
- Tracking a flaky job from a red check down to the container runtime, the kernel, or a clock that drifted.
- Adding machines to the fleet: install, enrol, network, verify, document.
- Cutting p95 queue wait by working out which stage actually blocks.
- Upgrading a cluster or a controller without anyone noticing.
- Pairing with a product engineer on a workflow that has been slow for a reason nobody has looked at yet.