What Tools Does a Platform Engineer Use? A 2026 Guide

What Tools Does a Platform Engineer Use? A 2026 Guide

Last Tuesday, I watched a 40-node Kubernetes cluster melt because a junior engineer forgot to set resource limits on a cronjob. That was at a fintech startup paying $185k for a platform engineer. The fix wasn't a new tool – it was the right tool configured correctly. That's the whole job.

You're reading this because you want the unfiltered list. Not the marketing fluff from HashiCorp or the "use our product for everything" pitch from a vendor. I've been building platform teams at SIVARO since 2018, processing 200K events per second for clients in healthcare, logistics, and AdTech. I've made every tool mistake you can make. Here's what I use now, and why.

By the end of this, you'll know what tools a platform engineer uses in 2026, which ones pay the bills (salary data included), and which ones you should ignore. Let's start with the layer that kills most startups.

The Core Stack: Compute, Storage, Networking

Most people think platform engineering starts with Kubernetes. Wrong. It starts with a clear contract between your platform and your application teams. That contract is a set of tools that enforce boundaries while giving developers freedom.

Kubernetes is still the default. But I'm not running vanilla k8s anymore. I'm running K3s on edge nodes and EKS on AWS. Why two? Because last year we found that K3s on ARM-based Graviton instances cut our cluster cost by 38% for stateless workloads. The trade-off? Less community support for exotic CNIs. You pick your poison.

For storage, Rook/Ceph was my go-to until 2025. Then I moved to Longhorn for block storage on bare metal. It's simpler, backups are trivial, and I can snapshot a 2TB volume in under 3 seconds. For object storage, MinIO on-prem and S3 in cloud. Never use blob storage without lifecycle policies – I learned that when a client's monthly S3 bill hit $47,000.

Networking is where most people overcomplicate. I use Cilium for eBPF-based networking and security. Why not Calico? I ran Calico for two years. Cilium gave us 15% better throughput and we could enforce network policies at L7 without sidecars. If you're on a tight budget, Flannel works fine for small clusters under 50 nodes. Above that, you need Cilium.

Here's a real cluster.yaml I used last week for a client onboarding:

yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: production-01
spec:
  controlPlaneRef:
    kind: KubeadmControlPlane
    name: prod-cp
  infrastructureRef:
    kind: AWSCluster
    name: prod-aws
  clusterNetwork:
    pods:
      cidrBlocks: ["10.244.0.0/16"]
    services:
      cidrBlocks: ["10.96.0.0/12"]

That's the skeleton. The real work is in the CNI and CSI configs.

Observability: The Non-Negotiable Layer

If you can't see it, you can't fix it. Period.

Prometheus with Thanos is my default. I started with plain Prometheus in 2019. Then I hit the cardinality wall when a service emitted 300 custom metrics. Thanos gave me long-term storage on S3 and global querying across 6 clusters. Yes, it's more infrastructure. Yes, it's worth it.

Grafana dashboards – hand-crafted, not auto-generated. I spend two hours per service to build dashboards that show latency distributions (p50, p95, p99), error rates, and saturation. Most people use the default "Kubernetes Cluster" dashboard. That tells you nothing about your applications. Delete it.

For logs, Loki replaced Elasticsearch in 2024. The cost difference was insane – $2,000/month vs $12,000/month for our volume. Loki doesn't index everything. It indexes metadata. You lose full-text search speed on gigabyte-sized log queries. If you need that, keep a small Elasticsearch instance for security logs. Everything else goes to Loki.

Traces? OpenTelemetry with Jaeger for storage. We send 100% of traces for critical services (payment, auth) and 1% sampling for the rest. The overhead on the payment service was 3% – acceptable. But we learned to batch spans in the collector, or the pod memory spikes. Here's a collector config we use:

yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch:
    timeout: 5s
    send_batch_size: 1000
exporters:
  jaeger:
    endpoint: jaeger-collector:14250
    tls:
      insecure: true
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [jaeger]

This config runs on a single m5.large instance and handles 15K spans/second.

CI/CD Pipeline Tooling: Not Just Jenkins

Jenkins is dead. Not literally – it's still running at banks. But no one builds new platforms on it unless they hate themselves.

ArgoCD is my GitOps controller of choice. Why? Its ApplicationSet feature lets me generate deployments from a single template per environment. We have 47 microservices. Each goes through dev, staging, prod. With ApplicationSets, I changed one line in a generators field and all 141 deployments updated. The alternative would be 47 separate YAML files and a script to patch them. Not for me.

For the pipeline engine itself, GitHub Actions for smaller teams (under 50 engineers) and Tekton for enterprise. I evaluated Drone CI and Buildkite in 2025. Both are excellent but GitHub Actions wins on integration – your PR checks, approvals, and releases all in one place. The con: action marketplace has security risks. We only use verified creators.

Here's a pipeline.yaml for a service that builds and deploys:

yaml
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  tasks:
    - name: build
      taskRef:
        name: kaniko-build
      params:
        - name: image
          value: repo/app:$(params.version)
    - name: deploy
      runAfter: [build]
      taskRef:
        name: kubectl-deploy
      params:
        - name: manifest
          value: ./k8s/deployment.yaml

Simple. And that's the point. Pipelines should be boring.

Developer Experience Tools – The Internal Developer Platform

This is where the industry goes wrong. Every company thinks they need Backstage with a custom plugin for everything. You don't.

I built an internal developer portal at SIVARO using Port (the product engineering company). It took two weeks. Backstage took three months at a previous job. The trade-off: Port is less flexible for deep customization. But we don't need deep customization – we need developers to be able to spin up a new service with the right CI/CD, secrets, and monitoring in 10 minutes. Port's blueprints gave us that.

Your internal developer platform should have three tools:

1. A service catalog – I use Backstage for this (deployed as a Helm chart on k3s). It ingests data from ArgoCD, Datadog, and PagerDuty. Developers can see ownership, dependencies, and on-call rotations.
2. A scaffolder – Cookiecutter templates plus a GitHub Action to create repos. Not fancy. Works.
3. A platform scorecard – Simple checks: does every service have a health endpoint? Prometheus metrics? A Dockerfile? We built this in Python with SQLite. Developers see their score in the portal.

One contrarian take: you don't need a full platform if you have fewer than 50 engineers. Templates and documentation are enough. I've seen three startups burn six months building an internal platform that was obsolete by launch.

Security and Secrets Management

Vault for secrets. I've used AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault. Vault gives me a consistent API across clouds and on-prem. The downside: it's another stateful service to manage. I've had Vault unseal fail at 3 AM because a raft quorum was lost. Worth it for the flexibility.

For policy enforcement, Kyverno or OPA. I started with OPA in 2021. It's powerful but the Rego language has a steep learning curve. Kyverno is easier for Kubernetes-native policies: "prevent containers from running as root" or "require resource limits". Here's a Kyverno policy I wrote last month:

yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resources
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-containers
      match:
        resources:
          kinds: ["Pod"]
      validate:
        message: "Containers must have resource requests and limits."
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    memory: "?*"
                    cpu: "?*"
                  limits:
                    memory: "?*"

This runs in audit mode first, then enforced after two weeks. Gave developers time to fix their YAML.

The Unexpected Ones: Spreadsheets and Slack Bots

You won't see these on any vendor's website. But I've spent more time in Google Sheets in the last year than in any IDE.

Spreadsheets for capacity planning. When we migrated from GKE to EKS, I modeled node costs, reserved instances, and spot interruptions for 50 services. The spreadsheet had 12 sheets – one per environment. It saved us $30K/month by identifying 4 services that could run on spot without disruption.

Slack bots for operational toil. We have a bot that posts daily resource usage per namespace. Another bot that reminds teams to rotate API keys every 90 days. Written in 50 lines of Python each. No framework. No deployment pipeline. cronjob on the cluster. Done.

How to Choose Your Toolbox (Without Going Insane)

Here's the framework I use at SIVARO:

1. Start with the problem, not the tool. Before choosing ArgoCD, ask: "Do we deploy more than 20 times a week?" If no, use a script.
2. Prefer boring technology. The most exciting tool in 2023 is the abandoned project in 2026. I still run PostgreSQL on VMs. It's boring. It works.
3. Hire for judgment, not tool knowledge. I can teach anyone Kubernetes in two weeks. I can't teach system thinking. The platform engineer skills required for 2026 include architecture, cost analysis, and communication. Tool proficiency is baseline.
4. Budget for migration. Every tool you pick today will need to be replaced within 3 years. Plan for it. Set aside 10% of your infrastructure spend for migration work.

Speaking of budgets, let's talk numbers. My team in San Francisco pays platform engineers between $170K and $220K base, per Glassdoor and ZipRecruiter data as of July 2026. The Kore1 salary guide shows similar bands for senior roles. If you're strong in Kubernetes and Terraform, you can command $190K+ in New York. But note: the Platform Engineering article points out that total compensation can exceed $250K when factoring RSUs and bonuses at FAANG-adjacent companies.

FAQ

Q: What tools does a platform engineer use for infrastructure provisioning?
A: Terraform for cloud resources, Pulumi for TypeScript-loving teams. Both work. I use Terraform because its ecosystem is larger. But Pulumi's state management is better for complex dependencies.

Q: Do I need to know all these tools to get a platform engineer job?
A: No. Know the concepts. Every company has a different stack. If you understand service mesh, you can learn Istio, Linkerd, or Cilium in a week. Focus on Linux containers, networking, and observability principles.

Q: What's the platform engineer salary 2026 for mid-level?
A: In US tech hubs, $140K-$170K base. Remote adds 10% flexibility but you compete globally. See the salary guide for city breakdowns.

Q: How does platform engineer differ from DevOps?
A: DevOps is about culture and automation. Platform engineering builds the internal product that developers consume. Think of it as DevOps with a product mindset. The Octopus article explains well.

Q: Should I use a managed Kubernetes service or self-host?
A: Managed 90% of the time (EKS, AKS, GKE). Self-host only if you need bare metal control or data sovereignty. I self-host for one client because they process medical images that can't leave their data center.

Q: What's the one tool you'd never drop?
A: Terraform. It's the source of truth for everything. When a cluster dies, Terraform rebuilds it. When you need to audit resources, Terraform shows you. Treat it as the contract between your platform and reality.

Q: How do I learn platform engineering tools?
A: Build a home lab. Run k3s on a Raspberry Pi. Add Prometheus. Deploy an app with ArgoCD. Break things on purpose. The Port article suggests focusing on one problem (like CI/CD) and learning deeply, not skimming across 20 tools.

Conclusion

Platform engineering is about reducing friction between development and operations. The tools are the vehicle, not the destination. I've seen teams obsess over the perfect service mesh while their developers wait 30 minutes for a build. Fix the build first.

What tools does a platform engineer use? The ones that solve the problems your team actually has. No more, no less. Start with Kubernetes, Prometheus, Terraform, and ArgoCD. Add observability and a developer portal. Then stop. Don't add Vault until you have secrets to manage. Don't add Cilium until Calico hurts.

My salary at SIVARO doesn't come from knowing every knob in every tool. It comes from knowing which knob to turn, and when. Build that judgment, and you'll be paid well – in 2026 and beyond.

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.