Zendesk has unveiled its new Foundation Interface, a unified platform designed to transform infrastructure provisioning into a fully self-service experience. This platform enables engineers to request infrastructure components, such as databases, object storage, compute resources, and secrets, by simply defining requirements in a declarative YAML file. These requests are then automatically validated, provisioned, and monitored through a seamless workflow integrated with Spinnaker and Kubernetes. The result is a major reduction in the time, friction, and uncertainty that previously accompanied infrastructure requests.
At the heart of this transformation lies a robust internal architecture that Zendesk engineers describe as a “genie and helpers” model. The Gatekeeper acts as the initial validator of requests, ensuring correct syntax, resource definitions, and permission scopes. Once approved, requests are routed to the Orchestrator, which breaks them down into Kubernetes-native constructs, specifically, Custom Resources (CRs). These CRs are then handled by domain-specific Kubernetes operators. The Watchdog component continuously monitors the state of these Custom Resources, ensuring all provisioning tasks succeed and signaling Spinnaker when it is safe to proceed with application deployments.
Kubernetes operators are central to this process. An operator is a software extension that uses Kubernetes APIs and the controller pattern to manage complex, stateful applications or infrastructure services.
Operators are typically implemented using controller frameworks such as the Operator SDK, Kubebuilder, or Metacontroller. These frameworks enable teams to define Custom Resource Definitions (CRDs) that extend the Kubernetes API to include new object types, for example, an Aurora Database or a Redis instance. Paired with each CRD is a controller loop that watches for changes to these resources and reconciles the desired state with the actual cluster state.
In practice, this means that when an engineer requests a database through the Foundation Interface, the corresponding operator provisions that database by interfacing with cloud provider APIs, applies configuration, and monitors for success or failure, all without human intervention.
This model ensures that each infrastructure component, be it S3 buckets, RDS instances, or more bespoke services, has a dedicated operator that knows how to provision, configure, and manage its lifecycle. Operators are designed to be idempotent, meaning they can safely reapply the desired state if conditions change, and they can handle edge cases or error recovery without manual intervention. The use of Kubernetes-native tools also means that Zendesk benefits from observability, auditability, and consistency across all provisioned resources.
By integrating this architecture with Spinnaker pipelines, Zendesk engineers can now deploy applications alongside their supporting infrastructure in a single, repeatable flow. The Foundation Interface ensures that infrastructure is provisioned securely and consistently, with automated checks and centralized tracking. Developers are no longer required to submit tickets or wait for manual approvals; they simply write a YAML file and trigger a deployment. The system handles everything else, from validation and resource creation to health checks and status reporting.
Darragh Kennedy, Director of Software Engineering at Zendesk, shared on LinkedIn that the journey toward a self-service infrastructure began years ago with the creation of the Foundation group. He highlighted how the team “built this from the ground up and iterated on it over the years to create a flexible and robust entry point”, underscoring the carefully engineered foundation behind the platform.
His post illustrates the long-term commitment and internal evolution leading to the current system:
“It seems like an age ago that we created the Zendesk Foundation group… we built this from the ground up and iterated on it over the years to create a flexible and robust entry point.”
This commentary reflects a deeper understanding of the engineering effort behind the Foundation Interface, emphasizing that it’s not a quick fix but a mature, iterative platform designed to scale with Zendesk’s engineering needs.
However, functionality like this is not unique to Zendesk. A recent example is Pulumi IDP, launched in May 2025. It offers a “golden path” through standardized infrastructure components and a private registry. This allows developers to consume reusable, policy‑approved configurations (in YAML) for provisioning infrastructure safely and efficiently. Unlike portal‑centric platforms, Pulumi IDP focuses tightly on infrastructure delivery patterns shaped and consumed via platform engineering practices.
The broader industry trend toward Internal Developer Platforms (IDPs) built on Kubernetes is gaining momentum. These platforms abstract Kubernetes complexity behind declarative interfaces and pre‑packaged workflows, enabling teams to self‑serve environments, deploy apps, and manage resources without needing to learn Kubernetes internals. Analysts highlight that success depends not only on technology but also on clear documentation, developer education, and strong platform governance Platform Engineering.
These parallels demonstrate that Zendesk’s choice to define infrastructure through YAML, validated via Kubernetes CustomResources and orchestrated through operators and pipelines, aligns closely with a growing movement. Organizations across sectors are adopting Kubernetes‑based self‑service platforms that abstract complexity, enforce policy, and promote developer productivity, just as Zendesk’s Foundation Interface aims to do.
