Platform Engineering: Build an Internal Developer Platform

By Kokil Thapa | Last reviewed: September 2026

Platform Engineering: Build an Internal Developer Platform when your team spends more time wiring servers than shipping features. Copy-paste deploy scripts, one-off staging URLs, and “ask DevOps” tickets do not scale past a handful of repositories. An internal developer platform (IDP) turns those repeated chores into self-service workflows with guardrails. This guide walks through what to build first, which tools fit a PHP and Laravel stack, and how to roll out an IDP without a dedicated platform team of twenty.

What is platform engineering and how is it different from DevOps?

Platform engineering is the practice of building and maintaining an internal product for developers. That product is the IDP: templates, pipelines, secrets, environments, and documentation packaged as self-service capabilities. DevOps focuses on culture, collaboration, and delivery speed. Platform engineering productises the outcome of that culture so every squad gets the same reliable path to production.

Think of DevOps as the goal and the IDP as the paved road. Without the road, each team hacks its own trail. With it, they choose from approved routes that already include security, logging, and rollback. On sister legal-tech sites I maintain with Deployer 7 and GitLab CI, the “platform” is modest: shared deploy recipes, environment conventions, and a checklist new repos inherit on day one. That is still platform engineering—just right-sized.

The CNCF platform engineering maturity model describes progression from ad hoc scripts to measured platform products. You do not need stage five on day one. Stage two—documented golden paths with automated provisioning—already removes most Friday-night deploy panic.

Platform team vs embedded DevOps

A platform team builds capabilities other teams consume. Embedded DevOps engineers sit inside product squads. Small agencies often blend both: one senior engineer owns the deploy pipeline while developers stay in feature work. The rule stays the same: if two teams repeat a task twice, platformise it.

How do you build an internal developer platform step by step?

Start with developer interviews, not tooling. Ask where delivery slows down: environment drift, missing staging data, flaky tests, or opaque production logs. Rank pain by frequency and blast radius. Your first golden path should fix the highest-frequency bottleneck for the majority of repos.

1. Inventory services and environments. List every app, its runtime (PHP 8.3+, Node 26 LTS for assets), database, queue worker, and cron entry. Note who deploys today and how long it takes.
2. Pick one reference application. Choose a representative Laravel 13 or Laravel 12 app—not your messiest legacy codebase. Hard problems come later.
3. Encode the golden path. Standardise repo layout, branch strategy, CI stages, and deploy hooks. Commit working examples.
4. Automate environment creation. Script staging from a template: database, .env secrets, DNS subdomain, TLS cert.
5. Publish through a portal. Even a markdown catalog plus links beats tribal knowledge. Graduate to Backstage when catalog size grows.
6. Measure and iterate. Track lead time, deploy frequency, change failure rate, and mean time to restore. Cut steps that do not move those numbers.

For PHP shops, the golden path often mirrors what already works in production. Here is a minimal GitLab CI skeleton for a Laravel app using Composer 2.10, committed Vite 8.x assets, and Deployer 7:

# .gitlab-ci.yml — golden path baseline
stages: [lint, test, build, deploy]

lint:
  image: php:8.3-cli
  script:
    - composer install --no-interaction
    - vendor/bin/pint --test

test:
  image: php:8.3-cli
  services: [mysql:8.4]
  script:
    - cp .env.testing .env
    - php artisan migrate --force
    - vendor/bin/phpunit

deploy_staging:
  stage: deploy
  script:
    - dep deploy staging -vvv
  environment:
    name: staging
    url: https://staging.example.com

deploy_production:
  stage: deploy
  when: manual
  script:
    - dep deploy production -vvv
  environment:
    name: production
    url: https://example.com

Pair that with a shared deploy.php every new repo imports. On production Laravel applications I have shipped, symlinked releases with shared storage/ and .env cut downtime to seconds. That pattern belongs in the platform, not in each developer’s memory.

Environment templates that actually get used

Developers ignore platforms that require fifteen form fields. Offer three presets: minimal (web + MySQL 8.4), standard (web + queue + Redis 8.10), and enterprise (HA database, read replica, scheduled backups). Map each preset to Terraform modules, Ansible roles, or—for a single Ubuntu 24 server—a bash script checked into a platform repo.

#!/usr/bin/env bash
# platform/scripts/create-staging.sh
APP="$1"
DOMAIN="${APP}.staging.example.com"
sudo mysql -e "CREATE DATABASE IF NOT EXISTS ${APP}_staging;"
sudo certbot certonly --nginx -d "${DOMAIN}" --non-interactive --agree-tos -m ops@example.com
dep deploy:unlock staging
dep deploy staging

Store generated URLs and credentials in your portal catalog. When onboarding a booking app like Adventure Third Pole Trek, the staging link should appear before the developer asks for it.

What tools should you use for an internal developer platform in 2026?

Tool choice follows constraints, not hype. A five-person Nepal agency running Laravel on a shared EC2 box needs GitLab CI, Deployer, and a markdown service catalog—not Kubernetes on day one. A product company shipping twenty microservices may need EKS, Argo CD, and Crossplane. Match the platform to your actual topology.

For enterprise application development, add policy checks in CI: dependency audit, container scan, and PHPStan level six before merge. Those gates belong in the platform layer so individual teams cannot skip them under deadline pressure.

Service catalog and software templates

A catalog entry is more than a repo link. Document owner, on-call rotation, SLAs, upstream dependencies, and the exact command to deploy. Software templates—Cookiecutter, Yeoman, or Laravel’s own starter kits—scaffold folder structure, CI file, Dockerfile, and health endpoint. New services should reach staging in under an hour.

Validate pipeline YAML with a JSON or YAML formatter in local pre-commit hooks. Small quality gates prevent broken configs from blocking everyone else’s pipeline.

How do you roll out platform engineering without blocking feature work?

Treat the IDP like any internal product. Publish a roadmap. Run office hours. Never mandate a migration during a client deadline week. Pilot with one willing team, collect feedback, fix rough edges, then expand.

Platform work should reduce queue depth for Linux system administration tickets. If staging requests still land in Slack after three months, the self-service UX failed—not the developers.

Version and runtime standards

Pin supported runtimes in platform docs: PHP 8.3 minimum for Laravel 13, PHP 8.2 for Laravel 12, MySQL 8.4 or 9.7, Redis 8.10 for cache and queues. Document upgrade windows so product teams know when PHP 8.5 becomes the default on shared hosts. Consistent runtimes eliminate “works on my PHP” incidents during support and maintenance cycles.

• Opt-in first: New repos use the golden path; legacy repos migrate on touch.
• Thin wrapper: Expose platform deploy staging instead of raw Deployer flags.
• Docs beside code: Keep runbooks in the same repo as the automation script.
• Champion network: One developer per squad feeds platform backlog priorities.

Connect CI to build pipeline automation best practices you already follow. Reuse artifact promotion patterns from reproducible builds so staging and production run identical compiled assets.

What metrics prove your internal developer platform is working?

Executives ask for ROI. Developers ask for fewer blockers. Both can be measured with DORA metrics plus platform-specific signals.

Lead time for changes should drop once self-service staging exists. Deployment frequency should rise without a matching spike in incidents. Change failure rate tracks bad deploys; golden paths with automated rollback keep this flat. Mean time to restore improves when logs, dashboards, and rollback are one click from the portal.

Add platform KPIs: time to first staging deploy for a new service, percentage of repos on the golden path, and developer satisfaction surveys every quarter. If satisfaction is flat while metrics improve, your portal UX probably needs work.

What mistakes break internal developer platforms?

The fastest way to kill adoption is building for a hypothetical microservices future while every repo is still a monolithic Laravel app. Another common failure: the platform team becomes a gatekeeper. Self-service means developers can act without approval for safe operations. Production still gets a manual gate—that is a guardrail, not a ticket queue.

Over-customising Backstage before you have ten catalog entries wastes weeks. Under-investing in secrets management leaks API keys into CI logs. Skipping rollback testing guarantees a bad Friday. I have seen deploy pipelines succeed while cron still pointed at an old release path; include post-deploy smoke tests that hit scheduler and queue workers, not only HTTP 200 on the homepage.

Security and compliance without friction

Embed security in the path: dependabot or composer audit in CI, least-privilege deploy keys, separate staging and production secrets, and audit logs for production promotions. For payment-integrated apps, align checks with PCI DSS essentials for developers. Platforms that bolt security on after launch always lose to those that bake it into templates.

Document incident steps in the portal: how to roll back, rotate keys, and notify stakeholders. When Notary Kathmandu and related sister sites share a pipeline, one runbook covers all—a concrete win from centralised platform docs.

Key Takeaways

• Platform Engineering: Build an Internal Developer Platform by productising golden paths—not by renaming your DevOps team.
• Start with one reference Laravel or PHP app, shared CI and deploy recipes, and a written service catalog before buying heavy portal software.
• Offer self-service environment presets; three tiers beat fifteen custom form fields every time.
• Track DORA metrics plus time-to-first-staging to prove the IDP earns its maintenance cost.
• Keep production promotion manual or policy-gated; automate everything up to that line.
• Iterate from developer feedback—platforms that gatekeep without listening get bypassed within a sprint.

People Also Ask

Do you need Kubernetes to build an internal developer platform?

No. Many productive IDPs run on bare metal or VMs with GitLab CI, Deployer, and Ansible. Kubernetes helps when you operate dozens of independently scaled services. A Laravel agency with shared EC2 hosts should platformise scripts and pipelines first, then evaluate containers when replication pain justifies the ops cost.

How large should a platform team be?

A common ratio is one platform engineer per eight to fifteen product developers, but small shops start with zero dedicated headcount. A senior full-stack engineer spending twenty percent of time on templates and CI often suffices until you pass roughly twelve active repositories or multiple runtime stacks.

What is the difference between an IDP and a developer portal?

The developer portal is the UI and catalog layer. The IDP includes the portal plus underlying APIs, templates, pipelines, and policies that actually provision and deploy. Backstage alone is not an IDP until it triggers real workflows behind the buttons.

How long does it take to build a minimal internal developer platform?

A useful v1—shared CI template, deploy script, staging automation, and markdown catalog—often lands in two to four weeks for teams already running manual but working deploys. Full portal integration, policy engines, and multi-cloud abstraction take months and should follow proven demand, not upfront speculation.

Ship faster with a platform your team will actually use

Platform Engineering: Build an Internal Developer Platform around real developer pain, not vendor slide decks. Document one golden path, automate staging, measure lead time, and expand from there. Whether you run five Laravel client sites or a growing product suite, the IDP is the internal product that pays rent every sprint.

Need help designing CI/CD, deploy automation, or a right-sized IDP for your stack? See custom software development services, browse the portfolio for production examples, or contact us to talk through your current pipeline and where a golden path would save the most time.