A cloud sandbox for every coding agent
Every Hoplite cloud thread gets its own isolated cloud sandbox with your repository, environment variables and setup script. The agent installs dependencies, runs your tests, starts the dev server and drives a browser against it, in a workspace of its own.
What is a cloud sandbox for coding agents?
A cloud sandbox is an isolated development environment where a coding agent does real work: it checks out the repository, installs dependencies, runs commands and starts the app. The agent works against a real checkout instead of guessing from snippets, and nothing it runs touches your own machine.
In Hoplite, every cloud thread gets its own sandbox. Hoplite clones the repository, injects the project's environment variables and runs your setup script. The workspace stays with the thread across follow-ups, so the next message picks up the same files and history.
Your repository, secrets and setup, every time
Each new thread clones the repository and runs the setup script from .hoplite/settings.json, or an override in project settings. Environment variables are stored encrypted, never shown again after saving, and injected into every command the agent runs, from setup to tests.
Setup runs while the agent reads
Before your script, Hoplite installs the toolchains your repository declares, such as the Node version in .nvmrc or Go from go.mod. Setup doesn't hold up the run: the agent starts reading and searching the code straight away, and commands wait until setup finishes.
Room to do the whole job
The agent installs dependencies, runs your test suite, starts the dev server and drives a browser against it. Compute scales up and down with the work, and repositories that use Docker Compose, Supabase or Testcontainers get a runtime with a private Docker daemon.
Kept for the thread, apart from the rest
Follow-ups in a thread reuse the same workspace, so files, dependencies and history carry over, while separate threads never share one. An idle workspace is archived and restored when the thread continues, and if a runtime fails, Hoplite restores its latest snapshot.
Laptop agent vs. Hoplite sandbox
| Question | Agent on your laptop | Hoplite cloud sandbox |
|---|---|---|
| Where commands run | On your machine, in your checkout | In an isolated sandbox for the thread |
| Several tasks at once | Separate worktrees you set up yourself | Every thread gets its own workspace |
| Environment | Whatever is installed locally | Declared toolchains and your setup script, in every thread |
| Secrets | Your whole shell environment | Project variables, encrypted at rest and injected into commands |
| Sharing the running app | localhost on your machine | A preview link for workspace members |
| Follow-ups | Your current checkout | The same workspace, files and history |
Sandboxes, answered
- What's inside a Hoplite sandbox?
- The checked-out repository, its dependencies, your project's environment variables and the runtime tools the agent needs. It can also hold a short-lived GitHub credential limited to the project's repositories, stored privately for git and gh.
- Does every message start a new sandbox?
- No. Follow-up runs in a thread use the same workspace, so files, installed dependencies and history carry over. Separate threads get separate workspaces.
- How do I configure setup?
- Commit a .hoplite/settings.json with setup, run and archive commands and a preview port, or set them under Settings → Project → Environment. A setting saved in Hoplite overrides the repository file.
- Can code in the sandbox read my secrets?
- Yes, by design. Variables are encrypted at rest and can't be viewed after saving, but they're injected into every command, so code running in the sandbox, including dependencies and tests, can read them. Add only what the project needs.
- Can the agent run Docker Compose?
- Yes. Hoplite picks a runtime with a private Docker daemon when the repository uses Docker Compose, Supabase, Testcontainers or similar tools, or you can choose it under Settings → Project → Sandbox. Privileged containers aren't allowed, so kind clusters can't run there.
- What happens when a sandbox sits idle?
- It's archived and restored the next time the thread continues. Files are kept; running processes such as previews may need restarting. If a runtime fails, Hoplite restores the latest snapshot, which may not include the most recent unpushed changes.
- What if a build runs out of memory?
- Compute scales with the workload, so heavy installs and builds usually need no resize. If a command is killed for running out of memory, Hoplite moves the sandbox up one size automatically, within your plan's limits.
Give every task a sandbox of its own
Connect a GitHub repository, add your setup script and start a thread. Start on Free.