hoplite.sh

Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents

BenceRed · 81 points · 70 comments · 8월 3일 · Open original

Hi HN, we’re Bence and Ryan, founders of Hoplite (https://hoplite.sh). Hoplite lets you deploy coding agents in the cloud, with a suite of tools that makes it incredibly easy to QA features. During onboarding, we port over your local setup - sessions, memories, MCP servers, and get your projects ready to run in the cloud. Here’s a demo: https://youtu.be/bnyktZ_9pjE We got here after pivoting away from the idea we applied to YC with; AI for retail investing. It ultimately wasn’t a product that we ourselves would use, nor served a customer base that we felt connected to. In reflecting on what we really wanted to do, we realised that we loved talking to founders and developers, and were really opinionated about the specific area of cloud agents. We tried out all the existing solutions, and didn’t find one that A) took good advantage of being in the cloud, and B) was performant and felt good to use. We’re building a product that we feel reflects what mainstream development will look like in 6-12 months. As models improve, developers will end up reviewing less and less code, and will instead focus on reviewing the product output. That means evaluating new user flows, visually verifying that new features look good, that the API works as expected, that the CLI works on Windows, etc. And doing it while running hundreds of agents concurrently. On the agent side, we’ve created a custom harness. We spent a lot of time deciding on whether we should use an off the shelf solution like Codex/Claude Code, but ultimately wanted the independence and freedom that came with building it in house. It also means that we can test out completely new features without relying on Anthropic and OpenAI to catch up. Everything is hosted on AWS, with the exception of: Temporal for durable workflows, Modal for sandboxes, and Planetscale for our database. Our infra decisions were driven by a strong belief that agents are becoming a tier 0 piece of infrastructure, and they need the reliability and security to match that. You can try it now for free with the code ‘HACKERNEWS’ - we’ve included $100 in free credits, plus you can connect your Codex subscription and use OpenAI models via it. You can see some more details around our pricing at https://hoplite.sh/pricing. At the moment we’re focusing on optimising two key experiences: onboarding and previews, and would love to hear your feedback on them. And if you find that the agent's performance in certain tasks doesn’t match your expectations, please let us know!

Comments

5 preview comments · loading full thread
scottydelta8월 3일

Trying to wrap my head around how it differs from my current on-the-go setup that is claude code. On claude's phone app or web app I can choose a repo, ask it for a feature and it writes the code, runs my tests + add more tests and creates a new branch. Then I can click on create PR or configure claude code to auto create PR. I also have another setup which is a self-hosted docker compose behind my vpn with one container with claude code agents managed using agent of empires[0] and another container with playwright with sse. Using this setup, my agents get access to actual browser where it can test things live and I can access the app started by agent on domain:port. This is something I don't get with Claude. [0] https://github.com/agent-of-empires/agent-of-empires

sebmellen8월 4일

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.?

kunalganglani5일 전

Nobody talks about this but the security model is the thing that should disqualify most of these tools immediately. I spent a weekend auditing the network calls that three popular open-source coding agents make. Two of them send your file contents to external endpoints by default with zero sandboxing. No confirmation prompt, no allowlist, nothing. If you're running these on anything with proprietary code you're essentially uploading your source to a third party and hoping their privacy policy holds. OpenCode is the worst offender here — the default config pulls from a remote provider URL and there's no way to even see what's being sent without packet inspection. You can lock it down but it requires manually editing YAML configs that aren't documented anywhere obvious. Aider at least respects .gitignore and keeps everything local unless you explicitly configure a remote endpoint. The frustrating part is the actual coding capabilities are decent on several of these. Multi-file edits, git integration, context-aware suggestions — all solid. But none of that matters if the tool is silently exfiltrating your code. Audit the network layer before you evaluate anything else.

kristianc8월 3일

>> It opens a pull request >> Then keeps iterating as review comments land, in the same thread, with the same context. My experience, particularly with Sol is that agents are generally really bad at knowing when to stop 'iterating' and will continue covering off ever-more obscure edge cases. How does Hoplite solve for this?

chandankarn8월 4일

The "reviewing product output instead of code" framing is the right direction for where development is heading, and the per thread VM model makes sense for isolation. One dimension worth thinking through as you scale: the security surface of cloud-hosted agents is meaningfully different from local agents. Local agents (Cursor, Claude Code) have access to your local filesystem and credentials. Cloud agents have access to your cloud credentials, your production-adjacent infrastructure, and potentially your CI/CD pipeline and they run without the developer watching. The MCP server porting during onboarding is the piece I'd think hardest about. MCP servers can have write access to config files, and the STDIO transport has a documented unsanitized parameter passthrough vulnerability (AVE-2026-00060, corroborated by OX Security and Microsoft) that affects Python, TS, Java, and Rust SDKs. When you're running hundreds of agents concurrently in the cloud, a single compromised MCP server has a much larger blast radius than a local one. The "what the agent writes" security layer is separate from the "how the agent runs" security layer. Hoplite solves the second. Scanning what the agent wrote (SAST, secrets detection, dependency audit) before it gets merged is the complementary first layer. SafeWeave runs as an MCP server inside the agent's environment for exactly this works locally and in cloud agent setups. Congrats on the launch. What's your current approach to credential scoping for agents that need cloud access?