Curriculum / Palantir Portfolio for Defense (Orientation)
Apollo: continuous, compliant delivery to the tactical edge
Introduction
Scenario: A defense program office needs software updates to reach forward operating sites and disconnected, air-gapped enclaves without ever breaking accreditation or requiring an open path back to a central cloud. As a portfolio-literate teammate, you orient to Apollo, the platform that delivers and operates Foundry and AIP across those environments.
Unit 6 positions Apollo at a high level: Palantir's continuous-delivery and day-2 operations platform. Where Foundry is the data operations platform and AIP is the generative-AI platform, Apollo is the layer that installs, upgrades, monitors, and maintains those services across the infrastructure they run on. In the portfolio's 'enterprise operating system' framing, Apollo is what keeps the rest of the stack current and healthy, so the people doing mission work do not have to hand-manage deployments. This unit is awareness and positioning, not a hands-on Apollo lab — you will read, diagram, and explain, not configure anything.
Apollo coordinates delivery through a pull-based hub-and-spoke model. Hubs issue Plans that describe the desired state of an environment; Spoke control-plane agents poll the orchestration engine for those Plans and apply them locally; and Releases are promoted through Release Channels with automatic rollback when a step fails. That pull-based design is the key to its defense relevance: a Spoke can reach out for instructions rather than requiring an inbound connection, which is what makes delivery to disconnected and air-gapped networks possible. Because the Spoke initiates, environments that are deliberately isolated for security can still receive governed, sequenced updates instead of being frozen at install-time versions.
Two honesty boundaries apply throughout this unit. First, Apollo's deployment state is not exposed through the Foundry read APIs this platform uses to verify learner work, so every step here is a self-attested reading, diagram, or short explainer — there is no machine-checkable artifact for Apollo. Second, specific accreditation claims (for example FedRAMP, IL5, or IL6 compliance-aware change management) appear only in marketing or search snippets and were not confirmed on the fetched Apollo docs pages; treat any impact-level claim as partial-confidence and write 'confirm against current product/accreditation docs' rather than stating it as fact. What you can assert plainly is the architecture: continuous delivery, pull-based hub-and-spoke, Release Channels with rollback, and support for connected, disconnected, and air-gapped networks.
Capability focus: Apollo as continuous delivery; hub-and-spoke + Release Channels; air-gapped/disconnected deployment relevance. · Artifact: An Apollo deployment explainer + a Hub/Spoke diagram with an air-gapped callout.
Key concepts
- Apollo: Palantir's continuous-delivery and day-2 operations platform. It manages the infrastructure and services across an environment — installing, upgrading, monitoring, and maintaining Foundry and AIP — so the platforms above it stay current and healthy without manual deployment work.
- Enterprise Operating System: the framing in which integrated AIP, Foundry, and Apollo function together as one operating system. Apollo is the delivery/operations layer of that system: it hosts and continuously updates the Foundry (data operations) and AIP (generative AI) services that mission users actually work in.
- Hub-and-spoke (pull-based) model: Apollo's coordination architecture. Hubs issue Plans describing a target state; Spoke control-plane agents poll the orchestration engine for those Plans and execute them locally. Because the Spoke pulls rather than receiving an inbound push, deployment works even where inbound connectivity is restricted.
- Release Channels: the mechanism by which Releases are promoted through environments in a controlled sequence, with automatic rollback on failure. This is how Apollo moves a known-good version forward stage by stage instead of pushing untested changes directly to production. (Channel specifics beyond promotion + rollback are cited at partial confidence — flag if pressed for detail.)
- Disconnected / air-gapped deployment: Apollo can be configured on disconnected or air-gapped networks. For defense missions this means classified enclaves and forward sites with no open path to a central cloud can still receive governed, sequenced updates — the pull-based Spoke model is what makes that possible.
- Day-2 operations: the ongoing run-and-maintain work after initial install — upgrades, patching, health monitoring, and rollback. Apollo automates these so that keeping Foundry and AIP current is a managed, repeatable process rather than a one-off manual effort per site.
- Impact-level / accreditation claims (partial confidence): statements that Apollo provides compliance-aware change management aligned to FedRAMP, IL5, or IL6 appear only in marketing/search snippets and were not confirmed on the fetched docs pages. Present these as 'confirm against current product/accreditation docs,' never as established fact.
Companion video
Palantir Apollo 2023 | Mission Control for Software Deployment · open on YouTube
Hands-on activity
each step validates · the unit completes when all steps pass- 1
Read the Apollo introduction and how-it-works pages
Read the Apollo introduction ('Welcome') and the 'How Apollo works' pages, then self-attest you can state Apollo's role and core mechanism in your own words. The introduction frames Apollo as Palantir's continuous-delivery and day-2 operations platform that can be configured on disconnected or air-gapped networks; the how-it-works page describes the pull-based model in which Spoke control-plane agents poll the orchestration engine for Plans, Hubs issue those Plans, and Releases are promoted through Release Channels with automatic rollback on failure. This is a reading deliverable — Apollo's state is not observable through the Foundry read APIs this platform checks, so capture the key sentences (continuous delivery, day-2 operations, pull-based) as your self-attested takeaway rather than expecting a system to verify it.
not startedself-attestedSelf-attested: you can state Apollo is the continuous-delivery / day-2 operations platform.
- 2
Draw the Hub/Spoke + Release Channel model
Draw a simple Hub/Spoke + Release Channel diagram and self-attest it shows the three moving parts correctly: a Hub that issues Plans, one or more Spokes whose control-plane agents poll the orchestration engine and execute Plans locally, and a Release Channel along which a Release is promoted stage by stage with automatic rollback if a step fails. Make the direction of initiation explicit — the Spoke pulls — because that arrow is the whole point of the model. You may label Release Channels and the promotion/rollback flow, but note on the diagram that channel specifics beyond 'promote with rollback' are cited at partial confidence; keep the annotation to what the docs state and flag anything you are inferring. This is a self-attested sketch; there is no Apollo artifact to machine-verify here.
not startedself-attestedSelf-attested: your diagram shows Hubs issuing Plans, Spokes polling/executing, and Release Channels.
- 3
Explain air-gapped / disconnected deployment relevance
Write a short explainer on why disconnected and air-gapped delivery matters for defense, and self-attest it. Explain that Apollo can be configured on disconnected or air-gapped networks, and connect that to the pull-based design from the prior step: because a Spoke reaches out for Plans rather than requiring an inbound connection, classified enclaves and forward/tactical sites isolated for security can still receive governed, sequenced updates instead of being stranded on install-time versions. Cover connected, disconnected, and air-gapped as the three deployment situations. Important honesty boundary: if you mention accreditation or impact levels (FedRAMP, IL5, IL6), mark them as partial-confidence and write 'confirm against current product/accreditation docs' — those claims surfaced only in marketing/search snippets and were not confirmed on the fetched Apollo docs pages, so do not assert them as fact.
not startedself-attestedSelf-attested: you can explain Apollo can deploy to disconnected/air-gapped networks (flag IL claims).
- 4
State Apollo's role in the platform stack
State Apollo's role in the overall platform stack and self-attest the recall. In one or two sentences, explain that Apollo manages the underlying infrastructure and services that host Foundry and AIP — installing, upgrading, and operating them — so the data operations platform (Foundry) and the generative-AI platform (AIP) stay current and healthy without per-site manual deployment. Tie it back to the 'enterprise operating system' framing: Apollo is the continuous-delivery/operations layer beneath the platforms mission users work in. This is a recall deliverable; Apollo exposes no Foundry read-API surface to this platform's runner, so it is self-attested rather than instance-confirmed.
not startedself-attestedSelf-attested: you can explain Apollo manages the infrastructure hosting Foundry/AIP/Gotham.