Lead Engineer at a consultancy with 51-200 employees
Real User
Top 10
Aug 28, 2026
One thing I have noticed about improving Upbound Crossplane is that, in Terraform, we can do a validation stage where people can say Terraform plan and see what changes it will do. It would be better if we had something in Upbound Crossplane as well. There is an option to render, I think 'crossplane render' or 'crossplane validate' will do similar to this, but it will just render the manifest, I would believe. It is not actually validating your current infrastructure with your desired infrastructure. If there is any system, something corresponding to 'crossplane plan' or, in a GitOps stage, if people push or create any new merge request, and if Upbound Crossplane can predict what it would do to the actual infrastructure, that would be really helpful.Regarding the needed improvements in Upbound Crossplane, I think the documentation part was pretty good even at the time when I was exploring a year back. It was very useful. Using that only, we tended to create a lot of compositions and these things. The community might have improved it much better, I believe. I haven't touched upon it recently. This was the only thing that we took as a disadvantage at the time of implementing, since we did not have any way to see what the Upbound Crossplane composition or what the Upbound Crossplane resource will do to the actual infrastructure. That is the only pain point we were seeing before.
Model Lead at a consultancy with 501-1,000 employees
Real User
Top 10
Jul 22, 2026
One area where Upbound Crossplane can be improved is with API rate limiting. For instance, if we frequently send some data to a specific API to poll the latest status of machines, it can result in exhaustion. While this isn't necessarily a fault of Upbound Crossplane, it relates to the cloud provider's side. If Upbound Crossplane retrieves the latest data, it might lead to delays or hit issues such as 429 too many requests, which should be addressed at the boundary layer if possible.
Principal Engineer at a tech vendor with 10,001+ employees
Real User
Top 10
Jun 18, 2026
Regarding Upbound Crossplane, I see room for enhancement in synchronizing the state file of Crossplane with Terraform, as 90% of organizations have generally implemented Terraform and have their own specific, environment-specific Terraform state files. If they are planning to integrate that with Crossplane, synchronizing both state files with respect to Crossplane and Terraform is one of the major challenges we are experiencing. Additionally, coding through GoLang and extending its capabilities as per our use cases is another challenge we are facing. The documentation for Upbound Crossplane is very good, and I believe no improvements are needed so far, except for the platform-level changes which I mentioned before.
I found an issue with features that was difficult for me when we needed to retrieve some tags or IDs of a resource that we deployed using Upbound Crossplane, for example, the RDS. We encountered a problem where we needed to use the ID of the RDS in another document that we have, making it difficult to return this information using Upbound Crossplane deployment. I believe Upbound Crossplane could be improved by possibly having a feature that can return tags, IDs, or resources that were deployed inside AWS, such as needing to return the ID of the VPC that we create when using Upbound Crossplane. I think the current state of Upbound Crossplane is already good enough.
Upbound Crossplane can be improved if they can add more AI agentic workflows. In the open source Upbound Crossplane, they can add more providers to support multiple providers, and for now, we are satisfied. I chose a rating of 9 out of 10 because Upbound Crossplane is a new tool and still it has a lot of improvements to be done. For example, fixes when it comes to databases is an area where things can be improved, alongside having good providers for supporting multiple databases which have the least performance issues.
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...
One thing I have noticed about improving Upbound Crossplane is that, in Terraform, we can do a validation stage where people can say Terraform plan and see what changes it will do. It would be better if we had something in Upbound Crossplane as well. There is an option to render, I think 'crossplane render' or 'crossplane validate' will do similar to this, but it will just render the manifest, I would believe. It is not actually validating your current infrastructure with your desired infrastructure. If there is any system, something corresponding to 'crossplane plan' or, in a GitOps stage, if people push or create any new merge request, and if Upbound Crossplane can predict what it would do to the actual infrastructure, that would be really helpful.Regarding the needed improvements in Upbound Crossplane, I think the documentation part was pretty good even at the time when I was exploring a year back. It was very useful. Using that only, we tended to create a lot of compositions and these things. The community might have improved it much better, I believe. I haven't touched upon it recently. This was the only thing that we took as a disadvantage at the time of implementing, since we did not have any way to see what the Upbound Crossplane composition or what the Upbound Crossplane resource will do to the actual infrastructure. That is the only pain point we were seeing before.
One area where Upbound Crossplane can be improved is with API rate limiting. For instance, if we frequently send some data to a specific API to poll the latest status of machines, it can result in exhaustion. While this isn't necessarily a fault of Upbound Crossplane, it relates to the cloud provider's side. If Upbound Crossplane retrieves the latest data, it might lead to delays or hit issues such as 429 too many requests, which should be addressed at the boundary layer if possible.
Regarding Upbound Crossplane, I see room for enhancement in synchronizing the state file of Crossplane with Terraform, as 90% of organizations have generally implemented Terraform and have their own specific, environment-specific Terraform state files. If they are planning to integrate that with Crossplane, synchronizing both state files with respect to Crossplane and Terraform is one of the major challenges we are experiencing. Additionally, coding through GoLang and extending its capabilities as per our use cases is another challenge we are facing. The documentation for Upbound Crossplane is very good, and I believe no improvements are needed so far, except for the platform-level changes which I mentioned before.
I found an issue with features that was difficult for me when we needed to retrieve some tags or IDs of a resource that we deployed using Upbound Crossplane, for example, the RDS. We encountered a problem where we needed to use the ID of the RDS in another document that we have, making it difficult to return this information using Upbound Crossplane deployment. I believe Upbound Crossplane could be improved by possibly having a feature that can return tags, IDs, or resources that were deployed inside AWS, such as needing to return the ID of the VPC that we create when using Upbound Crossplane. I think the current state of Upbound Crossplane is already good enough.
Upbound Crossplane can be improved if they can add more AI agentic workflows. In the open source Upbound Crossplane, they can add more providers to support multiple providers, and for now, we are satisfied. I chose a rating of 9 out of 10 because Upbound Crossplane is a new tool and still it has a lot of improvements to be done. For example, fixes when it comes to databases is an area where things can be improved, alongside having good providers for supporting multiple databases which have the least performance issues.