Infrastructure & DevOps
Want to propose a change, disagree with a placement, or add an interesting new technology? Please reach out to @Damian Szafranek. This Tech Radar is a living document - we keep it useful by updating it together as our projects, tools, and experiences evolve.
Scope
How our software gets built, deployed and operated: containers and orchestration, continuous integration and delivery, infrastructure as code, cloud platforms, identity we run ourselves, reverse proxying and TLS, and the deployment practices around all of it. What a running system is doing belongs in Observability & Monitoring.
Overview
ADOPT
Proven technologies we have high confidence in; our default choices.
Technologies Breakdown
Docker ADOPT
Docker is our company-wide standard for containerizing applications. It provides a consistent, portable, and isolated environment, which is fundamental to our deployment strategy on AWS.
AWS (Amazon Web Services) ADOPT
AWS is our primary and strategic cloud provider. Our deep in-house expertise, certified engineers, and existing infrastructure make it the default platform for hosting all our applications and services.
Jenkins ADOPT
Jenkins is our established and primary tool for Continuous Integration and Continuous Delivery (CI/CD). It is the standard for automating builds, tests, and deployments for our core projects.
Terraform ADOPT
Our default Infrastructure as Code tool for defining and managing cloud resources in a repeatable, version-controlled way.
Terraform helps us standardize environments, reduce “hand-built” drift, and reliably reproduce infra across stages and projects. Especially valuable when infrastructure needs to be created, replicated, or torn down frequently.
Kubernetes ADOPT
Strategic default for container orchestration when we need scalable, production-grade deployment and operations.
Kubernetes is the industry standard for running containers at scale and fits well as a long-term direction. Use it when operational needs justify it; for smaller systems we still consider simpler managed options.
Keycloak ADOPT
Our default Identity & Access Management (IAM) solution for authentication and authorization. Centralizing login, SSO, and user management instead of building it ourselves.
Keycloak provides a ready-to-run platform for OAuth2/OIDC-based authentication, SSO, and common identity flows (users, roles/groups, clients, tokens). We adopt it to avoid reimplementing security-critical features in applications and to standardize how services integrate with identity across projects. Use it when a system needs real auth (not a demo stub), especially with multiple apps/services, external identity providers, or long-term maintainability requirements.
AWS ECS ADOPT
AWS-native container orchestration that’s often “simpler than Kubernetes” while still enabling scalable container deployments.
ECS can be a strong fit for teams that want managed container orchestration without the operational weight of Kubernetes. It is our pragmatic default for many AWS-hosted services.
Caddy ADOPT
Our default reverse proxy and TLS terminator for a single-server deployment. Certificates from Let's Encrypt are automatic and the configuration fits on one screen.
It fronted the LLM platform we delivered in 2026. The side benefit turned out to be worth as much as the proxying: serving the API and the frontend from one address means there is no second origin, so there is no CORS configuration to get wrong at all. For a small deployment that is a whole category of problem removed rather than solved.
AWS SSM Session Manager ADOPT
Use it instead of an open SSH port. Access flows through AWS identity, so who connected and when is auditable, no keys sit on laptops, and the firewall only needs the web ports.
On the LLM platform we delivered in 2026 it let us close inbound SSH entirely, so the firewall needed only the web ports. The cost is conscious and worth knowing before you choose it: tools that reach a machine over SSH stop working, so configuration management by SSH is off the table and deployment has to run through the same channel.
GitHub OIDC to AWS ADOPT
Authenticate continuous integration to AWS with a federated role rather than stored keys. There should be no AWS access keys in repository secrets.
Used on the LLM platform we delivered in 2026, with the trust scoped to that repository and its main branch, and the role able to run exactly one command against one instance. Long-lived keys in continuous integration secrets are the most common way cloud credentials leak, and this removes them rather than rotating them. The same reasoning applies to a container registry: one authenticated by an expiring token needs re-authenticating on a schedule and will eventually fail a deploy, so prefer a registry that supports role-based authentication.
GitHub Actions ADOPT
We are actively trialing GitHub Actions on smaller projects as a modern, repository-native CI/CD solution. Its tight integration with our source code management simplifies build and deployment pipelines, especially for new or less complex services.
GitOps TRIAL
Infrastructure and platform changes delivered through Git: PRs, reviews, and automated reconciliation from source control.
GitOps improves traceability and repeatability (infra as code + automated apply). We’re trialing it because the workflow is high-value, but we’re still validating our preferred tooling and end-to-end setup patterns.
AWS EKS TRIAL
Managed Kubernetes on AWS—powerful and flexible, but not always the best “default complexity level”.
EKS is great when you truly need Kubernetes’ ecosystem and control. We’re trialing it to clarify when it’s worth the overhead vs. simpler options for our typical workloads.
Azure TRIAL
In use on the dfqt project. Reach for AWS by default on new work, and use Azure where a client's existing estate or requirements point there.
AWS remains our primary cloud and holds most of our operational experience. Azure is on the radar because we run dfqt on it, which is real exposure but narrower. Trial reflects exactly that: it is a viable target when a project calls for it, and we have less depth here than on AWS. Worth noting that every supporting cloud entry on this radar, from ECS to EKS to Lambda, is an AWS service with no Azure equivalent listed yet, so a second Azure project would mean filling some of those in.
Helm ASSESS
Package manager for Kubernetes that standardizes deployment configuration and reuse across environments.
Helm can reduce repetitive YAML and provide composable, versioned “deployment packages.” It’s in assessment because we haven’t used it broadly yet and want to validate patterns, maintainability, and team ergonomics.
AWS Lambda ASSESS
Serverless compute for small, event-driven workloads where simplicity and scaling-by-default outweigh long-running service needs.
We’ve had good results using Lambda for smaller tasks and integrations. We’re assessing its broader fit because we haven’t built many “core systems” around serverless as a primary architecture, and we want clearer guidance on where it shines vs. where it becomes constraining.
Stytch ASSESS
Worth evaluating where a project needs login, tokens and consent management sooner than we can build them. Onboarding is days rather than weeks. Compare it against Keycloak, which we already run.
Noted from another project rather than used here. Pricing is per monthly active user above a free tier of ten thousand, which is generous enough for more than a pilot, but means cost grows with success rather than with usage of our own infrastructure. The lock-in worth weighing is on the identity model itself, since moving off later means remodelling users and consent rather than swapping a library.
Manual Deployments HOLD
Manual and custom-scripted deployments are error-prone and lack the repeatability of automated pipelines. This practice is on hold; all projects are strongly encouraged to migrate to a standardised CI/CD pipeline: GitHub Actions for new work, or Jenkins where it is already established.
Docker Swarm HOLD
Avoid for new work—prefer Kubernetes or AWS managed orchestration options instead.
Swarm is increasingly niche compared to Kubernetes and modern managed orchestration. Existing setups can be maintained where needed, but we don’t recommend starting new platforms or services on Swarm.