There's quite a bit of documents out on their public site[1], although the Mission Manager that represents the other half of the story has its docs gated by authentication
1: https://www.palantir.com/docs/apollo/core/release-channels/ et al, plus one can get a sense of how apollo-cli works from their OpenAPI spec https://github.com/palantir/apollo-openapi/blob/develop/open...
I can see how this would be instrumental for coordinating hundreds of developers across tens of products, but as someone who's only ever worked as tens of developers on one product it seems like a lot of overhead for really no ROI; what's the difference between using this product and having a DevOps team that coordinates CI/CD in-house? Is Palantir's edge here being the out-of-house devops team for any large enterprise?
It also gets into the compliance side of things (arguably it's all about compliance) in that new releases, config changes, vulnerability mitigation, downtime windows, and a ton of other stuff are optionally gated by a review process. If you want to change the values.yaml for an existing release, you can choose whether that is a 4-eyes change
That latter bit also speaks to your question about "who is the target audience for this?" because, like many things Palantir, it's a lot of the defense industry and intelligence community, as they care a lot about having gates and controls in place. Apollo specifically also gets into "edge deployments," such as what software is running on a laptop that goes out into the field, comes back to base, and only then gets its updates pushed to it
I detest them with all my heart, but I'll be straight that Apollo does actually model the deployment concerns of software very well. Every place that I've been always hand-assembles their own CD story using off the shelf stuff, and so if one has compliance needs then Apollo allows to pay to have the "hand assembled" problem go away. That said, I have _absolutely no idea_ how much Apollo costs, so I'd also speculate that most organizations would be much happier just paying for a competent DevOps role to do the best they can to use off the shelf tools to hand assemble their own CD story, or use BigBang[1] which is at least open source and a standard (one may not like it, but it is at least consistent)