Project templates on top of the agent template #5

New issue

Open

opened 2026-10-01 09:20:28 +00:00 by jan · 0 comments

jan commented

2026-10-01 09:20:28 +00:00

Owner

Motivation

Some projects need heavy, project-specific tooling in the VM: a database
server, a DCC application, language runtimes. That does not belong in the
shared agent template, but installing it by hand in each sandbox is lost on
every remove && create and needs a wide network allowlist at runtime.

Proposal

A project template is built from the agent template plus a provisioning
script that the project provides (referenced from the manifest, see
#3 (Multi-repo projects: design)):

./scripts/build-template.sh --from jan-agent-shell:v1 \
    --provision path/to/provision.sh --name myproject:v1 \
    --network "deb.debian.org,..."

Builder network allowlist scoped to the throwaway builder, as today.
audit-template.sh runs on the result, as today: a project template must
not capture credentials either. This matters more here, because a
provisioning step may log in to something (a license server, a registry).
agentbox create uses the manifest's template when set.
Large artifacts (installers of several GB) are read from a host path at
build time, not downloaded in the VM, so the builder allowlist stays small.

To evaluate first

sbx kit mixins (experimental in 0.46) declare network policies, env vars,
startup commands and files. A kit might cover the "start a service when the
sandbox starts" part better than a template does. Template for the heavy
install, kit for the runtime wiring?

Done when

The e2e suite builds a small project template (e.g. one extra package) and
creates a sandbox from it.

## Motivation Some projects need heavy, project-specific tooling in the VM: a database server, a DCC application, language runtimes. That does not belong in the shared agent template, but installing it by hand in each sandbox is lost on every `remove && create` and needs a wide network allowlist at runtime. ## Proposal A project template is built **from** the agent template plus a provisioning script that the project provides (referenced from the manifest, see #3 (Multi-repo projects: design)): ```bash ./scripts/build-template.sh --from jan-agent-shell:v1 \ --provision path/to/provision.sh --name myproject:v1 \ --network "deb.debian.org,..." ``` - Builder network allowlist scoped to the throwaway builder, as today. - `audit-template.sh` runs on the result, as today: a project template must not capture credentials either. This matters more here, because a provisioning step may log in to something (a license server, a registry). - `agentbox create` uses the manifest's template when set. - Large artifacts (installers of several GB) are read from a host path at build time, not downloaded in the VM, so the builder allowlist stays small. ## To evaluate first `sbx kit` mixins (experimental in 0.46) declare network policies, env vars, startup commands and files. A kit might cover the "start a service when the sandbox starts" part better than a template does. Template for the heavy install, kit for the runtime wiring? ## Done when The e2e suite builds a small project template (e.g. one extra package) and creates a sandbox from it.

jan referenced this issue

2026-10-01 09:20:29 +00:00

sbx 0.46 compatibility: --no-share-skills is gone #2

jan referenced this issue

2026-10-01 09:20:31 +00:00

Project-local PostgreSQL inside the VM #7

jan referenced this issue

2026-10-01 09:20:31 +00:00

Spike: headless Autodesk Maya (mayapy) in a project template #8

jan referenced this issue

2026-10-01 09:20:31 +00:00

Roadmap: multi-repo work project on Windows #10