At the risk of replicating the classic Dropbox post (why would you need this when you could just use rsync?)…
I have a dev box with 96 GB of RAM, 2x4 TB NVMe drives, and an unbelievably beefy AMD CPU. This box costs me less than $150 per month and is so hyperlocal that I can log into it and use it as a remote desktop, while also using it as an always-on server that I can use to run T3 code and tmux and so forth. I can then connect to it from my laptop or my phone using Tailscale and prompt using the T3 Code or Remux mobile apps. Voilà — I have my own outsourced development center.
In this setup, my agent can handle everything: previews with a NixOS environment, unlimited threading, “autofixing” (which is just a loop between my agent and Copilot review comments), etc.
But it requires a LOT of custom setup/tooling so that my local environment works with my agent.
Why am I telling you this? Well, I've tried a number of serverless or ephemeral VM-type solutions, and it turns out that once you're working on "real code," you can't use ephemeral micro VMs reliably because your code starts interacting with too many different dependent services. You have to run migrations, so that your tests run properly, and to do that, you need to pull five different Docker images, and it goes on indefinitely. Eventually, the overhead of making little micro VMs is so high that it makes much more sense to take a monolithic approach to development and have a persistent workstation. You can still use things like worktrees, which allow you to massively parallelize your work, but you're building off of a shared local drive and cache.
So I believe there's a place for something like Hoplite with simpler software, but the problem is that the minute you get beyond toy software, it becomes really hard to test, scale, and deploy everything in micro VMs. There are also other companies that have tried this approach (like https://shipyard.build, although I think they had a slightly different philosophy from what you're doing) and I don't know that they've been massively successful.
What is it that you're doing differently that will allow Hoplite to succeed? How do you think that you'll compete against the legacy players in this space and the more full-spectrum players like Devin, et al.?
Re: the dev box, it works very well for individuals and small sized teams, but starts to become an operational burden past a certain size. Our ideal customer is one who has a ton of engineers and wants great multiplayer/observability, as the case for Hoplite becomes a lot clearer -- "Run through project setup once, then onboard all engineers with one email (and they can bring their entire local setup with one CLI command)".
On the point of microVMs, agreed that it's a very difficult problem to solve. Luckily sandbox providers are continuously improving their APIs to make this slightly easier, but I wouldn't be surprised if we need to migrate over to AWS Lambda MicroVMs and roll a lot of the orchestration logic ourselves. Our goal is to get our P95 project setup time (i.e. connect -> fully running in the sandbox) to around 5 minutes, most of which we imagine being dependency installation. This is one clear point of differentiation where if we nail it, we'd be leagues above the rest of the competition.
The legacy players such as Devin, Cursor, and Factory are certainly well entrenched in their market position, but this space has the unique advantage of completely reworking how it operates every 6 months. These existing tools need to balance keeping up with new user demand for features, while also maintaining the old legacy workflows for their existing customers. We're lucky in that we can now build a product that we believe resembles how the majority of development will work ~1 year from now, meaning we have a lot more flexibility in how we can move forward.
And fundamentally, outside of large enterprise features like on-prem deployment, the key differentiators are 1) UX, 2) cost, and 3) harness performance. We can certainly win at the first, are at parity with the second, and likely struggle at the third (need to do benchmarks/evals -- if those go poorly then we'll transition from the custom harness to using the first party Claude Code/Codex. So quite fixable.)
Thanks for the attempt, but this is really a non-answer, which makes me think you have not worked with the kind of large, well-encumbered codebases / business problems that I seem to be attracted to :D
My take is that some of your architecture decisions are fundamentally incompatible with [what I believe to be the state of] most enterprise codebases.
And that’s fine if you have a very specific client base and are focused on fellow startups.
I have a dev box with 96 GB of RAM, 2x4 TB NVMe drives, and an unbelievably beefy AMD CPU. This box costs me less than $150 per month and is so hyperlocal that I can log into it and use it as a remote desktop, while also using it as an always-on server that I can use to run T3 code and tmux and so forth. I can then connect to it from my laptop or my phone using Tailscale and prompt using the T3 Code or Remux mobile apps. Voilà — I have my own outsourced development center.
In this setup, my agent can handle everything: previews with a NixOS environment, unlimited threading, “autofixing” (which is just a loop between my agent and Copilot review comments), etc.
But it requires a LOT of custom setup/tooling so that my local environment works with my agent.
Why am I telling you this? Well, I've tried a number of serverless or ephemeral VM-type solutions, and it turns out that once you're working on "real code," you can't use ephemeral micro VMs reliably because your code starts interacting with too many different dependent services. You have to run migrations, so that your tests run properly, and to do that, you need to pull five different Docker images, and it goes on indefinitely. Eventually, the overhead of making little micro VMs is so high that it makes much more sense to take a monolithic approach to development and have a persistent workstation. You can still use things like worktrees, which allow you to massively parallelize your work, but you're building off of a shared local drive and cache.
So I believe there's a place for something like Hoplite with simpler software, but the problem is that the minute you get beyond toy software, it becomes really hard to test, scale, and deploy everything in micro VMs. There are also other companies that have tried this approach (like https://shipyard.build, although I think they had a slightly different philosophy from what you're doing) and I don't know that they've been massively successful.
What is it that you're doing differently that will allow Hoplite to succeed? How do you think that you'll compete against the legacy players in this space and the more full-spectrum players like Devin, et al.?