Last updated: October 14, 2026
TL;DR Running Foundry in production means managing models through Modeling Objectives with staging and production releases, choosing batch or live deployments on purpose, connecting external models through adapters, and watching everything with Data Health and monitoring views that alert to PagerDuty or Slack. Foundry doesn’t ship automatic drift detection, so you build it. Idle live deployments quietly burn compute. Our platform operations and MLOps team runs this work.
Palantir Foundry MLOps is the practice of training, releasing, deploying, and monitoring models inside Foundry, using Modeling Objectives for governed releases, batch or live deployments for serving, and Data Health and monitoring views for alerts.
Building a model is the fun part. It’s also the small part.
A widely cited Google paper, Hidden Technical Debt in Machine Learning Systems, argued back in 2015 that only a small fraction of a real-world ML system is the ML code, and that these systems carry massive ongoing maintenance costs. The rest is data collection, serving, monitoring, and everything else that keeps the model useful after launch day.
Foundry handles more of that surrounding work than most platforms. It doesn’t handle all of it. This guide covers the model lifecycle in Foundry, how to pick between deployment types, how external models fit, what monitoring is built in and what isn’t, how changes move safely to production, and how to keep compute costs from creeping. It’s written for data science and platform leads who own Foundry after go-live.
What Does MLOps Look Like Inside Foundry?
It centers on Modeling Objectives, which Palantir calls mission control for model management, evaluation, review, release, and deployment. Models are trained in Foundry or brought in from outside, submitted to an objective, evaluated, released, deployed, and then bound to the Ontology.
Palantir’s model integration overview describes objectives exactly that way, and says models can be imported as libraries, artifacts, containers, or APIs. Once deployed, models can be registered for use in the Ontology layer, which is where they start driving decisions in apps and agents.
Here’s the lifecycle, start to finish.
| Stage | Foundry tool | What happens |
|---|---|---|
| Train | Code Workspaces, Code Repositories, or Model Studio | A model is built on Foundry data |
| Submit | Modeling Objective | A model version becomes a candidate, like a pull request |
| Evaluate | Objective evaluations | Metrics are generated on evaluation datasets |
| Release | Staging and production releases | An accepted version is tagged for an environment |
| Deploy | Batch or live deployment | The model scores data or serves an endpoint |
| Bind | Functions on models, Ontology | Apps, Actions, and agents use predictions |
| Monitor | Data Health, monitoring views, Workflow Lineage | Failures and slowdowns trigger alerts |
Google Cloud’s well-known MLOps maturity levels are a useful yardstick. Level 0 is entirely manual. Level 1 automates continuous training. Level 2 adds a fully automated CI/CD system. Most Foundry teams we meet sit between 0 and 1. The tools for level 2 are mostly there. The habits usually aren’t.
How Do Modeling Objectives, Releases, and Environments Work?
An objective collects candidate model versions for one problem. Teams submit versions, compare them on evaluation data, then release the winner to staging or production. Each release automatically upgrades every deployment in that environment and leaves an auditable history.
The objectives documentation describes an objective as a catalog of potential production-worthy model versions, and releases as accepted solutions to the modeling problem. Each release carries an environment tag such as Staging or Production.
The release docs add the details that matter day to day.
- Every release needs a release number and a release note. Write real notes. Future you will read them during an incident
- Staging deployments let you test downstream uses before production
- Promotion is a click on Mark as production
- Each new release overwrites the previous one for that environment and upgrades all its deployments automatically
- Once a submission is released, it can’t be archived
Read the fourth bullet again. Releasing to production upgrades everything in production at once. That’s convenient, and it’s why the staging step isn’t optional for anything users depend on.
One legacy warning. Palantir says the foundry_ml library and dataset-backed models have been fully deprecated since October 31, 2025, and models built in Code Workbooks need rebuilding in Code Workspaces or Code Repositories. If you inherited an older Foundry estate, check for these first.
Batch vs Live Deployment, Which Should You Use?
Batch for scoring data on a schedule, like nightly demand forecasts or weekly risk scores. Live for on-demand predictions inside apps, Actions, or agents. Live deployments reserve compute the whole time they run, so only go live when users truly need an instant answer.
Palantir’s what to use guide lays out the options. Here’s the practical version.
| Option | Best for | Strength | Watch out for |
|---|---|---|---|
| Objective batch deployment | Scheduled scoring on datasets | Governed releases, simple to monitor | No multi-output or external models |
| Batch inference in Pipeline Builder or Python transforms | Scoring inside an existing pipeline | Lives with the rest of your data logic | Less release governance by default |
| Model direct deployment (live) | Quick iteration, variable traffic | Auto-upgrades and auto-scales with request volume | Fewer release controls |
| Objective live deployment | Production endpoints behind apps and agents | Staging and production releases, uptime monitoring | Fixed resources, no Marketplace deployment |
| Functions on models | Using live models in Ontology functions and Workshop | No-code binding to the Ontology | Needs a live deployment underneath |
Live deployments come with limits worth planning around. Per Palantir’s live deployment FAQ, requests accept up to 50 MB by default, a five-minute timeout applies, each deployment runs 2 replicas by default so upgrades happen without downtime, and GPU support for Python models is in beta.
Our default question is simple. Does a person or agent need this answer in under a second? If not, batch it. Most forecasting work, including our time-series forecasting builds, runs perfectly well in batch.
Can You Use SageMaker, Azure ML, Vertex AI, or Databricks Models in Foundry?
Yes, as externally hosted models. You connect them through a model adapter, an egress policy, and stored credentials. They get Foundry versioning, permissions, lineage, live deployment, and Ontology binding, but not batch deployments or automatic evaluation in objectives.
Model adapters are Palantir’s general framework for working with any model. An adapter loads the model and defines its predict method and its input and output schema. That’s what lets a Foundry function call a model without caring where it was trained.
The external model connection docs name Azure ML, SageMaker, OpenAI, and Vertex AI, with examples including Databricks. Credentials are encrypted, and users can run inference without having direct access to the external model.
The limits matter. Externally hosted models don’t support batch deployments or automatic evaluation inside objectives. For batch work, Palantir points to Python transforms with an egress policy instead.
When should you leave a model outside Foundry? When a mature data science team already trains, tracks, and serves it well somewhere else. Bring it into Foundry for the Ontology binding and the governance, not to move the training. Our comparison of Foundry, Databricks, and Snowflake covers how those platforms usually split the work.
How Do You Monitor Foundry in Production?
With Data Health checks on datasets, schedules, and tables, and monitoring views on everything else, including live deployments, functions, Actions, agents, automations, and streams. Both can alert to PagerDuty, Slack, or webhooks with low, medium, or high severity.
Our Pipeline Builder guide covers Data Health on pipelines. In production, the bigger shift is monitoring views.
Data Health checks cover dataset status, time, size, content, and schema, and work on datasets, schedules, and tables. For anything else, the docs point you to monitoring views. Note that health check groups are being sunset, so new setups should skip them.
Monitoring views bundle monitoring rules and health checks, and they can be dynamic, updating automatically as resources are added or removed. Rules cover live deployments, functions, agents, Action types, automations, streaming datasets, schedules, and object types, and alerts can go to PagerDuty or Slack.
Then there’s observability. Workflow Lineage keeps 7 days of execution history and logs, and function, Action, and AIP Logic metrics show near real-time success and failure counts plus P95 execution time over 30 days.
Our starting monitoring set for any production workflow.
- A freshness check on every dataset a model or app reads
- Schema checks on raw inputs from source systems
- Uptime monitoring on every live deployment users depend on
- Failure rate and P95 latency rules on key functions and Actions
- A dynamic monitoring view per project, so new resources get covered automatically
- A named owner and a severity for every alert
Number six is the one that decides whether the other five matter.
Does Foundry Detect Model Drift Automatically?
Not as a documented built-in feature. Foundry gives you the parts, including evaluations, scheduled batch scoring, monitoring rules, and datasets of predictions and outcomes, but drift detection is something you design and wire up yourself.
We looked. Palantir’s documentation covers evaluation, deployment health, uptime, and data quality in depth, but we found no docs page describing automatic drift detection for models. Some older marketing material talks about drift. The docs don’t.
That’s not a dealbreaker. It’s a design task. Google’s MLOps guidance notes that models can decay in more ways than conventional software, and the fix is the same anywhere.
Here’s the pattern we build.
| Check | How we build it in Foundry | Alert when |
|---|---|---|
| Input drift | Scheduled transform comparing this week’s feature distributions to the training baseline | A key feature shifts past an agreed threshold |
| Prediction drift | Health checks on the prediction output dataset | Average score or class mix moves sharply |
| Performance decay | Join predictions to actual outcomes once known, rerun evaluations | Accuracy or error drops below the release benchmark |
| Business impact | Ontology metrics on decisions made with the model | Overrides by users spike |
The last row is our favorite and the most ignored. When planners start overriding a forecast far more than usual, the model is telling you something before any statistic does.
How Do Changes Move Safely From Development to Production?
With Global Branching for changes that span pipelines, the Ontology, and apps, staging releases for models, and DevOps packaging with release channels for promoting whole products between environments. Apollo handles software delivery underneath.
Three Foundry tools share this job.
Global Branching, formerly Foundry Branching, lets you develop and test end-to-end workflows on one branch. A pipeline change and a new object type can live on the same branch, go through per-resource approvals, and merge to main together. That’s the right tool for most day-to-day changes.
Foundry DevOps packages Ontology, AI models, pipelines, data connections, or whole use cases as products, with release channels, maintenance windows, and automatic upgrades. Use it when you promote between separate spaces or ship the same workflow to several business units. One limitation from the deployment docs. Objective live deployments don’t support deployment through Marketplace, so plan those separately.
Apollo sits under all of it. Palantir describes it as a platform for managing and deploying software across independent environments, upgrading them based on release channel subscriptions, within constraints that developers and environment owners set. Our Palantir platforms explainer covers where Apollo fits next to Foundry and AIP.
For LLM functions specifically, the release path adds eval suites and staged writes. Our guide to AIP Logic and Evals walks through it.
How Do You Keep Production Compute Costs Under Control?
Watch live deployments first. They reserve compute for as long as they run, whether anyone calls them or not. Stop idle staging deployments, right-size resources after stress testing, and prefer batch or auto-scaling direct deployments where traffic is low or uneven.
Palantir’s compute usage page for models is unusually direct. Live deployments continuously reserve dedicated compute and use compute-seconds while active. Objective live deployments use compute regardless of request volume, while direct deployments scale with traffic. Over-resourcing a deployment uses more compute than necessary, and live deployments run until someone explicitly stops them.
That last line is how budgets leak. A staging endpoint stood up for a two-day test, still running four months later. We find at least one on almost every Foundry estate we review.
Our quick cost checklist.
- List every live deployment and its owner every month
- Stop staging deployments when testing ends
- Stress test, then shrink resource profiles to what the load needs
- Move low-traffic, latency-tolerant models to batch
- Make pipelines incremental before tuning anything else
Our Foundry pricing guide explains how compute-seconds convert into what you actually pay.
Who Should Own Foundry in Production?
A small platform team that owns monitoring, releases, and cost, working alongside use case owners who own the decisions and the data. Without a named platform owner, alerts go unread and costs creep within months.
Good ownership looks like this.
- One platform lead accountable for monitoring views, release process, and compute
- A named owner for every model, live deployment, and production pipeline
- Use case owners on the business side who sign off on model releases
- A weekly 30-minute review of alerts, failures, and spend
If you’re a team of three running one use case, that’s probably the same two people wearing every hat. Fine. Just write it down.
Treat Production as a Product
Three takeaways. Use Modeling Objectives and staging releases for anything users depend on, because production releases upgrade every deployment at once. Monitor with Data Health and dynamic monitoring views, and build drift detection yourself since Foundry doesn’t do it for you. And audit live deployments monthly, because idle endpoints are the most common cost leak.
PAL4C Labs is an independent, Palantir-exclusive consultancy. We build and run Foundry pipelines, models, Ontologies, and AIP workflows for operations, supply chain, healthcare, and regulatory teams, and we’re not affiliated with Palantir.
Want a second pair of eyes on your production setup? Send us a list of your live deployments and production pipelines. We’ll run a production health review with you, covering monitoring gaps, drift checks, release process, and idle compute, and hand back a prioritized fix list.
Foundry Production Questions We Get
Direct Deployment vs Objective Live Deployment, What’s the Difference?
Control versus convenience. Direct deployments auto-upgrade and auto-scale with traffic, which suits fast iteration. Objective live deployments add staging and production releases and uptime monitoring but reserve fixed compute, which suits production endpoints that users depend on.
How Do Staging and Production Releases Work?
Inside a Modeling Objective, you release an accepted model version with a release number and note, tagged for staging or production. Promote with Mark as production. Each release upgrades every deployment in that environment automatically.
Can We Batch Score With an External SageMaker or Azure ML Model?
Not through objective batch deployments, which don’t support externally hosted models. Use a Python transform with an egress policy for batch scoring instead, and use live deployment for on-demand calls.
Does Foundry Alert to PagerDuty or Slack?
Through monitoring views, which can send alerts to PagerDuty, Slack, or webhooks, with low, medium, or high severity. Data Health checks feed into the same system.
Does Foundry Monitor Model Drift on Its Own?
We haven’t found a documented built-in drift feature. Build it with scheduled comparisons of inputs and predictions against baselines, evaluations against real outcomes, and monitoring rules on the results.
What Happened to foundry_ml Models?
Deprecated. Palantir says foundry_ml and dataset-backed models have been fully deprecated since October 31, 2025, and Code Workbooks models need rebuilding in Code Workspaces or Code Repositories with the newer model tooling.
Why Is Our Compute Bill Higher Than Expected?
Often idle live deployments. They reserve compute until someone stops them, even with zero traffic. Check staging endpoints first, then oversized resource profiles, then pipelines that fully rebuild instead of running incrementally.