/
Cycloid vs Port
A Terraform apply runs cleanly through CI; no errors, no warnings, green across the board. Two engineers spin up a proof-of-concept cluster for a performance test, forget to tag it, and leave it running over a long weekend. Three weeks later, a $14,000 line item shows up in the cloud billing dashboard and nobody can immediately tell which team owns it, which workspace created it, or whether any approval was ever required.
vs
Written by
The Cycloid team
Platform engineering
Updated
October 2026
Read time
11 min read
Where should platform control sit?
When those incidents start repeating, platform teams open a shortlist. Port usually appears on it because the organisation can’t tell what infrastructure exists, who owns it, or whether it meets internal standards like required tags, defined on-call ownership, or passing security scans. Cycloid usually appears because infrastructure changes are executed without proper review, policy checks are informal at best, and the only thing standing between a developer and a production apply is a Slack message to the right person.
The procurement spreadsheet drops them in the same row because both have service catalogues and both have self-service workflows. Port organises knowledge about what exists: which services are running, which team owns them, whether they carry required metadata like on-call contact, deployment frequency, or SLA tier. Cycloid controls what executes: who can run a Terraform plan, whether that change passes policy before it touches a cloud provider, and whether it needs an approval before it runs. Conflating the two is roughly like comparing a circuit breaker to a wiring diagram. Both matter; neither does what the other does. And buying the wrong one doesn’t fix the original problem, it just gives you something polished to demo while the actual failure keeps recurring.
What follows works through both products at the layer where it counts: execution, governance, state ownership, and what the platform actually controls once compliance enters the picture.
Cycloid was built for the first camp. Forms, four-layer authorisation and approvals run before anything changes, and the run itself goes through the Native Runner or the CI you already have, reporting back to one control plane. Its software catalogue sits on the same record.
However, Port was built for the second camp. It centralizes knowledge about software and infrastructure assets into a catalogue that updates in real time via integrations, then lets teams build scorecards, dashboards, and self-service workflows on top of that data.
Neither tool replaces the other. The question is which problem you’re paying for right now.
The core trade-off
Port
Platform teams usually surface this question after a specific incident rather than as a strategic exercise. A Terraform workspace applies a change that nobody reviewed. A proof-of-concept environment stays running for six months because the engineer who created it left and ownership was never recorded. A staging config diverges from production, and nobody finds out until something breaks on the wrong side.
The single platform
At that point, teams tend to split into two camps. The first camp’s problem is that infrastructure changes are escaping any meaningful review. The second camp’s problem is that nobody can tell what exists, who owns it, or whether it meets internal standards. Both camps may eventually need both tools. But the purchase decisions, the onboarding effort, and the org-level change required are completely different, and conflating the two wastes time.
Decision matrix
Feature comparison: Cycloid vs Port
This comparison is written for platform engineers and DevOps leads making a concrete decision. The focus is on where enforcement happens, what the platform actually owns, and what you still have to build or wire together yourself.
01
Deployment, architecture and data boundaries
Cycloid offers three deployment options: shared SaaS, a dedicated managed instance, or fully self-hosted inside a customer’s private network, including environments with no outbound internet access. The reason that flexibility matters is specific: when Cycloid runs a Terraform or OpenTofu plan or apply, it handles AWS access keys, GCP service account credentials, Azure service principals, and the state those runs read and write. Approval records, execution logs, and policy evaluation results all live inside the platform’s runtime. For financial institutions, defense contractors, or any organisation under data sovereignty regulation, those artifacts can’t touch infrastructure outside a defined perimeter. The self-hosted option puts the entire control plane, credentials, state, and logs, inside the customer’s own network.
Port‘s deployment story starts from a different premise. Because Port doesn’t execute infrastructure changes or run Terraform directly, it never holds cloud provider credentials in the first place. What Port ingests is metadata: Kubernetes resource definitions, GitHub repository details, PagerDuty service ownership records, Datadog monitor states, CI/CD pipeline run results. Ocean integrations, Port’s data-syncing layer, can run as agents inside a customer’s network to pull that metadata without exposing internal systems, while the catalogue and portal themselves remain on Port’s cloud infrastructure. Enterprise customers can request Private Link connectivity or discuss dedicated tenancy, but the runtime stays SaaS.
The practical boundary here is what each platform touches. A regulated team running Cycloid self-hosted keeps every credential, every state file, and every approval record inside their own perimeter. A team running Port keeps only catalogue metadata in Port’s cloud: service names, ownership records, scorecard results, and integration-sourced properties. Neither model is wrong. The question is whether your compliance requirements extend to IaC execution and credential handling, or only to the organisational metadata layer.
Takeaway: Cycloid is the right fit when deployment and hosting requirements extend to IaC execution, credential handling and policy enforcement sitting inside a controlled network. Port fits when the requirement is a SaaS developer portal that surfaces organisational knowledge without owning the infrastructure execution path.
FEATURE
PORT
Deployment models
Shared SaaS, dedicated managed instance, or fully self-hosted including air-gapped and fully isolated private networks
SaaS only; enterprise customers can request dedicated tenancy and Private Link connectivity
Data residency control
Full control when self-hosted; state files, execution logs, credentials, and approval records stay entirely within customer-controlled infrastructure
Data stored in customer-dedicated databases on AWS; Ocean agents can run inside the customer’s network, but the portal and catalogue runtime remain on Port’s cloud
Platform runtime ownership
Customer or Cycloid manages the full control plane depending on the chosen deployment model
Port operates the AWS-hosted runtime; customers control configuration but have no access to the underlying infrastructure
Infra credentials handling
AWS access keys, GCP service accounts and Azure service principals are stored and scoped in the platform and used at run time
Port does not store customer credentials; all cloud access happens in systems external to Port
Regulated environment fit
Suitable where IaC execution, credential handling, policy enforcement, and state storage must remain inside a private or isolated network
Suitable where compliance requirements apply to catalogue metadata and organisational data, but not to IaC execution or cloud credential handling
02
Infrastructure delivery and state management
This is where the products stop overlapping. Platform engineers publish Blueprints: a template, a Form and the actions that create and change a resource. Developers request against them, Cycloid checks the request, and the run happens on the Native Runner or your CI. Terraform and OpenTofu state is read to inventory what’s managed and show IaC coverage.
Port doesn’t run infrastructure; it ingests data from the tools that do. Using its Ocean integration framework or direct API connections, Port can pull Terraform state data, Kubernetes resource data, AWS/GCP/Azure resource metadata, CI/CD run results, and dozens of other sources into its software catalogue. Catalogue entries update in real time, and you can build dashboards and scorecards on top of that data. But Port has no concept of a Terraform workspace it owns, no mechanism to trigger a plan, and no mechanism to block an apply. Those responsibilities live in whatever CI/CD or IaC tooling already exists.
Takeaway: Cycloid owns the delivery path and uses that ownership to check every request before it runs. Port ingests data from the tools that do those things and makes it queryable, but it doesn’t own any of it.
FEATURE
PORT
IaC execution
Runs Terraform and OpenTofu, Ansible and Helm on the Native Runner, or triggers your CI
Does not execute IaC; surfaces data from external IaC tools via integrations
Terraform state
Reads Terraform and OpenTofu state to inventory what’s managed and show IaC coverage
Can ingest state data via integrations but does not own or manage state
Environment lifecycle
Creates, updates and decommissions environments through Blueprint actions
Environment lifecycle handled entirely in external CI/CD and IaC systems
Infrastructure topology
Relationship graph of resources and services per environment
Catalogue shows resource metadata and relationships based on ingested data
03
Self-service and the developer interaction model
Both platforms offer self-service, but the underlying model differs significantly.
Cycloid’s developer self-service runs through Forms: inputs that present developers with a constrained set of options, region, instance type, environment tier and so on, all bounded by what the platform team has allowed. A developer filling out a Form isn’t writing Terraform or modifying a module; they’re selecting from approved values that feed the Blueprint’s create action. The platform validates inputs, runs the authorisation checks, triggers any approval, and runs the change. Governance isn’t something a developer can opt out of by choosing a different input.
Port‘s self-service is designed differently i.e., platform engineers define self-service actions tied to blueprints, the core modeling unit in Port. An action can trigger a webhook, a GitHub Actions workflow, a Jenkins pipeline, or any external automation. Port handles the form input, the optional manual approval, and the audit event. The actual work happens outside Port, in whatever CI or IaC system the action points to. This means Port’s self-service is as strong as the external system it’s calling. If that system lacks its own guardrails, Port doesn’t add them.
Cycloid’s tighter coupling gives you more control over what executes. Port’s loose coupling gives you more flexibility to plug into an existing toolchain without displacing it.
Takeaway: Cycloid reduces ticket load by standardising how infrastructure is requested and what it can produce. Port reduces cognitive load by centralising where actions live, while leaving execution to systems the platform team already manages.
FEATURE
PORT
Self-service mechanism
Forms with bounded inputs feeding Blueprint actions; governance built into the workflow
Action forms triggering external automations via webhooks, GitHub Actions, Jenkins, etc.
Guardrails on inputs
Input options predefined by platform team; invalid combinations blocked before execution
Input validation at the form level; enforcement depends on what the external automation implements
Approval flow
Built-in approval steps before the run (Enterprise)
Manual approval toggles configurable per action; approval notification via email, Slack webhook, or API
What happens if policy fails
The request is refused before anything runs
Depends on what the triggered external system does when it receives the payload
Execution coupling
Tightly coupled; platform owns the execution path
Loosely coupled; platform delegates execution to external tools
04
Access control, governance and auditability
Both platforms have RBAC, and both have audit logs, but they govern different things.
Cycloid checks every action through four layers: what you can see, your role (Admin, Lead, Member or Viewer), conditions on the request, and approval where it’s needed. When a request is refused, it’s refused at the platform level regardless of whether the underlying Git repository would have allowed it or whether the CI pipeline was configured loosely, and the refusal is logged too.
Port‘s RBAC controls who can view, create, or modify catalogue entities and who can invoke self-service actions. Permissions can be set by role (admin, moderator, member), by team membership, or by dynamic rules using JQ expressions against catalogue data. For example, you can write a policy that allows only the on-call engineer to trigger a rollback action on a given service. Port also maintains an audit log that records every catalogue modification, action invocation, and automated event, including which user or service account triggered it.
The distinction is about where enforcement actually bites. Port’s RBAC stops unauthorized users from invoking actions through Port. It doesn’t stop those same users from triggering the same pipeline directly from their CI system, pushing to the Git repository, or running Terraform from their laptop. Cycloid’s enforcement runs in the delivery path itself, so bypassing it requires bypassing the platform.
Takeaway: Cycloid enforces governance before changes reach production. Port describes compliance through scorecards and ownership that must already be enforced in the systems Port integrates with.
FEATURE
PORT
RBAC scope
Predefined roles scoped to teams, Resource Groups and environments, controlling who can request, approve or run. Enforced at the platform, not just the portal
Catalogue and action level; admin, moderator, and member roles control who can view or edit entities and invoke actions. Dynamic permissions via JQ expressions allow context-aware access, for example, restricting production deployments to senior engineers only
Policy enforcement
Form validation and conditions refuse non-compliant requests before the run, regardless of what the Git repository or CI pipeline permits
Port automations use JQ-based condition rules to enforce policies on action runs: blocking deployments with critical vulnerabilities detected by scanners like Trivy or Wiz, auto-approving low-risk requests, and escalating high-risk ones. This policy logic runs inside Port but acts on Port-managed action runs, not directly on Terraform or IaC execution
Approval workflows
Native approval steps per Blueprint action and environment; nothing runs until required approvers act
Per-action requiredApproval field set to ANY (any one approver sufficient) or ALL (every designated approver must act). When an action is triggered, it enters WAITING_FOR_APPROVAL status and sends an email notification to approvers. Approvers act from the Port UI or via API. Slack notifications require a separate automation
Audit logging
One record of the request, approver, checks, refusals and the change produced, tied to the resource and environment
Port maintains an audit log of every catalogue change, action invocation, approval decision, and automation trigger, including the user or service account that initiated each event. Execution logs from the downstream CI/CD or IaC system remain outside Port
Compliance posture
Non-compliant infrastructure changes are blocked before they execute, because Cycloid owns the execution path. A failed check stops the run regardless of what any upstream system would have permitted
Compliance is tracked through scorecards measuring criteria like branch protection, IAM hygiene, dependency management, and encryption standards. Policies run on Port-managed action runs. Compliance enforcement on raw IaC execution requires the downstream CI/CD system to carry it
05
Data model and catalogue flexibility
Port’s blueprints are entity types: you can model anything, a microservice, an environment, a cluster, a team, with properties, relations and mirror properties. That flexibility suits teams cataloguing many asset types across engineering, security and SRE.
Cycloid’s Blueprints do more than describe. Each one is a template, a Form and the actions that create and change a resource, and what it creates lands in the software catalogue with its owner, relationships and scorecard level. Tracked Blueprints and the asset inventory bring in what wasn’t created through Cycloid.
Teams that mainly need a flexible metadata model will find Port’s approach familiar. Teams that want the catalogue and the governed change on the same record will find that in Cycloid.
If the information above is inaccurate or outdated, please contact us at marketing@cycloid.io and we’ll set it right straight away!
How to decide
Cycloid or Port:
how to choose the right platform for your team
Platform teams pick the right tool for the wrong problem, deploy it, present it at a team meeting, and then wonder six months later why the original incidents are still happening.
If your recurring incidents trace back to the execution path, unreviewed plans, stages that differ in ways nobody can explain, or approvals that happen in a Slack thread, you need a platform that sits in that path.
If your friction is knowing what exists and who owns it, both products catalogue it. The difference is what happens next: in Port you build an action that calls another system; in Cycloid, the Blueprint that listed the resource is the one that changes it.
