Documentation Index
Fetch the complete documentation index at: https://docs.getbindu.com/llms.txt
Use this file to discover all available pages before exploring further.
Mess might happen when
Some agents can’t rely on a plainpip install at deploy time:
- Native deps that require a Rust toolchain or system libraries.
- CI/CD pipelines that already produce container images.
- Teams that need pinned, auditable, reproducible deploys.
What to do then?
Get bindu to boot your agent from a Docker image you built and pushed, instead of packaging your source folder and runningpip install inside
the VM.
How to do it
1. Write a Dockerfile
2. Build and push to a registry
Push to any public registry, or a private one with credentials configured on your boxd account (e.g.ghcr.io, Docker Hub, ECR).
3. Deploy with --image
--image is set, bindu changes its behaviour in three ways:
- No source upload - your folder stays on your machine.
- No
pip installstep - deps are already baked into the image. - Image
CMDis the entrypoint - whatever you put inCMDstarts the agent.
You see that
Your agent boots from a pinned, reproducible image with full control over every system dependency. Here’s how that compares to the default A2 mode:| A2 (source mount) | A1 (custom image) | |
|---|---|---|
| Setup | None - just run | Build + push image |
| Iteration speed | Fast (1–3s warm) | Slow (build + push + redeploy) |
| Reproducibility | Depends on pip install resolving the same deps | Pinned by image hash |
| Native deps | Limited to what pip install can build in the VM | Anything that builds at image time |
| Image registry needed | No | Yes |