Add note to docs about Apollo GraphOS Operator

[DMallare]

---

Adding a note about the Operator in our deployment docs

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• PR description explains the motivation for the change and relevant context for reviewing
• PR description links appropriate GitHub/Jira tickets (creating when necessary)
• Changeset is included for user-facing changes
• Changes are compatible¹
• Documentation² completed
• Performance impact assessed and acceptable
• Metrics and logs are added³ and documented
• Tests added and passing⁴
  • Unit tests
  • Integration tests
  • Manual tests, as necessary

Exceptions

Note any exceptions here

Notes

Footnotes

1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩

2. Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩

3. A lot of (if not most) features benefit from built-in observability and debug-level logs. Please read this guidance on metrics best-practices. ↩

4. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

[github-actions]

@DMallare, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.

[apollo-librarian]

✅ Docs preview ready

The preview is ready to be viewed. View the preview

File Changes

0 new, 3 changed, 0 removed

* graphos/routing/(latest)/performance/caching/response-caching/customization.mdx
* graphos/routing/(latest)/self-hosted/containerization/kubernetes/quickstart.mdx
* graphos/routing/(latest)/self-hosted/index.mdx

Build ID: a5dfecac2390c6ecd7e0e4fe
Build Logs: View logs

URL: https://www.apollographql.com/docs/deploy-preview/a5dfecac2390c6ecd7e0e4fe

[mabuyo]

Thanks for adding this @DMallare ! Would you mind adding to this page as well? https://www.apollographql.com/docs/graphos/routing/self-hosted

I'm thinking a similar format to the Docker section except with Kubernetes and sub-headings for Helm and Apollo Operator.
I'm not familiar with our guidance on when to use which, it would be great to have that information. I'm happy to massage the wording!

[DMallare]

Thanks for adding this @DMallare ! Would you mind adding to this page as well? https://www.apollographql.com/docs/graphos/routing/self-hosted

I'm thinking a similar format to the Docker section except with Kubernetes and sub-headings for Helm and Apollo Operator. I'm not familiar with our guidance on when to use which, it would be great to have that information. I'm happy to massage the wording!

Added!

[mabuyo]

A couple of suggestions!

[mabuyo]

We can actually remove this entire section in favour of the note at the top!

[DMallare]

Agreed :)

[mabuyo]

What do we mean by "production-grade" here? To me, it implies that the alternatives are not production-grade. It feels a bit too much like marketing-speak for my taste. Can we be more concrete on when they should use the Operator vs Helm?

Here's my suggestion based on what was in the last section ("Consider using Apollo Operator")

Suggested change

	<Note>
	For a production-grade self-hosted deployment, Apollo recommends the [Apollo GraphOS Operator](/apollo-operator/).
	</Note>
	<Note>
	Apollo recommends using the [Apollo GraphOS Operator](/apollo-operator/) for production deployments and when managing multiple routers or complex architectures. The Operator provides declarative Kubernetes resources to manage routers, supergraphs, graph schemas, and subgraphs, making it easier to maintain consistency and automate deployments across your infrastructure.
	<br/><br/>
	Use the Operator when you need:
	- Production-grade deployments with declarative configuration management
	- Simplified management of multiple routers, supergraphs, and subgraphs
	- Support for complex architectures including single-cluster, multi-cluster, and hybrid configurations
	- Integration with existing CI/CD workflows through deploy-only patterns
	For more details, see the [Operator workflow patterns](/apollo-operator/workflows/).
	</Note>

Though it's longer, I feel we need to give people a good enough reason to click off the Helm guide and use our recommended approach.

[mabuyo]

Please feel super free to verify this wording, I'm not familiar with Operator/K8s/Helm enough to verify its accuracy!

[DMallare]

I like this but we do have a section at the bottom of this page. I think we can just get rid of that and use this suggestion. I will make that change.

[mabuyo]

Can we also re-arrange a few things in this intro?

• Note should be at the very top
• Followed by ElasticNotice
• Then, add the intro explaining what this guide is and why you might want to use this approach compared to the Operator

This guide uses Helm charts to deploy a self-hosted router in Kubernetes. Using Helm is suitable for quick deployments, testing, or when you prefer direct Helm chart management.

This guide shows how to...

[mabuyo]

Suggested change

	For a production-grade self-hosted deployment, Apollo recommends the [Apollo GraphOS Operator](/apollo-operator/). The Operator provides declarative Kubernetes resources to manage routers, supergraphs, graph schemas, and subgraphs. It simplifies complex multi-service architectures.
	Apollo recommends the [Apollo GraphOS Operator](/apollo-operator/). The Operator provides declarative Kubernetes resources to manage routers, supergraphs, graph schemas, and subgraphs. It simplifies complex multi-service architectures.

Similar to my earlier comment, I think we can just say this is the recommended way.