Install sandbox dependencies as a controlled task stage

Inspect before installing

Start by identifying the program and runtime the task needs, then inspect the actual sandbox with small bounded commands. A provider may document a useful default toolset, but the task should not assume every version or package is present. Lupin's container interface does not expose a package-management abstraction; dependency preparation happens through the commands you authorize. Choose the smallest dependency set that can complete the work. Installing a broad development environment for a one-file transformation adds network activity, setup time and potential failure without necessarily improving the deliverable.

Use manifests as task inputs

Upload a reviewed package manifest and lockfile when the ecosystem supports them. Pin versions according to the project's existing convention rather than resolving latest merely because the sandbox is temporary. Preserve the manifest's digest with the task record so another run can identify the same dependency input. If the project already has a reproducible installation command, use it instead of inventing another resolver path. A lockfile can reduce version drift, but platform differences and external package availability can still matter. Record the actual installed runtime and package-manager versions when they affect the result.

Keep credentials and scripts under control

Private registries may require credentials, which should be narrowly scoped and introduced through an approved mechanism. The hosted adapter uses noEnv true, so operator account secrets are not inherited automatically; this is a boundary to preserve. Do not paste provider API keys into an installation command. Package installation can execute lifecycle scripts or fetch additional resources, so treat an untrusted manifest as executable input. The fact that it runs in a sandbox does not authorize unrelated network operations. Review the dependencies needed for the user's task and avoid copying a whole local credential directory as a shortcut.

{"command":"python -c 'import sys; print(sys.version)'","timeout_seconds":30}

Bound time and diagnostic output

Dependency installation consumes resource runtime before the main job begins. Give it a realistic bounded stage and leave time to verify, export and stop. The command request timeout, provider request deadline and resource lease are separate limits, so a lost response can leave installation status uncertain. Inspect the environment and command history before starting another installation attempt. Keep verbose logs in a named location and return a concise sanitized diagnostic summary. Preserve the actual exit code instead of letting a final log-formatting utility make a failed installation look successful to the agent.

Verify readiness with the intended program

After installation, import the required library or run the relevant tool's version and a small task-specific check. A package manager's success message does not establish that the application can load its native extension or resolve its configuration. Record the checks actually performed and any unresolved compatibility issue. Then execute the main task against the pinned inputs and retain the final artifact independently of the sandbox. Stop idle runtime after completion. Dependency preparation is successful when the required workload runs under observed conditions, not simply when an install command returns a large plausible-looking log.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

• docs.boat.dev · environments ↗Checked 2026-11-05
• docs.boat.dev · environments · secrets ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.