Platform Engineering 2026: Backstage vs Port vs Cortex

Platform engineering har blivit ett av de hetaste begreppen i branschen, och som med allt hett finns en risk att man bygger det för att det är på modet snarare än för att man behöver det. Jag har sett interna plattformar som blev teamets favoritverktyg, och jag har sett plattformar som blev dyra monument ingen rörde. Skillnaden handlar nästan aldrig om vilket verktyg man valde, utan om huruvida plattformen löser verkliga problem. Men när valet väl ska göras står det 2026 ofta mellan Backstage, Port och Cortex, och de skiljer sig mer än man tror.

Vad en intern utvecklarplattform faktiskt är

I kärnan handlar platform engineering om att behandla din interna infrastruktur som en produkt, med utvecklarna som kunder. I stället för att varje team ska lista ut hur man deployar, sätter upp övervakning och hanterar hemligheter på egen hand, bygger en plattformsfunktion vägar som gör det enkelt att göra rätt. De tre verktygen jag jämför här är alla så kallade developer portals, men de tar olika väg dit.

Det centrala begreppet är en katalog över allt ni äger, tjänster, beroenden, ägare, och golden paths, väl upptrampade stigar för de vanligaste sakerna ett team behöver göra. Hur väl ett verktyg stödjer båda är det jag väger tyngst.

Backstage: kraftfullt och öppet, men du bygger mycket själv

Backstage är öppen källkod och kom ur Spotify. Det är det mest flexibla av de tre: i princip allt går att forma, och det finns ett stort ekosystem av plugins. För en organisation med egna utvecklingsresurser och tydliga behov är det svårslaget i hur långt du kan ta det.

• Styrkor: maximal flexibilitet, ingen licenskostnad, stort ekosystem och full kontroll över din data.
• Avvägning: det är ett ramverk, inte en färdig produkt. Du bygger och driftar det själv, och det kräver löpande utvecklingstid att hålla vid liv.

Backstage passar när ni har resurser att äga en intern produkt och vill ha total kontroll. Det passar sämre om ni vill ha något som fungerar nästa vecka utan eget utvecklingsarbete.

Port: snabbt igång och konfigurerbart

Port är en hanterad produkt och tar en annan väg än Backstage. I stället för att bygga i kod konfigurerar du din katalog och dina självbetjäningsåtgärder i ett gränssnitt, vilket gör att du kommer igång snabbt. Datamodellen är öppen och flexibel, så du modellerar din egen verklighet utan att skriva ett ramverk.

• Styrkor: snabb tid till värde, ingen plattform att drifta själv, flexibel datamodell och fokus på självbetjäning.
• Avvägning: det är en extern hanterad tjänst med en licenskostnad, och du anpassar dig till produktens ramar snarare än att bygga helt eget.

Port passar team som vill ha kraften i en utvecklarportal utan att bygga och drifta den, och som värdesätter att komma igång fort.

Cortex: med tonvikt på standarder och mognad

Cortex är också en hanterad produkt, men med en tydlig betoning på tjänstemognad och så kallade scorecards. Tanken är att inte bara katalogisera dina tjänster utan att aktivt mäta dem mot standarder: har tjänsten en ägare, en runbook, larm, säkerhetskrav. Det gör Cortex starkt för organisationer som vill driva upp kvaliteten systematiskt.

• Styrkor: stark på scorecards och att mäta efterlevnad, bra för att höja en spretig tjänsteflora till en standard.
• Avvägning: hanterad tjänst med licenskostnad, och tyngdpunkten på mätning passar bäst när ni redan har många tjänster att styra upp.

Head to head: hur jag väljer

Ärligt talat löser alla tre kärnproblemet att ge utvecklare en gemensam ingång. Skillnaden ligger i hur mycket du vill bygga själv och vad du betonar.

• Vill du ha full kontroll och har utvecklingsresurser lutar jag åt Backstage, med ögonen öppna för driftkostnaden.
• Vill du ha snabb tid till värde utan egen drift lutar jag åt Port.
• Vill du systematiskt höja tjänstemognad är Cortex det mest fokuserade valet.

Det jag varnar för är att bygga en stor plattform innan behovet finns. Hur jag knyter ihop en plattform med bygge, deploy och drift beskriver jag i min tjänst för DevOps-plattform, och är du osäker på var ni står kan min mognadsanalys ge en fingervisning.

Relaterat

• Docker best practices 2026: Multi-stage builds, rootless containers och SBOM
• CI/CD-pipelines i GitHub Actions: Mönster för Next.js, Python och Terraform
• Kubernetes för 5-personers team: När det är värt komplexiteten

Vill du se hur en intern plattform vuxit fram i ett skarpt projekt finns exempel i min casebook.

Vill du ta det vidare?

Om dina team uppfinner samma hjul om och om igen hjälper jag dig att välja och bygga en plattform de faktiskt vill använda, utan att överbygga. Hör av dig via kontaktsidan.