Polybee builds physical AI for agriculture. Its engineering team uses machine.dev to run CI/CD for its computer vision and machine learning repositories. For Samir Otiv, its VP Engineering, the benefit is time his team gets back from investigating runner problems.
Its autonomous pollination and crop-monitoring systems combine drones with computer vision. CI/CD pipelines help the engineering team check changes before releasing that software.
"We use machine.dev for CI/CD pipelines for ensuring confidence on releases of our computer vision and machine learning repos."
Samir Otiv, VP Engineering, Polybee
The runner was becoming another thing to debug
Before Machine, Polybee used GitHub runners. Samir describes limited choice of machines and intermittent failures in that setup. Missing packages and older pre-installed versions also meant the team had to account for quirks in the runner environment.
That creates an extra investigation when a job fails. The team has to work out whether the change broke something or the runner got in the way. For Polybee, reducing that work was part of choosing a different setup.
The team wanted GPU support while keeping its GitHub Actions workflows familiar. Machine let it choose GPU runners without taking on the infrastructure needed to operate them.
A small change to existing workflows
Samir describes the move to Machine as a one-line change, with few additional changes to repository setup actions. Where those actions did change, he says they were mostly simplifications.
His description of onboarding: "the onboarding was seamless."
Spot-instance support also helped make Machine attractive to the team. They could select the compute they needed through the workflow rather than maintain their own runner infrastructure.
The saving was engineering time
Asked what changed for the team, Samir's answer was direct:
"Zero time spent on debugging or investigating flaky Github action runners. Zero time lost due to transient issues on runners."
Samir Otiv, VP Engineering, Polybee
That is the improvement he points to in Polybee's experience: fewer runner investigations taking time away from the team's work. He also describes the organisation as more efficient with Machine because of the engineering time saved.
Bringing another repository onto Machine
The same setup carries over when Polybee adds another project. Samir says it is easier to bring a new repository onto Machine because the team has less infrastructure to think about.
There is still a workflow to configure, but another repository does not mean another set of runner machines for Polybee to operate.
For Polybee, GPU CI fits into its existing release process. The team keeps working in GitHub Actions, with more choice over the machines that run its jobs.