Every backend team eventually discovers the same pattern: one team deploys their service with GitHub Actions and Terraform, another uses a Makefile that shells out to the AWS CLI, a third has a custom script that someone wrote two years ago and nobody wants to touch. All three services run in production. None of them follow the same conventions for logging, health checks, or secret management.

Golden paths are the response to this drift. The term was popularized by Spotify's platform engineering team and describes an opinionated, well-maintained route from "I need a new service" to "it's running in production with monitoring, CI/CD, and proper infrastructure." This guide covers the traditional approach (Backstage templates + Terraform + ArgoCD) and the framework-enforced approach where tools like Encore make the golden path the only path by building standards into the framework itself.

The goal isn't uniformity for its own sake. When services follow the same deployment patterns, on-call engineers can debug unfamiliar services without learning a new toolchain first. New hires ship their first PR in days instead of weeks because the path from code to production is documented and consistent. Production incidents from non-standard deployments drop because the golden path has already been hardened by every team that used it before.

What a Golden Path Covers

A golden path for backend development typically spans five layers:

Service scaffolding. A template or generator that produces a new service with the right directory structure, dependency versions, configuration format, and boilerplate. The service starts with logging, health checks, and API documentation already wired in.

CI/CD pipeline. Standardized build, test, and deploy steps that every service gets by default. Developers push code, the pipeline handles the rest. No per-service pipeline configuration, no bespoke Docker builds, no "ask DevOps to set up Jenkins for your new repo."

Infrastructure provisioning. When a service needs a database, a cache, or a message queue, the golden path defines how to request it and how it gets provisioned. Security policies, network configuration, and access controls are baked in. Developers don't write Terraform modules from scratch for each service.

Environment management. Preview environments for pull requests, staging environments that mirror production, and production deployment with rollback support. Every service gets the same environment topology without custom configuration.

Observability defaults. Tracing, metrics, and structured logging configured out of the box. When a service launches, it's already emitting the data that on-call engineers need. No post-launch scramble to add monitoring.

Getting one of these layers right is manageable. Getting all five to work together, stay consistent across 20 or 50 services, and remain current as your infrastructure evolves is where the difficulty lives.

The Traditional Approach: Backstage + Terraform + ArgoCD

Most organizations that invest in golden paths follow a pattern that looks something like this:

Backstage provides the service catalog and scaffolding templates. When a developer creates a new service, they pick a template in Backstage that generates a repository with the right structure, pipeline configuration, and infrastructure definitions. The template encodes your organization's conventions.

Terraform modules handle infrastructure provisioning. Your platform team writes modules for databases, caches, queues, and networking that enforce security and configuration standards. The golden path template wires the service to these modules so developers don't interact with Terraform directly.

ArgoCD or a similar GitOps tool handles deployment to Kubernetes. Infrastructure state lives in Git, and changes deploy automatically when merged. Rollbacks are git reverts.

GitHub Actions or GitLab CI runs the build and test pipeline, triggers ArgoCD syncs, and runs any pre-deployment checks.

Datadog, Grafana, or a similar observability stack provides the monitoring layer, with dashboards and alerting rules that the platform team maintains.

This works. Large organizations run golden paths this way and get real value from them. But the integration surface is enormous. The Backstage template generates Terraform that provisions infrastructure for a Kubernetes cluster that ArgoCD deploys to, and the observability stack needs to know about all of it. Each connection is custom glue code that your platform team maintains.

When a golden path template falls behind, the gap between what the template generates and what production services look like starts to grow. Team A forks the template because they needed a different database configuration. Team B skips the template entirely because it didn't support their use case. Six months later, you're back to three teams with three different deployment patterns, except now you also have a Backstage instance to maintain.

The ongoing cost is the part that catches people off guard. A platform team of three to five engineers can spend the majority of their time updating Terraform modules, fixing Backstage plugins after upgrades, debugging ArgoCD sync failures, and handling requests from teams that need something the golden path doesn't cover yet.

Framework-Enforced Golden Paths

There's a structurally different approach. Instead of building a golden path from a collection of tools and templates layered on top of a general-purpose framework, the framework itself enforces the path.

Encore takes this approach with its open-source TypeScript and Go frameworks. Infrastructure resources are declared as typed objects in application code. A database isn't provisioned through a Terraform module that a template generated; it's a SQLDatabase declaration in your service code that the framework understands at the type level. A pub/sub topic is a Topic with typed message schemas. A cron job is a CronJob with a schedule expression.

Because the framework parses these declarations, it knows what infrastructure every service needs without external configuration files. That understanding propagates through the entire workflow:

Scaffolding becomes unnecessary. There's no template to maintain because the framework defines how services are structured. Every service declares its APIs and infrastructure the same way because the type system enforces it. A new developer creates a service by writing code in the format the framework expects, not by running a scaffolder that generates boilerplate.

CI/CD is built in. Encore Cloud runs your build pipeline automatically when you push to a connected repository. There's no per-service pipeline configuration. Every service gets the same build, test, and deploy workflow because the platform understands the application structure from the framework's declarations.

Infrastructure provisioning is automatic. When you deploy, Encore provisions the databases, caches, pub/sub topics, and cron jobs your code declares in your own AWS or GCP account. The provisioned infrastructure follows the same patterns for every service because there's one provisioning system, not per-team Terraform modules.

Environments come included. Preview environments spin up per pull request with isolated infrastructure. Staging and production environments are configured through the platform, not through environment-specific Terraform workspaces or Kubernetes namespaces.

Observability is automatic. Distributed tracing, structured logging, and metrics are built into the framework's runtime. Every service emits the same telemetry format because the framework handles instrumentation. There's no "add the Datadog agent" step.

The result is that the golden path isn't a layer of tooling on top of your stack. It's the stack. Every service follows the same patterns because the framework only allows one way to declare infrastructure, define APIs, and structure services.

Rigidity as a feature and a constraint

Framework-enforced golden paths are more rigid than template-based ones. That rigidity cuts both ways.

With a Backstage template approach, a team that needs something the golden path doesn't cover can fork the template, modify their Terraform, or deploy differently. The escape hatch exists. It creates drift, but it also handles edge cases.

With a framework-enforced approach, the framework defines what's possible. If Encore's primitives don't cover your infrastructure need, you can't declare it in the framework. You can still provision resources outside the framework and connect to them, but that resource falls outside the golden path. The framework supports common infrastructure patterns (SQL databases, Redis, pub/sub, cron, object storage, secrets), but if you need something exotic, you're working around the framework rather than within it.

Adoption is the other consideration. Template-based golden paths work with whatever framework your services already use. Express, Fastify, Hono, NestJS — the template wraps around your existing code. A framework-enforced golden path requires using that specific framework. For new projects, that's a straightforward choice. For existing codebases with dozens of services on Express, migration is a project in itself.

Which Approach Fits

Template-based golden paths make sense when you have a large, diverse codebase, a dedicated platform team to maintain the tooling, and teams that need flexibility to handle edge cases. The overhead is justified by the scale.

Framework-enforced golden paths make sense when you want consistency without the platform team. If you're a team of 5 to 30 developers and the alternative to a framework-enforced path is no golden path at all (because nobody has the bandwidth to maintain Backstage + Terraform + ArgoCD), the framework approach gives you standardization as a side effect of using the framework.

The deeper question is whether your golden path should be a layer you maintain or a property of the tools you choose. Both work. One costs more to operate. The other costs more in flexibility.

For teams evaluating the framework approach, Encore's open-source framework is worth trying on a new service to see whether the constraints fit your needs. The cloud platform handles the deployment and infrastructure provisioning side. If the primitives cover what your services need, you get a golden path without building one.