Clarify Arize and Phoenix integration positioning - #948
Conversation
f151b81 to
13f92ae
Compare
13f92ae to
3a5aa85
Compare
3a5aa85 to
e21b670
Compare
- Unify the cloud and self-host copies; keep vendor positioning, guide links, and UTM parameters - Add Phoenix Cloud alongside self-hosting in the Phoenix intros; scope local-development framing to the self-host tree (Dify exports traces server-side) - Use root-relative internal links; drop the redundant info callouts - Translate the updated sections across all eight zh/ja sibling pages
|
Thanks for the contribution @arizedatngo! We've pushed some edits on top of your branch. Mind taking a look before this merges? What we changed:
One thing we noticed while reviewing: Dify exports traces from its backend workers, so a Phoenix instance on a developer's machine wouldn't receive traces from Dify Cloud. Only from a self-hosted Dify that can reach it. On that basis we kept the "local development" framing on the self-host pages and pointed Cloud users to Phoenix Cloud or a reachable self-hosted endpoint. Does that match how you see Phoenix used with Dify Cloud? Happy to adjust, and same goes for any of the product descriptions. |
|
@RiskeyL thanks again for pushing edits on top of this branch. Since this is labeled The main intent is to keep the existing Arize/Phoenix setup accurate while clarifying AX vs Phoenix positioning and using the canonical Arize evaluation resource links. |
Summary
Why
The Dify docs include separate Arize and Phoenix integration pages. This update makes the AX and Phoenix paths easier to distinguish before setup: AX for full-featured managed cloud or enterprise self-hosted deployments, and Phoenix for open-source local or self-hosted workflows.
Testing