Skip to content
Agile Defense

Deployments: Two ways to deliver Foundry Foundations

The platform ships to customers on two paths. The enclave container carries the current stack across an air gap and runs it adjacent to Foundry — available as soon as a class needs it. The Foundry-native re-platform moves the whole product inside Foundry itself — the long-term home. This page positions the two so every FDE can pick and explain the right one.

Enclave container: Spec approved — ready to implementFoundry-native: Planned — future

Head-to-head

Same curriculum, same validation contract, same design system — different homes.

DimensionEnclave containerFoundry-native
AvailabilitySpec approved — ready to implementPlanned — after current-stack work completes
HostingDocker container adjacent to Foundry on an enclave hostStatic SPA hosted by Foundry Developer Console
DataSQLite on a mounted volumeOntology object types via OSDK
AuthEmail + password with per-class rostersFoundry identity; roles from platform groups
ValidationLive adapter with the class's namespace root (fixture mode for dry runs)Namespace-parameterized Foundry Functions
AIP helperPythia via /api/helper (mock or configured provider)AIP Logic / Agents, Ontology-grounded
DistributionAir-gapped tarball — docker save/load with sha256 verificationMarketplace package
UpgradesLoad the new tarball; entrypoint re-syncs schema; data survives on the volumeMarketplace versioning

Option A — Enclave container

A single container image, built in a connected environment and carried across the air gap as a checksummed tarball. One enclave hosts one class; validation runs against the customer’s Foundry with the class’s namespace root.

Boot behavior
The entrypoint re-syncs the schema idempotently on every start and seeds only on first boot — a live class’s data is never clobbered. Upgrades are just a new image over the same volume.
Packaging & transfer
One script builds the image and emits a versioned tarball with a sha256 companion. Verify the checksum after transfer, docker load, configure an env file, docker compose up -d.
Operations
The enclave’s reverse proxy terminates TLS; the container needs no network egress at runtime. Backup is the volume’s single SQLite file. Health at /api/health.

Option B — Foundry-native

The re-platform: Developer Console hosts a static SPA; the Ontology holds the data; Functions run validation and live sessions; Pythia becomes AIP-native; the whole product installs from Marketplace. No container, no separate host, no separate login.

Component migration map

How each current component reaches its Foundry-native counterpart.

TodayFoundry-nativeHow

Course content modules

src/content/* typed TSX

Same modules, bundled into the SPAPorts as-is

Design system

@foundry-curriculum/design-system

Same package, same tokensPorts as-is

Next.js pages (SSR)

Server components, force-dynamic

Static SPA routes fetching via OSDKRe-implemented

Prisma models

User · ValidationRun · LiveSession · Class · Enrollment

Ontology object types + linksReplaced

API routes

/api/live · /api/validate · /api/helper · /api/classes

Foundry Functions (typed, ontology-aware)Re-implemented

Validation checks

Per-step checks against Foundry APIs

Namespace-parameterized Functions running in-platformRe-implemented

Email + password auth

Per-class rosters, scrypt hashes

Foundry identity; roles from platform groupsReplaced

Pythia helper

Mock client + live-context grounding

AIP Logic/Agents with the same grounding contractReplaced

Sequencing

Six phases to Foundry-native, each with a hard exit criterion. The enclave container is the delivery vehicle until Phase 6 completes.

  1. Phase 1: Foundation

    Static SPA shell; content modules and design system port; mock data layer.

    Exit: Full catalog browsable from Developer Console with zero server.

  2. Phase 2: Data

    Ontology object types defined; OSDK reads/writes replace Prisma.

    Exit: Progress and validation runs persist in the Ontology.

  3. Phase 3: Functions

    Validation checks and live-session logic as Foundry Functions.

    Exit: A step validates against a real enclave namespace.

  4. Phase 4: Identity

    Foundry SSO; roles from groups; password auth deleted.

    Exit: No credential or session code remains in the app.

  5. Phase 5: Helper

    Pythia backed by AIP Logic/Agents; mock kept for local dev.

    Exit: Helper answers with live Ontology grounding in-platform.

  6. Phase 6: Packaging

    Marketplace package; install & upgrade docs.

    Exit: Clean install into a fresh enclave passes the smoke checklist.

References

Official Palantir documentation grounding both paths. The full specs live in the repo at docs/superpowers/specs/2026-07-02-enclave-container-deployment-design.md and docs/superpowers/specs/2026-07-02-foundry-native-architecture-design.md.