With Box CI you run CI builds on your dev machine, or any other machine you want.
Why does using a CI service mean you need to run your builds on slow, expensive servers? You have a machine sitting in front of you that's way more capable, and free to use.
A CI service should focus on the stuff you don't have time to implement yourself - build management, history, logs streaming, access for all your team. That's all Box CI does. It lets you control the one thing you actually want to - running your builds.
Porting your build to a CI service takes ages. Understanding their model, their options, their yml format, their support formus, on and on.
A CI service that runs everyone's builds needs a way to manage a lot of servers and jobs running arbitrary code. That's hard, and using containers, avoiding state and caching and funnelling everything through a uniform config format make it a bit easier.
But what's convenient for the platform isn't what's best for you and your build. A custom solution on appropriate hardware is always going to do better. Don't waste your time shoe-horning your build into someone elses platform because they mandate it - it's already good to go!
All you want to do is add the service part of the CI service on top. That's what Box CI does.
A big concern with running your builds and deployments on third party servers is that there is no way around giving them all of your code and secrets. That stuff is the keys to the kingdom. It's a pretty big responsibility.
Now look, we all trust these big companies aren't nefarious. But the problem isn't them, it's that people know they hold all these secrets. They're a pretty obvious target. And even with the best of intentions, accidental security bugs happen.
With Box CI you know that the worst case scenario for us getting hacked is your build logs and history getting leaked. You always remain in control of your own code and secrets - the way it should be.