Remix.run Logo
Launch HN: Hoplite (YC S26) – Effortlessly deploy cloud coding agents(hoplite.sh)
30 points by BenceRed 4 hours ago | 37 comments

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!

scottydelta an hour ago | parent | next [-]

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

BenceRed an hour ago | parent [-]

That setup is pretty much what we're trying to offer with Hoplite!

Using us means losing freedom and control with regards to infrastructure, however we think that's a tradeoff people would want to make in exchange for easier onboarding and a more polished experience.

scottydelta 32 minutes ago | parent [-]

Makes sense. It took me some experimentations with a few open source libraries and docker-compose to arrive at my setup. My setup also requires me to access agents via a terminal app on my phone so it's nice to have a web app like your offering.

Are you offering browser access to the agents in your setup?

BenceRed 13 minutes ago | parent [-]

Yes, agents have a persistent Chromium session they use via the agent-browser CLI. Typical workflow would involve starting the preview, seeding data, then the agent going through the old and new UX flows for a before + after view. We've also got some optimisations around saving the aforementioned flows in a QA library, so that they can be replayed without needing an agent to run through it all again.

asdev 13 minutes ago | parent | prev | next [-]

just a data point, at my company we are building this internally. if you're targeting people building from scratch it might work, but there's no way you can port any somewhat mature infra stack, nor will the org want to. you'll need to deal with the variable complexity of everyone's dev environment which already doesn't work locally for thousands of different reasons.

BenceRed 9 minutes ago | parent [-]

Agreed that at the moment it's a very difficult problem, but one we're looking to solve! I think it becomes a no-brainer for most people if we're able to give each agent a replica of their production stack.

What does your current setup look like? And are you using an open source solution like OpenInspect for your in-house version, or building it from the ground up?

asdev a few seconds ago | parent [-]

Building from ground up using OpenAI Agents SDK. We already have custom in house Cloud Development Environment, so the effort is just to "agent-ize" though which is not small. That's why I feel any team with any sort of infra support likely won't buy your product, since they already have the tribal knowledge to set this up. Newer teams might. But overall porting people's dev envs into the cloud is a tarpit problem(IMO), I was interested in this space too but decided against it for that reason. Happy to be proven wrong though!

fishtoaster 2 hours ago | parent | prev | next [-]

Took me a minute to see the value - my first thought was "this is just cursor's cloud agents..."

But the key thing here for me is "Every sandbox boots your app on a live URL." Cursor doesn't easily have that, and that's what would allow me to ditch my local env entirely - the ability to actually try out a PR without needing to check it out locally.

So on that note: how does that work? We've had trouble with getting our dev env running in other cloud envs because it requires a few things (clickhouse, localstack, pg, etc) running which we manage via docker compose locally.

Also, some minor pricing feedback: it'd be really great if there were a version with pay-as-you-go and a cheaper fixed cost. I think your 99/seat/mo model is fine for professional work, but it's a lot to commit to for personal work.

BenceRed an hour ago | parent [-]

Modal just released some features that would allow users to bring custom Docker images, and I'm working on getting your exact use case supported! Aiming to get it out by the end of the week.

Noted the pricing feedback! We're still figuring out exactly what works best so it's still very much so subject to change.

Bnjoroge an hour ago | parent | prev | next [-]

What’s the experience like going from an active on-going thread to a cloud-hosted one? I dont wanna always work on the cloud, and want my current setup to be exactly the same as in the cloud, and should be pretty seamless. Only folks i’ve seen solve these are folks who run the sandboxes locally and take that to the cloud like smolvm/microsandbox.

BenceRed an hour ago | parent [-]

This is still something we're working on making seamless. The current approach is to install our MCP server and ask the local agent to start up a new thread on Hoplite when you want to transition to the cloud, but it doesn't carry over file system changes. (Unless you first push the contents to a remote branch, at which point the Hoplite agent can pull it down.)

r5Khe 3 hours ago | parent | prev | next [-]

Looks neat! I've been using Amp (https://ampcode.com/) for a while (Which seems to be doing something very similar), and I really appreciate this type of workflow. One thread = one VM feels like a solid model going forward.

BenceRed 2 hours ago | parent [-]

Agreed. Per-thread VMs are quite similar to how local agents use worktrees to avoid cross contamination, but with the added benefit of being able to easily scale up/down compute requirements on demand.

mellosouls 3 hours ago | parent | prev | next [-]

Firstly: good luck!

I've been wondering what the alternatives to things like Github Copilot Cloud and Codex Cloud might be, especially ones that might be flexible wrt models, and this seems at least to have some of those behaviours.

If that perception is correct, please would you explain what it offers against those sorts of services (those in particular) and how the pricing compares - eg. their base levels are $20 a month, yours starts at a higher level - I can see there seems to be more brought in from the local IDE world (and similar), which seems very useful compared to the standard "prompt against repo, repeat" of the normal cloud agents but it would be useful to understand the targets and intents.

BenceRed 3 hours ago | parent [-]

Thank you! Regarding models, as you said we're not locked into a specific provider, and are able to offer open weight models like Kimi K3 and GLM 5.2

Our pricing is higher than other providers because we do not upcharge on token or sandbox costs. We believe that people should be running as many agents as they possibly can handle, and an upcharge would create a monetary incentive for us to say that, when it's a genuine belief we hold.

We also offer features out of the box that would usually be behind enterprise gating (e.g. sandbox baking).

lionls 2 hours ago | parent | prev | next [-]

Amazing work, I am currently in the process of building something similar on my server for personal use, but yours looks really promising. Especially running sandboxes on your own can be tedious. Why have you opted for Modal instead of Firecracker or a similar micro VM solution?

Best of luck to you!

BenceRed 2 hours ago | parent [-]

Modal has a lot of small niceties that made them easy to implement, such as filesystem snapshots and programmatic build images. But I did see that AWS recently launched Lambda MicroVMs, and since we're an AWS house we may transition to using them.

My main issue with Modal is that their autoscaling is not as good as Daytona's. You have to stop the machine, resize, then start it, which takes ~3s and terminates all running processes. Daytona supports scaling up (but not down) without stopping the VM.

Also would recommend checking out ColeMurray/background-agents if you're planning to self host. Very good alternative! And the team behind it are great

lionls an hour ago | parent [-]

Thanks Bence, for your thoughts there. Will definitely take a look.

FailMore 2 hours ago | parent | prev | next [-]

Looks interesting. Does this mean I would use this as my day to day harness? Or is it something additional to an established workflow?

BenceRed 2 hours ago | parent [-]

You can do either. If you don't want to migrate over fully, I'd recommend setting up an automation to fix Sentry/PostHog issues as they come in. You can get a good feel for the platform and how it fits into your workflows that way.

We also have an MCP server that you can use to delegate tasks (e.g. research, debugging, SRE work) to Hoplite via your existing local setup.

abtinf an hour ago | parent | prev | next [-]

Why would I use this over exe.dev?

BenceRed 21 minutes ago | parent [-]

exe.dev works quite well for giving an agent a computer and managing it remotely, but seems to require a fair bit more configuration to achieve parity with what we offer out of the box. Namely automations, PR autofix, visual QA, and general UI/UX polish.

I think it comes down to whether configuration or ease of use is valued more, and Hoplite favours the latter a bit more. (They shouldn't really be mutually exclusive, but we have a long way to go before we're happy claiming that we match/beat self-hosting in that area)

mkagenius 3 hours ago | parent | prev | next [-]

If you ever need to switch sandboxes, would be happy to chat.

BenceRed 3 hours ago | parent [-]

At the moment we're using Daytona as a redundant fallback in case Modal experiences an outage, but they have very stringent limits on how many resources we can consume concurrently. We're evaluating adding a second provider to help ease this so would love a chat! Feel free to email bence [at] hoplite.sh

fsuts 2 hours ago | parent [-]

This Daytona? https://github.com/daytonaio/daytona

As the repo says no longer maintained

BenceRed 2 hours ago | parent [-]

This one: https://www.daytona.io. Their platform was OSS for a long time but they decided to go closed source recently.

docheinestages 3 hours ago | parent | prev | next [-]

Suggestion: showing an actual screenshot or video of your app is a much better indicator of effort than a generic Claude made animation. I've seen AI slop landing pages on far too many YC-backed startups. Not saying yours is one, but parts of it smell.

BenceRed 3 hours ago | parent [-]

Agreed 100%. We've been working with a designer on a complete redesign of our landing page to avoid that vibey-smell.

LoganDark 3 hours ago | parent | prev | next [-]

Naming conflict with https://www.hoplite.gg

rytill 3 hours ago | parent | next [-]

Almost every possible name that is not a portmanteau, made-up word, or combination of N words has a naming "conflict". This is not an interesting thing to say and I wish that people would stop saying this on everything anyone ever posts on HN. It almost feels like it should be against HN rules to point out that something else shares the same name with no additional statements.

LoganDark 2 hours ago | parent [-]

For one, it's interesting to me because I've already known Hoplite for years as nothing to do with AI. For two, I'm not sure how sharing that is so egregious it should be against the rules? Is there an interpretation I'm missing of my original comment? Does pointing out another Hoplite get interpreted as disparaging or accusatory in some way? Does it go against intellectual curiosity?

rytill 2 hours ago | parent [-]

The term "conflict" implies "there is a problem here". I would say it's very lightly disparaging, because it implies the author didn't even do basic research on other things that are also named the thing they decided to call it.

I actually checked HN rules and just saw this:

> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

So, there you go, I guess.

BenceRed 3 hours ago | parent | prev [-]

Yeah, luckily they're in quite a different domain to us -- hopefully shouldn't have too much trouble winning the SEO battle

LoganDark 3 hours ago | parent | next [-]

I don't imagine they get too many Google searches anyway, but they are incredibly popular in competitive Minecraft spheres.

rirze an hour ago | parent | prev [-]

Good luck, `hoplite` triggers a ton of Minecraft media for me and that name has been around 10 years.

nzjrs an hour ago | parent | prev [-]

Your website text reads like Claude slop

BenceRed 6 minutes ago | parent [-]

Agreed, we're working with a designer and are going to be fixing this very soon. Our main focus has been on making sure the product itself looks and feels very good to use -- probably not the best approach from a marketing POV.