Golden Paths and Guardrails

Finding the sweet spot between flexibility and restrictions

One of the fundamentals of an Internal Developer Platform is enabling self-service for development teams. There’s often a misconception, though, that self-service means giving developers unrestricted access to all the underlying infrastructure and tools. That approach usually leads to complexity, confusion, and—ultimately—low platform adoption. In fact, if access is completely unrestricted, what’s the point of having a platform at all?

I like to think of self-service as a buffet in a restaurant. You’re presented with a variety of already prepared dishes. You don’t need to know how to cook them. You pick what you want, and it’s ready to eat. The kitchen staff has done the hard work so you can enjoy the results without the hassle.

Now, maybe you’d like a variation of a particular dish. You can ask the cook whether it can be customized, but it might take longer or incur additional costs. Or maybe you want to cook the same dish at home. In that case, you can ask for the recipe and ingredients, but you’re responsible for cooking and handling any mistakes along the way.

In the context of an Internal Developer Platform, we call these dishes golden paths. Golden paths are well-defined, tested (and tasty!), and documented approaches to everyday tasks. They should cover the most frequent use cases and be easy to follow. They’re intentionally opinionated. They guide developers toward best practices and reduce the cognitive load of infrastructure and tooling decisions.

At the same time, flexibility matters. If a developer needs to deviate from the golden path, they should be able to, but with the understanding that they’re taking on more responsibility for the outcome.

Golden paths come in many forms, depending on an organization’s needs and context. Some common examples include:

• Module libraries
  Predefined infrastructure-as-code modules (for example, Terraform modules or Helm charts) that allow developers to provision resources consistently and securely. A PostgreSQL module, for instance, might ask only for a name, size, and region, while handling backups, monitoring, and security by default—yet still allowing advanced customization when needed.

• CI/CD pipelines
  Preconfigured pipelines that automate build, test, and deployment workflows. For example, a pipeline that builds a Docker image for a .NET application, runs tests, and pushes it to a registry on every merge to main. Developers can use it as-is or extend it for more advanced scenarios.

• Service templates
  Standardized templates for deploying services. Think of a Kubernetes-based web application template with autoscaling and monitoring baked in. Developers provide the application code and choose a framework (Node.js, Python, Java, etc.), and the platform handles the rest.

• SDKs
  Well-designed SDKs that abstract infrastructure concerns behind simple interfaces. For example, an SDK for emitting structured logs or telemetry without forcing developers to understand the details of OpenTelemetry.

As platform engineers, our mission is to offload complexity and decision-making from development teams and lower their cognitive load. But it’s essential to be clear that golden paths are not about restricting creativity or autonomy. If we’re too restrictive, the platform becomes a golden cage. Developers will feel constrained and eventually look for ways around it.

This is where guardrails come into play.

Guardrails define the boundaries of acceptable behavior on the platform. They prevent choices that could compromise security, reliability, or maintainability. A guardrail might block deployments to unapproved regions, prevent resource starvation in shared clusters, enforce backups on critical databases, or require security scans before releasing to production.

We don’t implement guardrails to limit developers. We do it to protect the company’s assets, reputation, and compliance posture. Like guardrails on a road, they don’t stop you from reaching your destination. They keep you from veering off the road and crashing.

Guardrails can be implemented at different layers. In general, the higher the layer (e.g., preventive policies enforced by the cloud provider, or admission controllers in Kubernetes), the harder it is to bypass and the more effective it tends to be. Lower-level guardrails (such as defaults in modules) are easier to work around and to evolve.

There is no perfect balance that works for everyone, and you will need to navigate and evaluate trade-offs as you develop and evolve the platform. In the first few iterations, you will be more permissive on what teams can do. But as you mature the platform, you won’t allow certain activities, or if you do, you want to have complete control over them.

That’s all for now.

P.S. Chapter two of Crafting Platforms will be published by the end of this week. Stay tuned!