What is our primary use case?
Our main use case for Anbox Cloud is running Android applications in the cloud for scalable testing and remote access. We use it to spin up Android instances on demand, validate app behavior across versions, and support streaming sessions without needing many physical devices. It helps us to reduce dependencies, automate validation, and scale Android environments faster for QA and development workflows.
One unexpected benefit was how useful Anbox Cloud became for reproducibility. Instead of relying on physical devices with different states, we could launch clean Android instances and reproduce issues in a more controlled way. Another unique use is using it for remote demos and validation, where stakeholders could access the Android app without installing anything locally. This helped reduce setup friction and made testing faster across distributed teams.
What is most valuable?
The best feature of Anbox Cloud is its scalable Android instances, as you can launch multiple Android environments on demand without depending on physical devices. We have the cloud-based app streamer, so users can access Android apps remotely through their browser or a streaming session. Every session can start from a controlled image, which is very useful for QA and debugging. The QA automation potential fits well with CI/CD pipelines for testing Android apps at scale. For me, the biggest value is the scalability plus reproducibility, which makes Android testing and validation much easier to standardize. Another important feature is the centralized management of Android images and sessions. It makes it easier to control versions, update environments, and keep testing consistent across teams. I would also highlight the low-friction access for users, as they do not need a physical Android device or complex setup. They can open a session remotely and interact with the app almost immediately.
Anbox Cloud has a positive impact because it reduced our dependency on physical Android devices and made testing environments easier to scale. It helped us improve QA efficiency, reproduce issues faster, and provide remote team members with consistent Android sessions. It also reduced setup time for demos, validation, and exploratory testing because users could access Android apps directly from the cloud.
A few measurable outcomes are that we reduced Android environment setup time from hours to minutes because sessions could be launched on demand. We also reduced dependency on shared physical devices, which helped avoid waiting time between QA developers and stakeholders for testing issue reproduction. This tool became faster because we could start from clean, consistent Android instances instead of troubleshooting device-specific issues. Overall, it improved QA turnaround time and made remote validation much easier, specifically for distributed teams.
What needs improvement?
Anbox Cloud can be improved mainly in ease of setup and operational simplicity. The platform is very powerful, but the initial configuration can feel complex, especially around infrastructure, networking, images, GPU support, and scaling. Better guided setup, clearer troubleshooting messages, and more production-ready templates would help a lot. I would also improve the monitoring and reporting experience, especially around session performance, resource usage, latency, and failures. For QA and operation teams, having clearer dashboards and logs would make it easier to detect problems quickly. Overall, it works well, but it could be more user-friendly for teams that do not have Linux, LXC, or cloud infrastructure experience.
I would add that the documentation could be more scenario-based. The official docs cover the components, but real production examples would help more, specifically for scaling, GPU configuration, networking, image lifecycle, and troubleshooting failed sessions. Also, integrations could be stronger. Better out-of-the-box examples for CI/CD pipelines, monitoring tools, observability dashboards, and automated QA workflows would make adoption easier. I also would appreciate clearer guidance around cost optimization because when you scale Android instances in the cloud, resource planning becomes very important.
For how long have I used the solution?
I have been using Anbox Cloud for around two years.
What do I think about the stability of the solution?
Anbox Cloud is very stable for us.
What do I think about the scalability of the solution?
Scalability is one of Anbox Cloud's strongest points. It scales well because Android instances can be launched on demand instead of depending on a fixed pool of physical devices. That made it easier to support parallel QA sessions, remote validation, and multiple user testing at the same time. The only limitation is that scalability depends heavily on the infrastructure behind it, especially AWS compute capacity, GPU availability, networking, and session management. The platform scales well, but it needs proper resource planning and monitoring to avoid performance issues or unnecessary costs.
How are customer service and support?
Our customer support experience was good, especially when the issue was clearly related to the deployment configuration or platform behavior. The support team was helpful, but some cases required detailed logs and infrastructure context before getting a clear answer. Since Anbox Cloud involves Ubuntu containers, networking, GPU, and cloud resources, troubleshooting can be complex. Overall, I would rate support positively, but I would appreciate faster guidance for production issues and more related user troubleshooting documentation.
Which solution did I use previously and why did I switch?
Before Anbox Cloud, we mainly relied on physical Android devices and some traditional cloud device farm options like BrowserStack, but we switched because Anbox Cloud gave us more control over the Android environment, better scalability for launching sessions on demand, and more consistency for reproducible testing. Physical devices were harder to manage remotely, and device farms were useful but less flexible when we needed customized Android images and controlled infrastructure.
How was the initial setup?
Anbox Cloud can be improved mainly in ease of setup and operational simplicity. The platform is very powerful, but the initial configuration can feel complex, especially around infrastructure, networking, images, GPU support, and scaling. Better guided setup, clearer troubleshooting messages, and more production-ready templates would help a lot.
What was our ROI?
We saw a positive return on investment mainly through reduced device dependency, faster setup, and better reproducibility. The clearest metrics were that we reduced Android environment setup time from hours to minutes because QA and developers could launch cloud sessions on demand. We reduced waiting time for shared physical devices, especially when multiple people needed to validate the same build. We did not necessarily reduce headcount, but we improved team capacity because the same QA team could execute more validations without needing extra devices or manual setup. From a cost perspective, the biggest saving was avoiding the need to constantly buy, maintain, replace, and coordinate multiple physical Android devices across distributed teams.
What's my experience with pricing, setup cost, and licensing?
Our experience with pricing was that it was reasonable for the value, but it requires careful planning. The main cost came from AWS compute resources, storage, networking, and scaling Android sessions. If sessions are always running, costs can grow quickly, so we had to manage capacity, shut down unused instances, and monitor usage. For setup costs, the initial effort was higher because Anbox Cloud requires good knowledge of Ubuntu, cloud infrastructure, networking, and scaling configurations. The licensing was manageable, but it is not something I would treat as plug and play. You need to evaluate the license together with infrastructure costs to understand the real cost of ownership.
Which other solutions did I evaluate?
We evaluated a few alternatives before choosing Anbox Cloud: BrowserStack for cloud-based real device testing, AWS Device Farm for Android app testing at scale, Firebase Test Lab, and the usual physical Android device labs. We chose Anbox Cloud because it gave us more control over the Android environment, better flexibility with cloud infrastructure, and stronger scalability for launching Android sessions on demand.
What other advice do I have?
For governance and security, I would say that Anbox Cloud is strong from an infrastructure and isolation perspective, but its AI capabilities are not the main focus of the platform. The security value comes more from running Android workloads in controlled, isolated cloud environments, managing images centrally, and limiting access through infrastructure policies. That helps with governance because teams can control which Android versions, apps, and sessions are available. For AI-related use cases, I would still recommend adding clearer access controls, audit logging, data rotation policies, and monitoring around user sessions because sensitive data can pass through those environments. Overall, I would rate governance and security as solid, but it depends on how well the organization configures the surrounding cloud infrastructure.
My advice for others looking into using Anbox Cloud is to plan the infrastructure before adopting it, because it is a powerful solution, but it is not just install and use. You need to think about AWS capacity, networking, GPU needs, session limits, storage, monitoring, and cost control from the beginning. I would also recommend starting with a small pilot first to validate your Android app, measure latency, test scaling, and confirm how many sessions your team really needs. For QA teams, the biggest value comes when you standardize images, automate session creation, and connect it with CI/CD. That is where Anbox Cloud becomes much more valuable than only replacing physical devices.
Overall, Anbox Cloud is a strong platform when you need scalable Android environments in the cloud. The biggest value is not only replacing physical devices, but creating a more controlled, repeatable, and scalable Android workflow for QA, demos, and remote validation. Teams should treat it as an infrastructure platform, not just a testing tool. When it is planned properly with monitoring, cost control, automation, and security policies, it can deliver a lot of value. I would rate this solution an 8 out of 10.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)