Upbound Crossplane Reviews

My main use case for Upbound Crossplane is automating our back-end deployment.

I believe the best features Upbound Crossplane offers are the documentation, which is easy to understand, and the way Upbound Crossplane uses providers to deploy the entire infrastructure we need.

The documentation helps me in my workflow because it is clear regarding what we need to do and what variables and features we can add during the creation of the Helm templates that we use to deploy. Upbound Crossplane provider integration makes things easier for us because it uses simple YAML to deploy, allowing us to deploy the entire provider easily.

Upbound Crossplane has positively impacted our organization by allowing us to reduce our deployment time from three days to three hours for the entire back-end and entire infrastructure.

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.

I have been using Upbound Crossplane for about one year.

I find Upbound Crossplane to be stable.

I think Upbound Crossplane's scalability is good enough.

I did not use the customer support, as I do everything by myself.

I did not previously use a different solution. The solution was manual, and we deployed everything manually before changing to Upbound Crossplane.

We did not buy Upbound Crossplane through the AWS Marketplace. We use the free versions.

I did not evaluate other options beforehand because the platform decided we must use Upbound Crossplane.

I have not seen any return on investment apart from the time savings I already mentioned.

We did not use the paid version, only the free version, so I do not have experience with pricing, setup cost, and licensing.

I rate Upbound Crossplane a 10 on a scale of 1 to 10. I choose 10 because it is easy to work with. Regarding Upbound Crossplane's AI capabilities, I do not know much because I did not use it with AI. I did not use the AI features, so I cannot comment on its accuracy and reliability of output. My advice for others looking into using Upbound Crossplane is to read the documentation, as it is simple and easy to understand. My overall review rating for Upbound Crossplane is 10.

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 has impacted our organization positively as it has been a transformative experience because the main thing about transformation is how we were able to make our lives easier as engineers. For example, if I have to deploy something or set up some infrastructure resources within a bunch of minutes, I can do that because now I have end-to-end automation enabled with Upbound Crossplane.

Since switching to Upbound Crossplane, we now have a 60% reduction in errors, which is something I really appreciate about this.

The best features Upbound Crossplane offers include that we have templating all the resources, which is called XCRDs and these are easy to manage. When the resource is created in the Kubernetes cluster itself, it is quite easy to manage through that, and we don't have to track everything on the cloud platform. Everything is in our Git repo which is there as infrastructure as code, wherein our Helm templating is there and Go templating is there, which helps us to create automation for Upbound Crossplane. We have separate clusters for Upbound Crossplane.

XCRDs and templating have made my workflow easier and more efficient because Upbound Crossplane is a great product to replace Terraform. In our case, we had a lot of drift scenarios with Terraform and it was difficult to manage because in our organization we also have our own native solutions. Those providers are something that helps us automate and set up end-to-end automation for provisioning, whether it is any kind of resource, whether it is a secret or secret replications across different cloud providers.

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.

I have been using Upbound Crossplane for the last three years since it was launched.

In my experience, Upbound Crossplane is stable. However, there are custom providers that we use. Every organization can also create their own custom providers, and if they have to create them, then they have to maintain them well. If they are not maintained well, then it will not be stable. At this moment, Upbound Crossplane is stable for us.

Upbound Crossplane's scalability is good. At this moment, we did not face any scalability issues because scalability also depends on how you set up the underlying infrastructure.

I previously used Terraform, but Terraform native was creating a lot of drift errors and inconsistency because the engineers were not maintaining it properly. That drift was something which was not working for us, so that is where we moved to Upbound Crossplane.

Integrating Upbound Crossplane with our existing systems and workflows was initially difficult because this tool was new to the market just two to three years ago. However, now that we have completed the setup, it is going very with integrating all the providers because the best thing is that Upbound Crossplane provides inbuilt providers which are available in open source and those are reusable. We don't have to do anything from scratch, and there are a lot of providers available that can be utilized for our work environment. This existing workflow really helped.

Upbound Crossplane handles security and compliance requirements in our organization by having our own layer of security which is our native solution. In Upbound Crossplane, our secrets are stored in separate clusters which are being replicated. When secrets are replicated, they are encrypted at rest, and we use additional tools to safeguard. We have all the necessary native guardrails as per our organization and compliance.

Upbound Crossplane integrates with our CI/CD pipelines and DevOps processes by having end-to-end deployment because we are using GitHub Actions to integrate with all the workflows that we have. For example, if there is any provisioning of a resource, an end user or a development engineer just has to run that pipeline to actually do the provisioning and do the needful. We have around 50 plus data centers, which means 50 plus environments across the globe in different regions, and we have been managing all of them through GitHub Actions.

Right now, we haven't set up monitoring because we have just completed the setup. The observability part is something that we are currently working on. We are going to have a stack of VictoriaMetrics, Grafana, and OpenTelemetry solutions for monitoring, and we are still working toward achieving this.

I have seen a return on investment as we are saving a lot of time because with one CI/CD setup, we can deploy claims in multiple environments.

The documentation and learning curve for Upbound Crossplane were really smooth initially to set up. However, our use cases were complex, so to solve our use cases, we had to first learn the basics. The basic documentation is very clear in the official documentation, which really helps.

Before choosing Upbound Crossplane, we did not evaluate other options. It was something which was launched new and we had a good interest in it only because it creates a number of XCRDs and then the components that we create and claims that we deploy. We really liked the process of Upbound Crossplane.

My advice to others looking into using Upbound Crossplane is that this is definitely a transforming tool if you are looking for a next-gen infrastructure solution. At the same time, for people who don't know Kubernetes in depth and who don't have much cloud native knowledge, it can be a bit difficult to start. I would say that people should first have in-depth knowledge of cloud native toolsets and then they should start using Upbound Crossplane. I have rated this product a 9 out of 10.

My main use case for Upbound Crossplane is building layers for infrastructure platforms. I used it as a replacement for Terraform while working in an open-source project called Open Source Management and Network Orchestration by ETSI. I used it to create control planes for creating infrastructure for network workloads, specifically Telco network workloads. These include EKS clusters, workflows, and image building workflows, among other things. Mostly I work with the AWS provider, Google Cloud provider, and Microsoft Azure provider. I also built a platform layer on top of my existing toolset.

I have used Upbound Crossplane in my current organization, specifically with one of the teams. I used it to build platform layers. We had an internal developer portal, and I built a layer for the monitoring stack. It involved creating clusters to deploy Grafana, Prometheus, EFK stack, and various other tools that we continued adding. We migrated to Thanos and then Loki, and I kept adding these to the infrastructure layer while maturing the platform. Ultimately, what I provided to the developers was a monitoring API, which they called in a certain way. Actually, it was a file that they needed to push to a certain repository called Obstack. It would then trigger based on the guardrails that I had defined. I was continuing to work on the infrastructure layer, adding new tools, but the interface layer always remained the same, which was a great way to mature our platform.

A specific example of a project where I used Crossplane as a replacement for Terraform is when we had a user request a 5G network deployment. We first created the infrastructure for the workload, which could be an EKS cluster along with many things required for a 5G deployment to work. From an EKS cluster to VPC subnetting and deploying the workloads, we called it the all batteries included version of an EKS cluster. It has many network components which are required for any 5G network to work. The example use case was Free 5G Core at that time from Orange Networks. I used Upbound Crossplane to create all that infrastructure, and the benefit it gave me was the active reconciliation feature compared to Terraform because it works on a Kubernetes kind of desired state and active state approach. It will definitely monitor the infrastructure that I asked it to create and then reconcile it without me interfering, unlike Terraform, which is a fire and forget approach and will not try to monitor the infrastructure created by it. It is just basic simple API calls.

The best features of Upbound Crossplane are the analogy it brings regarding separation of concerns. As a platform team member, I can continue to work on the infrastructure layer while developers can continue to work on interacting with the APIs and getting their infrastructure done, so they could work on feature development. This kind of separation, which was always desired in a DevOps team but never truly achieved, is something I find unique to Upbound Crossplane. There are many other benefits, including the active reconciliation I mentioned. There are so many advantages regarding the data language. It always works in YAML, which I find very to the point, accurate, and very concise. It is a management headache sometimes, but there are also tools to help me manage that. I find it is better than some of the templating tools that we have, such as Helm.

Using YAML with Upbound Crossplane compared to other tools in terms of my workflow and collaboration with developers feels very comfortable for me because I see what I get. With YAML, I am basically providing any system data and then expecting a result out of it. It is very to the point and I appreciate it, but obviously developers dislike it. I sometimes use templating tools and some UI forms for developers to interact with the tools that I use, which are internally driven by YAML. For me personally, I do not see YAML as anything negative. It has always been that I appreciate it whenever a tool works on YAML. I do not need to learn any domain-specific or tool-specific knowledge.

I feel that Upbound Crossplane can be improved in terms of the providers. Back when I was using it, there were some providers which did not have a certain schema, but obviously, that is something which will always come with how the tool is maturing and how it is being adopted. There will always be the use case of taking up the code base from other tools itself. If I were to develop a provider for Terraform for Upbound Crossplane, I think there is a way to do it via the Terraform provider. If there is a Terraform provider for anything, I can develop an Upbound Crossplane provider. All those things, YAML management and schema management, I felt was a little bit more tricky when I wanted to test it from the Upbound CLI or the Crossplane CLI. It was a little bit tricky and can be improved to encourage more developers to start contributing to the provider development in Upbound Crossplane.

Regarding Upbound Crossplane's capabilities, I feel the governance and security is something which is lacking. At that time, I did not see anything related to security apart from linting. I could not find anything in the CLI itself. This is something we need to look into, and I felt that when we talk about the security of the provider, that is also something we can look into regarding checking the source code itself if there could be a way to do that. Although I find it is good because you can package your composition and check the vulnerability in your composition using any tool that you use for Docker image scanning. There could still be some additions to the CLI itself to make people look more into security from their terminal itself.

I first used open-source Crossplane back in 2022.

Upbound Crossplane is stable.

Upbound Crossplane's scalability is quite impressive. It is just another tool in the Kubernetes ecosystem. It is as scalable as I want it to be because it is deployed in Kubernetes. I can scale it as much as I want.

I used to use Terraform and I switched to Upbound Crossplane because of the benefits around active reconciliation and Kubernetes ecosystem enablement.

Before choosing Upbound Crossplane, I evaluated other options such as Pulumi. The AI capabilities around Pulumi I find very intriguing, but I felt that my organization was not as mature to push all the infrastructure responsibilities to development teams. That is why I ultimately used Upbound Crossplane as my final tool.

I find the documentation around Upbound Crossplane very good. However, I also had to look for different blogs and open-source documentation to understand how this tool actually works when I was new. Still, I would say it was one of the better-documented projects than some of the other projects that I find in open source today. I find it to the point.

I can share some specific outcomes and metrics that highlight how Upbound Crossplane helped us deliver and build faster and more reliably. We took some time in building the whole knowledge base around Upbound Crossplane and tools such as Argo CD and Argo Workflows. But it still did not take much time. It was a one-month research and development period when we were able to build our minimal viable new kind of deployment model. The benefits we saw were amazing. We went from having a 28-member troubleshooting team down to four to five members of the platform engineering team. The metrics were also great from reducing the cost. Because we were always working on cost optimization once the deployment is done, it keeps on monitoring itself. I only need to watch my Git repository. If no changes are made there, nothing will cause any troubles. We were always working with new tools in cost optimization and security such as Kubecost and Karpenter in AWS. This helped us do all the research and development in the cost optimization and security landscape, which helped us save huge costs.

I find the pricing, setup cost, and licensing of Upbound Crossplane very suitable for research and development.

I would give Upbound Crossplane a nine rating. I take off that one point due to the provider maturity. I would advise others looking into using Upbound Crossplane to start small. Solve one problem at a time with Upbound Crossplane, and then you will have many problems that you can solve in your organization, but start small with a small use case. I have one additional thought about Upbound Crossplane before we wrap up: it is all good, and I want to send my cheers to the team working behind this project. The documentation and community support are commendable. If I had to suggest anything to change for the future, I would say to keep doing what you are doing.

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.

The best features Upbound Crossplane offers include the GitOps approach, which synchronizes Kubernetes platform changes, and I find that very useful compared to Terraform. With Terraform, maintaining the Terraform code is risky, and if any Terraform block breaks, the entire code and Terraform lifecycle breaks. With Crossplane, maintaining individual components and keeping Kubernetes components in sync using Argo CD is more feasible and easy compared to Terraform, which is why we are trying to pivot towards Crossplane from Terraform.

Upbound Crossplane helps us increase or expand its API capabilities just like Kubernetes APIs, which we are looking forward to. I believe this is GoLang, and we are investigating that approach. Synchronizing the entire infrastructure and provisioning infrastructure using Crossplane is something we are very interested in, and we will try to achieve that as soon as possible.

Upbound Crossplane has positively impacted our organization so far. I can share specific outcomes such as provisioning a PostgreSQL database, an S3 bucket, and an EC2 instance from Crossplane using the GitOps approach, which has worked very well. We are trying to expand the same towards the entire Kubernetes native capabilities as well, and that is our current goal.

When I provisioned PostgreSQL and S3 buckets through Crossplane, I noticed improvements in deployment speed, reliability, and team collaboration. Since this works solely on the GitOps approach, whenever we use Crossplane to provision any PostgreSQL or other cloud resources, we can see the entire logs using that specific Argo CD application sets. If something breaks, we can immediately look into the Argo CD app and its logs to determine exactly where the problem is coming from. The deployment happens in a matter of seconds, not in minutes, compared to Terraform, and that is what has impressed us with Crossplane so far.

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 have been using Upbound Crossplane for close to three months, and I also used it in my previous company as a POC, not in a production environment.

I have not experienced any reliability issues with Upbound Crossplane so far; it performs very well.

Upbound Crossplane's scalability has met my needs as the platform grows. Since it works on a GitOps approach, it is all a matter of the HPA and the VPA concerning the Crossplane components, which can be easily maintained.

I have not yet interacted with customer support for Upbound Crossplane.

Previously, we were using application deployments through GitHub Actions integrated with Argo CD, and we were deploying applications using Helm charts from our GitHub repositories, while the target environment was a Kubernetes cluster managed by Terraform. Since we are working 100% on the Kubernetes native platform, we are trying to shift from Terraform.

We did not evaluate any other options except Upbound Crossplane.

My advice to others looking into using Upbound Crossplane is that if they have any legacy systems or if they are deploying applications on virtual machines, I would suggest they stay away from Crossplane because it is strictly bound to a Kubernetes-native GitOps approach. However, if they are deploying their applications on Kubernetes, then I would suggest they consider it. I would rate this product a 6 out of 10.

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.

One feature of Upbound Crossplane that I love is the reconciliation of the resources. If drift detection happens, it will automatically try to self-fix those resources and recreate them. That is the main part, and another benefit is that if we want to create thousands of instances or network resources, we can do that with just one API call, and everything will be handled through Upbound Crossplane. Also, it is Kubernetes-based, meaning it handles operators and Kubernetes operators that monitor the resources, and if something gets damaged, it will automatically self-heal that resource.

Most importantly, I find myself relying on the VM part of Upbound Crossplane, which we currently have. Let's suppose if any VM goes down or shifts from the ready state to another state, it will constantly watch that actual and desired state. If something changes from the desired state, it will try to reconcile that and actually create those resources. Additionally, it will have a layering with it, and it will inform the team via a Slack message; any detection will pop up on the UI, indicating that there are resources with some issues and that we are trying to reconcile them.

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.

I have been using Upbound Crossplane to provision our infrastructure for one year.

Upbound Crossplane is stable.

When it comes to Upbound Crossplane's scalability, if we want to send some traffic to the outside internet, we can provision any infrastructure from Upbound Crossplane, and it will support that delete operation and, if it is in the ready state, we can route traffic to those nodes. In terms of scalability, we can create the desired number of replicas, change configurations, and manage resources dynamically. Any shortages will trigger automatic resource creation.

I have not had a chance to utilize customer support, as I have not encountered a specific reason to connect with them.

Prior to using Upbound Crossplane, we were using Terraform, which had state lock issues and lacked self-healing features. That is why we switched to Upbound Crossplane, as it effectively handles all these concerns, making our jobs easier.

Before choosing Upbound Crossplane, I evaluated various options, but I only found Upbound Crossplane to be the best choice. However, I am not recalling the solutions I looked at.

My advice for others looking into using Upbound Crossplane is this: if you are suffering from Terraform's state file locks while provisioning infrastructure and want to automate network cloud resources, reconciliation, and resource monitoring without manual intervention, then Upbound Crossplane will be very beneficial and useful. I would rate this product a nine out of ten.

My main use case for Upbound Crossplane is for platform engineering and infrastructure automation, as I use Upbound Crossplane to provision and manage cloud resources, such as databases, storage, clusters, and networking, through Kubernetes APIs, enabling self-service infrastructure for development teams.

Currently, I use Upbound Crossplane primarily to see which clusters and nodes are operational and which are not.

The best features Upbound Crossplane offers are infrastructure as Kubernetes APIs and self-service infrastructure. Developers can provision resources without cloud credentials, which is a significant advantage. Multi-cloud support is also a strong point, as I have seen that it is useful in managing AWS, Azure, and GCP from a single control plane. GitOps integration is another valuable capability.

Apart from the organization, Upbound Crossplane has also positively impacted my personal projects. I am currently learning through personal projects that I have created.

I can share a specific example of how Upbound Crossplane has impacted my personal projects. I used Upbound Crossplane's multi-cloud support to learn and experiment with provisioning resources for both AWS and GCP using a Kubernetes-based approach. It helped me understand cloud-agnostic infrastructure management without having to learn separate provisioning workflows, and I use that knowledge for cloud automation in my personal projects.

Upbound Crossplane has good community support, and I can find a lot of material over the internet. However, one area of improvement is the learning curve, as Upbound Crossplane concepts such as providers, compositions, and claims can be difficult for beginners. Documentation and troubleshooting can sometimes be challenging. We could benefit from better examples of debugging, improved error messages, and a more intuitive UI to make adoption easier.

I rated it eight out of ten because it solves infrastructure automation and self-service provisioning very well while supporting multi-cloud environments. However, it is not a ten due to the steep learning curve and the complexity involved in debugging and setting up compositions.

I have been using Upbound Crossplane for one year now.

Upbound Crossplane is stable.

Upbound Crossplane's scalability is good, and it is scalable.

Regarding customer support, I have not tried it yet. I have not felt any difficulties, so I will see how this evolves in the future.

I have not previously used a different solution before Upbound Crossplane. This is my first time using such a solution. I am more focused on my personal projects, so I do not use Upbound Crossplane extensively in my organization. However, I use it to learn, and I believe it will be great in the upcoming years.

I have not evaluated other options before choosing Upbound Crossplane.

My advice to others looking into using Upbound Crossplane is that they should try it once, and then they will understand what I am referring to. It is a great solution. I would rate my overall experience with Upbound Crossplane as eight out of ten.

My main use case with Upbound Crossplane during the time I used it was creating Azure resources such as Azure containers and VMs from Kubernetes clusters and AKS clusters in an automated, fully cloud-native way.

A specific example of how I used Upbound Crossplane for this automation is that we wanted to create resources and used Tekton to manage the automated process. In our POC, we used Argo CD to manage the Azure resources so that if anything happened on the AKS cluster or on the Kubernetes resources, if someone deleted it, we could easily recreate the whole thing. That's how we managed it.

In my opinion, the best features Upbound Crossplane offers are that it runs on Kubernetes, which is the main thing. As our whole infrastructure and everything runs on Kubernetes and we manage everything with Kubernetes, it is the best option. Since we also use Argo CD to manage the cluster, we don't need to manage anything else with GitHub Actions or Terraform; we only need to manage Upbound Crossplane resources.

As I mentioned regarding managing everything through Kubernetes and integrating with Argo CD, it simplifies our workflows and reduces the need for other tools such as Terraform or GitHub Actions. In our scenario and use case, we needed to manage it through our back-end services, which were on Kubernetes, so it was easier to manage the resources through Kubernetes. From our back-end application, we could call the Kubernetes API, and we just needed to call a GitHub repo and add a file on the GitHub repo, which was very useful to manage. That's why we wanted to use Upbound Crossplane instead of Terraform.

Upbound Crossplane impacts my organization positively because, from our perspective, we need to rely on fewer resources. As it manages through Kubernetes, it is easier to manage from a back-end application to do everything. For example, if we create any resources from a back-end application, we could actually manage and keep the information in a database, so it was less of a task.

The documentation needs to be updated regarding the needed improvements for Upbound Crossplane. There is very little documentation online, and there are no tutorials for Upbound Crossplane. We can find so many more tutorials on Terraform and other resources, but there are very few tutorials for this. Whenever a new developer or a new person comes to learn about the resources, it is very helpful if they have some video documentation. So, Upbound should work on that.

My advice to others looking into using Upbound Crossplane is that Upbound should actually work more on the documentation; it would be very easy to use if someone goes through the documentation. It may work, but Upbound should definitely work more on the documentation.

I worked with Upbound Crossplane for about six months.

In my experience, Upbound Crossplane is stable.

Upbound Crossplane's scalability is very good; it is very scalable as it is running on native Kubernetes, so it was very scalable from my perspective.

We didn't use customer support with Upbound Crossplane.

Before Upbound Crossplane, we used Terraform, but from the back-end perspective, it was very hard to manage or run Terraform from the back end.

There is a return on investment, as there are fewer employees needed, but I don't have any concrete metrics because it is managed from the management team, who have the metrics. If you need it, you can contact the company.

A specific outcome or metric I can share is that we reduced the headcount by two engineers. From the initial infrastructure creation, the automation we created allowed us to build any resources based on the back-end, so no additional DevOps engineer was needed.

Regarding my experience with pricing, setup cost, and licensing, since it was open source, we didn't need any licensing fees, but it was a little difficult because there is very little documentation. Other than that, everything is acceptable.

Before choosing Upbound Crossplane, we evaluated Terraform, but it didn't align with our goal.

Overall, I don't have any additional thoughts about Upbound Crossplane; it was a really cool product. Regarding Upbound Crossplane's AI capabilities, I haven't worked on that, so I don't have knowledge about it. Concerning Upbound Crossplane's AI capabilities, I think its accuracy and reliability of output are the same; I don't know, as I didn't work with Upbound's AI capabilities, so I don't have anything to share about that. I would rate this review a nine out of ten.

My main use case for Upbound Crossplane is that I built a small internal developer platform for my previous company.

I created a composite resource definition in Upbound Crossplane that described the whole technology stack that my company was installing at each deployment. Because that software was specifically tailored for each customer, and it was a set of microservices, automating this process was necessary since doing it manually was quite time-consuming. I provided an interface that developers could use to create new environments.

The best features Upbound Crossplane offers is that it makes sense from a design perspective compared to Terraform or other tools. Because it's integrated in Kubernetes, which is ultimately where your software is going to run, it leverages the Kubernetes control loop. This keeps everything in one place, and you only have to maintain one mental model without having to think about how to save the state of your environment somewhere else, as happens in Terraform.

Upbound Crossplane has impacted my organization positively by making it much easier for the operations team to deploy our environments and software without requiring them to know exactly what had to be done. It offered me the possibility of creating an abstraction that other people could use to make their job easier. The time required to complete an environment setup was reduced from about one or two weeks to forty to fifty minutes. Although I don't have a specific metric for errors, it was very often the case that some configuration was forgotten or something was done differently compared to the past, which would cause problems down the line. By coding the process in Upbound Crossplane through composition, errors were only possible if I made an error in the code.

One main problem I had with Upbound Crossplane was probably due to the still somewhat immature state of the product. There were many bugs throughout, and some were quite troublesome. I had a problem where I couldn't create some resources with the same name in different namespaces. They would be included in the finalizers of the objects in other namespaces. When I was trying to delete those, I essentially couldn't delete them because there was always some finalizer remaining. I raised an issue on GitHub, and this issue has remained unresolved for several months. This is only an example of multiple occurrences of such problems.

I have the feeling that vanilla Upbound Crossplane, the open-source version, is somewhat declining compared to the commercial offering. I would like to see the open-source project maintained more actively.

I have been using Upbound Crossplane for one year and a half.

Upbound Crossplane was not stable in my experience.

Scalability was also a problem with Upbound Crossplane.

I did not try the customer support for Upbound Crossplane.

I used Terraform before Upbound Crossplane. I switched because Upbound Crossplane also offered the possibility of creating my own custom resources.

Before choosing Upbound Crossplane, I evaluated Terraform and Ansible.

I would suggest using Upbound Crossplane for smaller projects within the company, but don't rely too much on it for larger-scale projects or projects that are mission-critical.

I really loved working with Upbound Crossplane, and I'm sure that over time it is going to improve and possibly become the standard one day because in my vision it is really much better than its competitors. However, it still needs more work.

My overall rating of Upbound Crossplane is eight out of ten.