Lead Engineer at a consultancy with 51-200 employees
Real User
Top 10
Aug 28, 2026
Our main use case for Upbound Crossplane is that we are using Kubernetes as our main platform, and we have multiple clients who will be using this Kubernetes platform for deploying their container service. Initially we were using Terraform for the infrastructure side, but since we have the application dependency and infrastructure dependency separately, most of the developers have to push their develop containers through Argo CD. For the infrastructure, they need to depend upon a separate pipeline for their Terraform deployment. We want to give the developers the ability to deploy both the containers and the infrastructures through the same GitOps way, through Argo CD. That is why we planned to have Upbound Crossplane in it.A specific example of how we used Upbound Crossplane in that setup is when an application has a dependency on DynamoDB and an IAM role. Previously without Upbound Crossplane, our workflow looked the following way: developers would have the containers in a GitOps way in a GitOps repository, and it would deploy the containers. Then there would be a separate repository and pipeline where they have to have their own Terraform code to deploy this DynamoDB and IAM. That was two separate pipelines they needed to take care of. Now, what we are doing is in the same container repository, along with their development code, they will have this Upbound Crossplane custom resources where they can directly invoke the AWS provider by creating this DynamoDB and IAM. Using this one, they will have everything in a centralized GitOps way. Even if they want to change something on the IAM, they can simply tweak it on their GitOps repository and that will actually do the change on the infrastructure side. In addition to our main use case, we were creating a few Compositions in Upbound Crossplane as well. It was similar to the modules in Terraform. In Terraform, we tend to create more complex modules, which means combining Dynamo, S3, and IAM as a single one. Similarly, in Upbound Crossplane, we did some Compositions where the developers just have to mention the DynamoDB name, S3 name, and IAM name. Behind the scenes, it will correlate all the resources and it will do the connections between them using this composition as a module. That would actually create a final resource and give it as an output to their containers.
Model Lead at a consultancy with 501-1,000 employees
Real User
Top 10
Jul 22, 2026
Upbound Crossplane connects the cloud APIs on cloud providers like GCP, AWS, and Azure. We need to maintain the network resources and the VM containers, and the VM instance that Upbound Crossplane provides ensures the constancy and self-healing of that part. It is very useful for our use case to provision the infrastructure and create the network resources and cloud resources. In my day-to-day work, we have a use case that I cannot disclose in detail, but in general terms, it is like this: let's suppose you want to create the VMs that will be called the edge nodes, which can offload the traffic from the edge devices to our control plane. It does this by having three or maybe four providers that we can attach to Upbound Crossplane, and it will instantly boot up the VMs. We are using temporals that will onboard the VMs and then install the software on them. The core part of Upbound Crossplane is that previously we were using Terraform, which had state lock issues, and all of that got solved when we moved to Upbound Crossplane, which keeps all state in etcd and also has auto-healing and self-reconciliation. If something happens to that particular instance, it will auto-reconcile it, and that is the main benefit of Upbound Crossplane. My main use case for Upbound Crossplane is about connecting the public cloud providers; we even have some private providers that we can attach to it, and there is consistency we can achieve. There is the same call; we don't need to care about the cloud part because it will be automatically handled on Upbound Crossplane's side. The resources can be managed within this tool; we don't need to manually hit or create the instances or other network-related services on the cloud. We can utilize everything on Upbound Crossplane itself; it is fully managed.
Principal Engineer at a tech vendor with 10,001+ employees
Real User
Top 10
Jun 18, 2026
Our main use case for Upbound Crossplane at Carbon International involves maintaining our Kubernetes environments, which is entirely run using Terraform in the background. We considered using Crossplane along with Terraform to have all Kubernetes objects up to date, and we are still in the POC phase and have yet to bring it to production. There are a couple of surprises regarding the integration between Crossplane and Terraform. Managing the state files of Terraform and Crossplane is challenging because if both are working on the same platform component, synchronizing between the two state files is risky at this time. However, if we focus Crossplane towards one Kubernetes platform and Terraform towards another platform, we believe that would solve this issue, and my team and I are still investigating this approach. We are still exploring how we can utilize Crossplane to manage our infrastructure completely. We are trying to replace Terraform with Crossplane, but we are still in the POC and R&D phase.
My main use case for Upbound Crossplane is that initially we were frustrated with using Terraform, and right now all the infrastructure provisioning and infrastructure automation we are doing is through Crossplane. A specific example of how I'm using Upbound Crossplane for infrastructure provisioning and automation is that currently, for our platform, we have a cloud native GenAI platform, and for that platform, we have to provision various services in three hyperscalers: AWS, Azure, and GCP Cloud, so across all three major cloud platforms, we have to provision our resources using Upbound Crossplane and it is easy to manage them.
Upbound Crossplane is a powerful open-source tool for infrastructure management, offering a universal control plane that helps automate provisioning and governance across multiple cloud providers.Upbound Crossplane enables organizations to transform how they manage infrastructure by providing an API-driven platform that simplifies the creation and management of cloud infrastructure abstractions. It allows teams to build bespoke infrastructure APIs and manage cloud resources using...
Our main use case for Upbound Crossplane is that we are using Kubernetes as our main platform, and we have multiple clients who will be using this Kubernetes platform for deploying their container service. Initially we were using Terraform for the infrastructure side, but since we have the application dependency and infrastructure dependency separately, most of the developers have to push their develop containers through Argo CD. For the infrastructure, they need to depend upon a separate pipeline for their Terraform deployment. We want to give the developers the ability to deploy both the containers and the infrastructures through the same GitOps way, through Argo CD. That is why we planned to have Upbound Crossplane in it.A specific example of how we used Upbound Crossplane in that setup is when an application has a dependency on DynamoDB and an IAM role. Previously without Upbound Crossplane, our workflow looked the following way: developers would have the containers in a GitOps way in a GitOps repository, and it would deploy the containers. Then there would be a separate repository and pipeline where they have to have their own Terraform code to deploy this DynamoDB and IAM. That was two separate pipelines they needed to take care of. Now, what we are doing is in the same container repository, along with their development code, they will have this Upbound Crossplane custom resources where they can directly invoke the AWS provider by creating this DynamoDB and IAM. Using this one, they will have everything in a centralized GitOps way. Even if they want to change something on the IAM, they can simply tweak it on their GitOps repository and that will actually do the change on the infrastructure side. In addition to our main use case, we were creating a few Compositions in Upbound Crossplane as well. It was similar to the modules in Terraform. In Terraform, we tend to create more complex modules, which means combining Dynamo, S3, and IAM as a single one. Similarly, in Upbound Crossplane, we did some Compositions where the developers just have to mention the DynamoDB name, S3 name, and IAM name. Behind the scenes, it will correlate all the resources and it will do the connections between them using this composition as a module. That would actually create a final resource and give it as an output to their containers.
Upbound Crossplane connects the cloud APIs on cloud providers like GCP, AWS, and Azure. We need to maintain the network resources and the VM containers, and the VM instance that Upbound Crossplane provides ensures the constancy and self-healing of that part. It is very useful for our use case to provision the infrastructure and create the network resources and cloud resources. In my day-to-day work, we have a use case that I cannot disclose in detail, but in general terms, it is like this: let's suppose you want to create the VMs that will be called the edge nodes, which can offload the traffic from the edge devices to our control plane. It does this by having three or maybe four providers that we can attach to Upbound Crossplane, and it will instantly boot up the VMs. We are using temporals that will onboard the VMs and then install the software on them. The core part of Upbound Crossplane is that previously we were using Terraform, which had state lock issues, and all of that got solved when we moved to Upbound Crossplane, which keeps all state in etcd and also has auto-healing and self-reconciliation. If something happens to that particular instance, it will auto-reconcile it, and that is the main benefit of Upbound Crossplane. My main use case for Upbound Crossplane is about connecting the public cloud providers; we even have some private providers that we can attach to it, and there is consistency we can achieve. There is the same call; we don't need to care about the cloud part because it will be automatically handled on Upbound Crossplane's side. The resources can be managed within this tool; we don't need to manually hit or create the instances or other network-related services on the cloud. We can utilize everything on Upbound Crossplane itself; it is fully managed.
Our main use case for Upbound Crossplane at Carbon International involves maintaining our Kubernetes environments, which is entirely run using Terraform in the background. We considered using Crossplane along with Terraform to have all Kubernetes objects up to date, and we are still in the POC phase and have yet to bring it to production. There are a couple of surprises regarding the integration between Crossplane and Terraform. Managing the state files of Terraform and Crossplane is challenging because if both are working on the same platform component, synchronizing between the two state files is risky at this time. However, if we focus Crossplane towards one Kubernetes platform and Terraform towards another platform, we believe that would solve this issue, and my team and I are still investigating this approach. We are still exploring how we can utilize Crossplane to manage our infrastructure completely. We are trying to replace Terraform with Crossplane, but we are still in the POC and R&D phase.
My main use case for Upbound Crossplane is automating our back-end deployment.
My main use case for Upbound Crossplane is that initially we were frustrated with using Terraform, and right now all the infrastructure provisioning and infrastructure automation we are doing is through Crossplane. A specific example of how I'm using Upbound Crossplane for infrastructure provisioning and automation is that currently, for our platform, we have a cloud native GenAI platform, and for that platform, we have to provision various services in three hyperscalers: AWS, Azure, and GCP Cloud, so across all three major cloud platforms, we have to provision our resources using Upbound Crossplane and it is easy to manage them.