December 13, 2025·3 min read

Disclaimer: I am a few weeks into building an internal developer platform for myself. Here is what I have learned so far.

Golden paths get a lot of attention in platform engineering discussions. Most of that attention stops at creation—scaffolding repos, setting up CI, and deploying to Kubernetes.

That part is relatively solved.

The harder problem is day-2 operations. That is where golden paths get more complicated.

I have been experimenting for a month with golden paths built on Backstage, Argo CD, and Kubernetes, and then layering Port.io on top to handle the parts that do not fit cleanly into GitOps alone.

Day-1 Is Easy

A typical golden path stack could look like this:

• Backstage for service creation and discoverability
• GitHub as the source of truth
• Argo CD for GitOps reconciliation
• Kubernetes as the runtime

Backstage software templates do a solid job at day-1:

• Repos are scaffolded consistently
• CI/CD pipelines are pre-wired
• Deployment manifests exist from the start
• Services show up in a catalog instead of disappearing into someone's personal GitHub

That initial experience matters. Early decisions tend to stick, for better or worse.

But once the service exists, for me, Backstage mostly steps aside.

Where Things Get Messy: Day-2

Day-2 is where reality shows up.

Examples:

• Restarting or scaling a misbehaving service
• Promoting config between environments
• Triggering a redeploy without a code change
• Inspecting ownership, dependencies, or runtime state
• Performing safe operational actions without giving everyone kubectl access

These actions do not always belong in Git. They also do not belong in sending messages to the platform team.

This is where I started looking at Port.io.

How Port.io Fits

I found Port.io most useful for day-2 operations, with some ability to trigger day-0 creation workflows when needed.

Port does not natively scaffold code.

It triggers things that do.

So in practice:

• Port can be the button a developer clicks on day-0
• Backstage (or a repo template) can still do the scaffolding
• Git remains the source of truth
• Argo reconciles state

In that sense, Port is not a "day-0 engine" so much as a day-0 orchestrator.

In my lab setup:

• Backstage is the entry point for creation, metadata, and discovery
• Git and Argo CD remain the source of truth
• Port.io becomes a controlled interaction layer on top

Using Port, I modeled:

• Services, environments, and clusters as entities
• Relationships between repos, workloads, and infrastructure
• Actions that map to real operational workflows like restart, sync, and promote

Crucially, those actions do not mutate the cluster directly.

They trigger:

• GitHub Actions workflows
• Argo CD syncs
• Or other well-defined automation steps

In my setup, provisioning remained outside of Port. That constraint mattered. Without it, the platform quickly started to resemble a prettier kubectl wrapper.

Why This Separation Actually Works

Each tool is good at a different thing:

Backstage is strong at creation but limited once a service is running. Port works well for interaction and visibility but benefits from clear boundaries. Argo enforces desired state but does not provide much guidance at the human level.

Once I stopped trying to make one tool do everything, the system made more sense.

What Success Might Look Like

I am still early in building this, so I do not know yet what success looks like in practice.

What I am looking for instead are signals that things are moving in the right direction:

• New services start to look boring in similar ways
• Day-2 actions become visible and repeatable
• The platform starts answering questions before people ask them (with AI)

If those things start to happen over time, that will feel like progress.

Final Thought

Backstage, Argo CD, Kubernetes, and Port.io are all powerful tools.

None of them are the golden path by themselves.

Golden paths emerge when:

1. Defaults are intentional
2. Day-2 operations are treated as first-class concerns
3. The platform allows teams to step off the path without friction

There are tradeoffs no matter how you design this. That is usually where the real work begins.

Tags:

Enjoyed this post? Give it a clap!