Internal developer portal vs platform
Portal or platform? Better together.
Portals display. Cycloid does. Your platform team delivers the portal your teams need without starting from scratch, and developers get the catalogue and the governed paths to act on it, in one place.
Trusted by
The portal-only problem
A portal on top of manual work is still manual work
Most teams start with a portal. It tells a developer who owns a service, where it runs and what it depends on. Then they need a new environment, and the portal hands them a ticket form. A ticket filed through a portal isn’t self-service. It’s an automated order.
Portal alone
What it is
The front end developers look at
What’s in it
The catalogue, owners, dependency graph, scorecards
Who it serves
Developers finding things
Governance
Shows who owns what
Where it stops
At the ticket form
+
Platform alone
What it is
The automation and rules behind it
What’s in it
Blueprints, Forms, runners, promotion, day-2 actions
Who it serves
Platform teams building paths
Governance
Enforces rules at run time
Where it stops
At a pipeline only the platform team can find
=
What it is
Both, on one record
What’s in it
Both, with the action next to the view
Who it serves
Both, plus executives watching adoption and audit
Governance
Four-layer authorisation before anything’s created, logged either way
Where it stops
Inside the guardrails you set
Who gets what
Who gets what from portal and platform
Same record, three reasons to care.
Build the platform, not the glue
The problem
You run a portal, a pile of scripts behind it, and you maintain both.
With Cycloid
Publish Blueprints, set environment types, naming rules and approvals once. Run it on the Native Runner or the CI you already have.
The outcome
You set the guardrails. Your team won’t have less work. It’ll have better work.
See it, then do it
The problem
You see your app. You often can’t see what it runs on, and changing it means a ticket.
With Cycloid
Pick a golden path or a Form, deploy, then promote and run day-2 actions from the same page.
The outcome
No ticket queue on structured paths. Approvals only where risk calls for them.
One place to see if it's working
The problem
Two tools to fund, and still no single view of adoption or compliance.
With Cycloid
One platform with adoption analytics, dashboards and an audit log. SaaS, self-hosted or air-gapped.
The outcome
Adoption you can measure, and checks that run before the deploy.
How it works
From catalogue to production, on one record
1Catalogue and golden paths
The catalogue lists services, landing zones and environments, each with an owner. Next to each sits the Blueprint that builds it, versioned and published by your platform team, with Git sync if you want it.
2Forms that check before they create
Your platform team picks the questions. The form asks them. A Form turns a Blueprint’s inputs into dropdowns, conditional fields and pickers fed from the asset inventory. Every submission is validated, and a non-compliant request is refused before the resource exists. Run GitOps? The Git plugin commits the generated files to your repo.
3Native Runner, or your CI
Runs go through the Native Runner under your control, or the CI you already have. Developers follow status and logs from the portal, and failed steps can be retried, and you recover by rolling forward with a new deployment.
4Guardrails and audit
Four-layer authorisation checks every action, whether a person or an assistant takes it. Environment types and naming rules apply at creation, approvals kick in where risk or ownership calls for them, and the audit log records every yes and every no. Guardrails first. A human only where a human adds something.
5Promote and run
Promotion paths move builds from dev to QA, staging and prod under your rules, including a scorecard gate such as Silver or above. Day-2 actions sit in the Blueprint, next to the deploy, and show on the resource page.
A portal on its own tells you what’s there. A platform on its own runs things nobody can see. Cycloid keeps both on one record, so the page that shows a service is the page you change it from, and every change passes the same checks, human or assistant.
Which do you need first?
Most teams don't need a portal first. They need it to run something.
The portal isn’t the hard part. The paths behind it are. The 2025 DORA report found that 90% of organisations have adopted at least one platform, and linked high-quality platforms to getting value from AI. So start from the friction your developers actually have, the environment that takes a week or the change that needs three people, and build the Blueprint for that first. The catalogue fills itself as those paths go live, because what you deploy through Cycloid is listed with its team. Already running Backstage? The two can sit side by side while you compare, and your IaC modules and CI stay where they are.
What teams deliver
Portal and platform in one, in production
B Corp Certified
ISO 27001 Certified
COOL VENDOR 2024
Cool Vendor 2024
HYPE CYCLE 2026
For Platform Engineering
Working with your assistant
Ask what's there, then act on it
Ask your assistant who owns a service and what it depends on, then ask for a staging copy. The answer comes from the catalogue, and the request comes back as the same Form the portal uses, naming rules included.
Nothing consequential runs until you confirm. The audit log records the assistant session and the person it acted for.
Does the assistant get its own permissions?
No. There’s no service account and no elevated assistant role. If you can’t deploy to production, neither can the assistant you’re talking to, in Cycloid’s own assistant or any compliant MCP host.
Who owns orders-api? Then spin up a staging copy.
Team Orders owns it. Here’s the form.
Form · orders-api, Blueprint v3.1
Environment type
staging
Name
orders-api-stg
Naming rule
Passed
Frequently asked questions
What's the difference between an internal developer portal and platform?
A portal is the front end: the catalogue, owners, docs and scorecards developers look at. A platform is what runs behind it: provisioning, pipelines and policy. Cycloid gives you both on one record, so you can act on what you see.
Do I need both a portal and a platform?
If developers can see a service but still file a ticket to change it, yes. A portal alone moves the queue. With both, structured requests run self-service, and approvals apply only where risk calls for them.
Can we keep our existing CI and Git workflows?
Yes. Cycloid wraps the IaC and CI you already have. It doesn’t replace them. Runs go through the Native Runner under your control or your own CI, and Git is optional: sync Blueprints from a repo, or commit Form output if you run GitOps.
We already run Backstage. Do we have to choose?
No. Backstage gives you a framework, and everything on top is yours to build and maintain. Cycloid gives you the catalogue and the platform behind it as product. The two can sit side by side while you compare.
The whole picture
Three pillars, one platform
Everything Cycloid does sits in one of three places. Start with the one slowing you down.
Pillar 01
Self-service that doesn’t stop at deploy: run, promote and compose in one portal.
Bring the request that's always in the queue
Book 20 minutes. We’ll show you the portal and the platform on one record, working on a request like yours.