You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ADK doesn't have many sandboxed local alternatives for code execution. The only option is ContainerCodeExecutor which relies on Docker. Beyond requiring a Docker daemon to be available, it can also add complexity in production, especially when the app or agent is already running inside a container. Nested containers (DinD) require elevated privileges, which can compromise the isolation and defeat the very purpose of sandboxing.
Proposed solution
The solution I'm proposing is based on Vpod, an open-source project I maintain. A vpod is a tiny Linux sandbox that runs inside WebAssembly for untrusted processes. It uses snapshots with preinstalled libraries to start fast and avoid setup complexity.
Here's an example of what the code execution inside a VpodCodeExecutor could look like:
fromgoogle.adk.agentsimportAgentfromvpod_adkimportVpodCodeExecutoragent=Agent(
name="secure_coder",
model="gemini-2.0-flash",
instruction="Execute Python code in a secure sandbox.",
code_executor=VpodCodeExecutor(snapshot="vsnap-data"), # numpy/pandas/scipy preinstalled
)
Under the hood, it's a thin wrapper over Vpod's Python SDK:
fromvpodimportSandboxwithSandbox.create(snapshot="vsnap-data") assandbox:
sandbox.code.run("import pandas as pd")
result=sandbox.code.run("print(pd.Series([1,2,3]).sum())")
print(result.text)
Sandboxes are highly portable and work on any OS or environment. They also can be suspended and resumed on disk without any background process or daemon.
Trade-offs, up front
Vpod is based on RISC‑V emulated in WASM and doesn't benefit from hardware acceleration, so CPU‑heavy workloads might run slower than native. It's mainly aimed at safely running typical agent-generated code, not at max-throughput compute.
I'm curious whether anyone here has run into this with Docker and ContainerCodeExecutor in production. If so, I'd love to hear how you worked around it.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Problem
ADK doesn't have many sandboxed local alternatives for code execution. The only option is
ContainerCodeExecutorwhich relies on Docker. Beyond requiring a Docker daemon to be available, it can also add complexity in production, especially when the app or agent is already running inside a container. Nested containers (DinD) require elevated privileges, which can compromise the isolation and defeat the very purpose of sandboxing.Proposed solution
The solution I'm proposing is based on Vpod, an open-source project I maintain. A
vpodis a tiny Linux sandbox that runs inside WebAssembly for untrusted processes. It uses snapshots with preinstalled libraries to start fast and avoid setup complexity.Here's an example of what the code execution inside a
VpodCodeExecutorcould look like:Under the hood, it's a thin wrapper over Vpod's Python SDK:
Sandboxes are highly portable and work on any OS or environment. They also can be suspended and resumed on disk without any background process or daemon.
Trade-offs, up front
Vpodis based on RISC‑V emulated in WASM and doesn't benefit from hardware acceleration, so CPU‑heavy workloads might run slower than native. It's mainly aimed at safely running typical agent-generated code, not at max-throughput compute.I'm curious whether anyone here has run into this with Docker and
ContainerCodeExecutorin production. If so, I'd love to hear how you worked around it.Here's more information about Vpod:
pip install vpodBeta Was this translation helpful? Give feedback.
All reactions