Platform Engineering In Action: Deploying a Platform-Ready WordPress Stack with Score to Docker, Kubernetes, and Humanitec-powered IDP.

In platform engineering, the goal is not just deployment — it’s delivery at scale. With a Platform-as-a-Product mindset, engineering teams move beyond infrastructure scripts and start crafting developer experiences.

This Platform Engineering example series brings that idea to life. Over three hands-on tutorials, we transformed the world’s most recognized PHP app — WordPress — into a platform-engineered workload that runs across:

Docker Compose, powered by score-compose
Kubernetes, powered by score-k8s
Humanitec, as a full-fledged Internal Developer Platform (IDP)

More than just a migration, this project reveals how Score enables:

Clear separation between app intent and infra implementation
Runtime portability across environments and teams
Reusable, policy-driven infrastructure with no developer overhead
Self-service deployment workflows that reduce cognitive load

What You Will Learn

Why Score provides a clean, cross-runtime workload abstraction
How to declare resources without writing platform-specific YAML
How platform teams expose golden paths using resource definitions
What “self-service” really looks like for application teams
How this model supports both local-first dev and production-grade ops

What You Will Learn
Table of Contents
The Problem: Fragile, Environment-Specific Deployments
The Solution: A Platform Contract with Score
What the Series Covers
CTO Notes: Strategic Takeaways from Each Part
Why This Matters for Senior Engineers and Platform Teams
Final Thoughts.
Contribute to the Awesome Score Spec.

The Problem: Fragile, Environment-Specific Deployments

Many teams begin with docker-compose.yaml, Helm charts, or handwritten Kubernetes manifests. These work — until they don’t.

Common friction points:

App teams define secrets, ports, and storage inside the workload codebase
Platform teams rewire YAML for each environment
CI pipelines carry brittle logic
Infrastructure knowledge is scattered or duplicated

Over time, onboarding slows, environments drift, and handoffs multiply. The root issue? A lack of abstraction between app needs and infra implementation.

The Solution: A Platform Contract with Score

Score solves this problem by defining a developer-focused workload spec — not a deployment engine.

Developers use Score to describe:

Container images
Environment variables
Required resources (like mysql, dns, route)

Platform engineers then map those resource requests to provisioners or infrastructure definitions — tailored to each runtime.

Example:

A mysql resource maps to a local container in Docker, a StatefulSet in Kubernetes, or an RDS instance via Humanitec
The developer never changes their workload spec

This is the contract. Developers declare intent. The platform fulfills it.

What the Series Covers

This series turns that model into practice by deploying the same score.yaml across three targets — showing how workload portability and platform maturity evolve together.

Part 1: WordPress with Score and Docker Compose

Run WordPress locally with zero docker-compose.yaml. Provision MySQL and dynamic localhost DNS using Score and score-compose.

Platform takeaway: Show developers how to spin up realistic dev environments — fast, safe, and repeatable.

Part 2: WordPress with Score and Kubernetes

Use score-k8s to deploy the same workload spec into Kubernetes — without Helm, kustomize, or YAML handrolls.

Platform takeaway: Codify how services bind, route, and scale in Kubernetes — without burdening application developers.

Part 3: WordPress with Score and Humanitec

Deploy to a full-blown IDP powered by Humanitec. Use resource definitions and classes to provision MySQL dynamically. Expose routes. Inject secrets. All with humctl score deploy.

Platform takeaway: Deliver self-service infra with policy-driven guardrails. No YAML, no kubectl, no ops bottlenecks.

CTO Notes: Strategic Takeaways from Each Part

Each layer of this series adds value — not just to the platform, but to the developer experience.

Part	Target Runtime	Developer Outcome	Platform Outcome
1	Docker Compose	Fast, local-first dev	Clean provisioning for inner loop environments
2	Kubernetes	Seamless staging rollout	Declarative runtime behavior, reusable patches
3	Humanitec	Self-service app delivery	Policy-driven infra, zero handoffs

This is what platform evolution looks like — starting small, scaling smart.

Why This Matters for Senior Engineers and Platform Teams

For senior engineers

This pattern enforces clean boundaries. No more leaking Kubernetes concerns into app code. No more bespoke docker-compose.yaml files. Score becomes the source of truth, while platform logic stays isolated.

For platform teams

It’s the blueprint for building golden paths. Each provisioner or resource definition becomes an internal product — with a defined interface, clear defaults, and environment-aware behavior.

For engineering leadership

This model supports autonomy without chaos. Developers ship faster, while platform teams codify and control infrastructure evolution — at scale.

Final Thoughts.

WordPress was just the starting point. This approach works across:

Legacy apps being containerized
New microservices needing repeatable environments
SaaS platforms rolling out self-service environments

Score defines what the app needs. The platform decides how it’s delivered.

By combining Score with runtime tools like score-compose, score-k8s, and Humanitec, teams achieve:

Developer autonomy with safety
Platform consistency without friction
Infra-as-product patterns that scale

It’s not just about YAML replacement — it’s a new operating model for platform-first organizations.

Contribute to the Awesome Score Spec.

This article series is part of the Awesome Score Spec Examples project.

If you’ve learned something here — or if you want to share how your team runs Score in production:

⭐️ Star the repo
💡 Open a PR with your example
🔄 Reuse this pattern inside your platform

Let’s make platform engineering practical — and portable — for every team.