Introduction

Scenario: Your mission command app reads, aggregates, and acts on the supply-chain Ontology, but it still only runs on your machine; the watch floor needs it served from the enrollment so operators can open a URL and triage disruptions. In this unit you host the frontend-only OSDK React app on Foundry web hosting so it loads live Ontology data from a stable enrollment subdomain.

By now you have a working OSDK React single-page app that authenticates, searches and aggregates Ontology objects, applies Actions, and executes a published query. This unit takes that app off your laptop and puts it where the mission can reach it: Foundry web hosting. Foundry web hosting serves frontend-only OSDK applications as static assets - it is closer to GitHub Pages than to a Node server, so there is no backend process you can run on it. That is by design: in the OSDK architecture Foundry is the backend, and your hosted bundle is pure client-side code (HTML, CSS, JavaScript) that calls the Ontology REST API v2 from the operator's browser using the OAuth2 client you configured in Developer Console.

The deployment flow is deliberately small. You produce a production build (a dist/ directory), zip it, and upload it as a new version through the Developer Console hosting UI or with the @osdk/cli. You can preview that version, then deploy it to production, where it is served from your enrollment subdomain. Note one cohort assumption up front: this track expects coding-capable developers (TypeScript/React plus OAuth2), so we treat producing and building the bundle as a known skill and focus the teaching on what hosting does, what it confirms, and what it does not. Because this is an advanced unit, the honesty discipline matters more here than anywhere else: most of what you ship is client-side and is not visible to any documented Foundry READ API.

That last point shapes how this unit is verified. The only documented, read-confirmable signal about your deployment is that the hosted-application resource exists at its project path - resolvable with Filesystem v2 Get By Path. That existence check cannot tell you which website version is live, whether the subdomain actually serves it, or whether the page rendered correctly for an operator; it only confirms the application resource is present. The repository contents, the production bundle, the OAuth2 client configuration, and the browser-rendered page are all outside the READ-API surface, so they are attested manually. What you can still prove with confidence is the Ontology the app consumes - the object types and aggregates from earlier units - but hosting itself is mostly demonstrated, not machine-confirmed. Keep that distinction sharp in your handoff notes.

Capability focus: Static-asset build + upload; Developer Console / @osdk/cli deploy; hosted-application resource on an enrollment subdomain. · Artifact: A deployed, live website served from a Foundry enrollment subdomain.

Key concepts

Companion video

1. 1

   Build static assets and upload a new version

   Produce the production build of your OSDK React app (the dist/ directory), zip it, and upload it as a new version using either the Developer Console hosting UI or the @osdk/cli. Foundry web hosting serves static assets only - there is no server process - so the bundle must be a self-contained set of HTML, CSS, and JavaScript that calls the Ontology REST API v2 from the browser. Preview the uploaded version, confirm it loads, then deploy it to production on your enrollment subdomain. This step is self-attested: the build, the zip, the uploaded version, and the deploy state are all client-side and Developer Console hosting artifacts, and no documented Foundry READ API exposes them, so you record that you completed the build-upload-preview-deploy loop rather than proving it through the Ontology API.

   not startedself-attested

   Mark complete

   Self-attested: the production build is zipped and uploaded/deployed via Developer Console or @osdk/cli.

2. 2

   Confirm the hosted application resource exists

   Confirm that the hosted-application resource exists by resolving it at its expected project path with Filesystem v2 Get By Path (GET /api/v2/filesystem/resources/getByPath). The Developer Console application backing your deployment is itself a Foundry resource, so a successful path resolution is real, machine-checkable evidence that the application resource is present. Be precise about what this proves and what it does not: it is an existence-only check, so it cannot confirm which website version is live, that the enrollment subdomain is actually serving your bundle, or that the page renders for an operator - those remain in the next, manual step. Note also that the exact Filesystem-v2 resourceType enum for a Developer Console hosted application is an assumption to confirm at build time; treat the resource's presence at its path as the load-bearing signal.

   not startedinstance check

   Run check

   Confirms the hosted application resource resolves at its expected project path (existence-only; enum confirm-at-build).

3. 3

   Verify the deployed site loads and reads the Ontology

   Open the deployed enrollment-subdomain URL in a browser, sign in through the OAuth2 client, and confirm the SPA loads and renders live Ontology data - for example the late-shipment list and the total-exposure metric from earlier units, served now from the hosted site rather than your local dev server. This step is self-attested because browser-level site verification is outside the Foundry READ-API surface: no documented READ API can confirm that the subdomain served your bundle, that authentication succeeded in the browser, or that the page rendered correctly. The Ontology data behind those views is read-confirmable (and was confirmed in earlier units), but the act of the hosted page loading and displaying it is demonstrated to a reviewer, not machine-confirmed. Record the live URL and what an operator sees so the deployment can be re-verified by hand.

   not startedself-attested

   Mark complete

   Self-attested: the enrollment-subdomain URL loads the SPA reading live Ontology data.