Sandboxed builds
Build input
Every build is tied to:
organization
application
environment target
immutable source revision
runtime contract version
builder image digest
lockfile digest
No build runs against a moving branch reference such as “whatever main is now.”
Build sandbox
Each build runs in a disposable sandbox with:
- Fresh filesystem
- Fixed CPU and memory limits
- Wall-clock timeout
- No host mounts
- No production secrets
- No runtime database
- No control-plane credentials
- Restricted outbound networking
- Read-only source token
- One-time artifact upload credential
- Destruction after completion
The target implementation is:
Kubernetes Job
↓
Kata/Firecracker-style microVM RuntimeClass
with gVisor as the fallback candidate if the chosen infrastructure cannot support the preferred KVM-backed model.
The Phase 0 sandbox bake-off must validate:
- Escape resistance model
- Cold-start time
- Nuxt build performance
- Memory overhead
- Network enforcement
- Filesystem destruction
- Operational upgrade process
- Density/cost
Supported build contract
For intrnl-managed Nuxt apps:
- Supported Node version pinned by runtime contract
pnpm- Frozen
pnpm-lock.yaml - Fixed builder image
- Standard build command
- No arbitrary Dockerfile
- No privileged build
- No host socket
- No nested container daemon
External Git apps must conform to a supported manifest rather than supplying arbitrary infrastructure.
Package installation
Package installation should use a controlled npm proxy/cache.
Benefits:
- Reduced public registry dependency
- Repeatability
- Policy enforcement
- Better observability
- Ability to block known packages or sources
- Reduced arbitrary egress during installation
Post-install scripts remain possible because ecosystem packages sometimes require them, but they execute only inside the disposable sandbox.
Build pipeline
1. Fetch exact source revision
2. Validate repository structure
3. Validate intrnl.config
4. Verify supported runtime/framework version
5. Install locked dependencies
6. Generate dependency inventory/SBOM
7. Run secret scan
8. Run dependency/license/vulnerability policy
9. Type-check/lint as configured
10. Run tests
11. Analyze requested capabilities
12. Analyze migrations
13. Build Nuxt/Nitro Worker bundle
14. Separate and hash static assets
15. Run compatibility smoke test in workerd
16. Create artifact manifest
17. Sign artifact
18. Upload artifact and reports
19. Destroy sandbox
Scanner findings feed policy; they do not automatically prove an application safe.
Artifact manifest
Each artifact records:
{
"application_id": "app_01K...",
"source_revision": "def456...",
"runtime_contract": "2026-09-01",
"builder_image": "sha256:...",
"lockfile_digest": "sha256:...",
"worker_bundle_digest": "sha256:...",
"static_assets_digest": "sha256:...",
"migration_set_digest": "sha256:...",
"sbom_digest": "sha256:...",
"created_at": "...",
"signature": "..."
}
The runtime verifies the manifest and signature before activation.
No production secrets at build time
Apps must not require secrets to compile.
Public build-time settings may be supplied through a separate non-secret configuration class.
Production credentials are attached only at runtime.
Signing trust boundary
The pipeline order does not grant the untrusted build process access to an artifact signing key. The trusted signing service must authorize and bind the manifest to the recorded build and source revision. Phase 0 must specify signing protocol, key custody, verification, and revocation behavior.