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.
Let’s say
You’ve built an agent locally. It runs fine withpython my_agent.py - but
the moment you close the terminal, it’s gone. Nobody else can reach it, it
has no public URL, and keeping it alive means keeping your laptop open.
Moving an agent to the internet normally means provisioning a server,
configuring networking, managing TLS, and wiring up a process supervisor.
That’s a lot of infrastructure for something that should just run.
You want to
Run the exact same script you already have - no deploy concerns added to it - on a real public URL, with its own HTTPS domain, cryptographic identity, and persistent state. Without touching any infrastructure yourself.How it works
The runtime model
A bindu agent’s runtime is where its Python process actually executes. By default that’s your own terminal (in-process). Thebindu deploy CLI lets
you run the same script elsewhere via a RuntimeProvider.
The canonical provider is BoxdRuntimeProvider, which runs the agent inside
a boxd microVM - isolated from your laptop, with its own
public URL, DID, and HTTPS domain.
Your script stays clean
No deploy concerns leak into the agent script itself:Two ways to run it - same script, different verb
Locally:[my-agent] INFO: Started server process [12]
[my-agent] INFO: Application startup complete. Inside the VM, bindu runs
bindu serve --script my_agent.py - which is
python my_agent.py plus a few CLI niceties. bindufy() serves in-process,
exactly as it does locally.
When to use each runtime
| In-process (default) | Boxd runtime | |
|---|---|---|
| How to run | python my_agent.py | bindu deploy --runtime=boxd |
| Best for | Local development | Production microservices |
| Public URL | No | Yes, HTTPS |
| Persistent state | No | Yes |
| Multi-tenant | No | Yes |
Result
A2A clients can reach the agent athttps://my-agent.boxd.sh. Ctrl-C
detaches your terminal; the VM auto-suspends after 60 seconds of inactivity.
Re-running bindu deploy resumes the same VM and pushes updated source.
Your script never changed - only the launch verb did.
Current limitations (v1)
- One runtime provider ships in-tree:
boxd. The abstraction supports others (e2b, modal, fly.io) but no additional providers are bundled yet. - No live source-watch or auto-redeploy. Editing your script requires
re-running
bindu deploy. - No declarative manifest (
bindu.toml) yet - all deploy config is via CLI flags. Planned as a follow-up.
Continue learning
- Quickstart - friendly walkthrough for your
first deploy. Start here if you’ve never used
bindu deploybefore. - Boxd runtime reference - full
bindu deployflag reference for the boxd runtime. - Custom image (A1 mode) - deploy from a user-built Docker image.
- Design rationale
- the reasoning behind the runtime abstraction.