ansys · LKasianAnsys · Aug 25, 2026 · Aug 25, 2026 · Aug 25, 2026 · Aug 25, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -1,3 +1,3 @@
-This project uses [towncrier](https://towncrier.readthedocs.io/) and the changes for the upcoming release can be found in <https://github.com/ansys-internal/visor/tree/main/doc/changelog.d/>.
+This project uses [towncrier](https://towncrier.readthedocs.io/) and the changes for the upcoming release can be found in <https://github.com/ansys/visor/tree/main/doc/changelog.d/>.
 
 <!-- towncrier release notes start -->
diff --git a/README.rst b/README.rst
@@ -73,30 +73,30 @@ Visor documentation.
 * **Standalone Python**
 
    * Launch a desktop Visor app with the Python package ``ansys.visor.viewer`` to visualize files.
-   * See `Visor Python API <https://vigilant-lamp-162kw9z.pages.github.io/version/dev/user_guide/launching_theia/theia_python_api.html>`_
+   * See `Visor Python API <https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/user_guide/launching_visor/visor_python_api.html>`_
      for API usage examples.
-   * See `API reference <https://vigilant-lamp-162kw9z.pages.github.io/version/dev/python_api_reference.html>`_
+   * See `API reference <https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/python_api_reference.html>`_
      for details about the Python API.
 
 * **Visor HTTP service**
 
    * Manage multiple Visor instances through the Visor HTTP API.
    * Integrate with `PIM (Product Instance Management) <https://github.com/ansys/ansys-api-platform-instancemanagement>`_
      to manage Visor instances in SAF apps.
-   * See `Visor HTTP service <https://vigilant-lamp-162kw9z.pages.github.io/version/dev/user_guide/launching_theia/theia_service.html>`_
+   * See `Visor HTTP service <https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/user_guide/launching_visor/visor_service.html>`_
      for usage examples.
-   * See `HTTP API reference <https://vigilant-lamp-162kw9z.pages.github.io/version/dev/http_api_reference/index.html>`_
+   * See `HTTP API reference <https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/http_api_reference/index.html>`_
      for API details.
 
 * **Dash frontend app**
 
    * Connect to a Visor instance from a Dash app with the Visor Dash component in
      ``ansys.visor.dash.dash_visor_viewer``.
-   * See `Visor Dash component <https://vigilant-lamp-162kw9z.pages.github.io/version/dev/user_guide/launching_theia/theia_dash_component.html>`_
+   * See `Visor Dash component <https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/user_guide/launching_visor/visor_dash_component.html>`_
      for details.
 
 For advanced usage and configuration options, see the following Visor documentation:
 
-`User guide <https://vigilant-lamp-162kw9z.pages.github.io/version/dev/user_guide/index.html>`_ and
-`Examples <https://vigilant-lamp-162kw9z.pages.github.io/version/dev/examples/index.html>`_ in the
+`User guide <https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/user_guide/index.html>`_ and
+`Examples <https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/examples/index.html>`_ in the
 Visor sections.
diff --git a/doc/changelog.d/1192.test.md b/doc/changelog.d/1192.test.md
diff --git a/doc/changelog.d/1195.documentation.md b/doc/changelog.d/1195.documentation.md
diff --git a/doc/changelog.d/1196.maintenance.md b/doc/changelog.d/1196.maintenance.md
diff --git a/doc/changelog.d/1199.test.md b/doc/changelog.d/1199.test.md
diff --git a/doc/changelog.d/1200.miscellaneous.md b/doc/changelog.d/1200.miscellaneous.md
diff --git a/doc/changelog.d/1204.miscellaneous.md b/doc/changelog.d/1204.miscellaneous.md
diff --git a/doc/changelog.d/1216.maintenance.md b/doc/changelog.d/1216.maintenance.md
diff --git a/doc/changelog.d/1217.miscellaneous.md b/doc/changelog.d/1217.miscellaneous.md
diff --git a/doc/changelog.d/1218.added.md b/doc/changelog.d/1218.added.md
diff --git a/doc/changelog.d/1234.added.md b/doc/changelog.d/1234.added.md
diff --git a/doc/changelog.d/1236.maintenance.md b/doc/changelog.d/1236.maintenance.md
diff --git a/doc/changelog.d/1237.maintenance.md b/doc/changelog.d/1237.maintenance.md
diff --git a/doc/changelog.d/1238.documentation.md b/doc/changelog.d/1238.documentation.md
diff --git a/doc/changelog.d/1239.maintenance.md b/doc/changelog.d/1239.maintenance.md
diff --git a/doc/changelog.d/1240.maintenance.md b/doc/changelog.d/1240.maintenance.md
diff --git a/doc/changelog.d/1243.documentation.md b/doc/changelog.d/1243.documentation.md
diff --git a/doc/changelog.d/1244.added.md b/doc/changelog.d/1244.added.md
diff --git a/doc/changelog.d/1245.test.md b/doc/changelog.d/1245.test.md
diff --git a/doc/changelog.d/1249.added.md b/doc/changelog.d/1249.added.md
diff --git a/doc/changelog.d/1253.added.md b/doc/changelog.d/1253.added.md
diff --git a/doc/changelog.d/1254.documentation.md b/doc/changelog.d/1254.documentation.md
diff --git a/doc/changelog.d/1256.maintenance.md b/doc/changelog.d/1256.maintenance.md
diff --git a/doc/changelog.d/1259.maintenance.md b/doc/changelog.d/1259.maintenance.md
diff --git a/doc/changelog.d/1268.maintenance.md b/doc/changelog.d/1268.maintenance.md
diff --git a/doc/changelog.d/1275.maintenance.md b/doc/changelog.d/1275.maintenance.md
diff --git a/doc/changelog.d/1285.fixed.md b/doc/changelog.d/1285.fixed.md
diff --git a/doc/changelog.d/1286.maintenance.md b/doc/changelog.d/1286.maintenance.md
diff --git a/doc/changelog.d/1287.maintenance.md b/doc/changelog.d/1287.maintenance.md
diff --git a/doc/changelog.d/1290.fixed.md b/doc/changelog.d/1290.fixed.md
diff --git a/doc/changelog.d/1291.maintenance.md b/doc/changelog.d/1291.maintenance.md
diff --git a/doc/changelog.d/1293.maintenance.md b/doc/changelog.d/1293.maintenance.md
diff --git a/doc/changelog.d/1296.miscellaneous.md b/doc/changelog.d/1296.miscellaneous.md
diff --git a/doc/changelog.d/1297.documentation.md b/doc/changelog.d/1297.documentation.md
diff --git a/doc/changelog.d/1298.miscellaneous.md b/doc/changelog.d/1298.miscellaneous.md
diff --git a/doc/changelog.d/1299.miscellaneous.md b/doc/changelog.d/1299.miscellaneous.md
diff --git a/doc/changelog.d/1300.miscellaneous.md b/doc/changelog.d/1300.miscellaneous.md
diff --git a/doc/changelog.d/1304.fixed.md b/doc/changelog.d/1304.fixed.md
diff --git a/doc/changelog.d/9.maintenance.md b/doc/changelog.d/9.maintenance.md
@@ -0,0 +1 @@
+Clean up stale references to internal repo
diff --git a/doc/developer_docs/adrs/02-visor-technology-components.md b/doc/developer_docs/adrs/02-visor-technology-components.md
@@ -145,7 +145,7 @@ and better architecture in terms of streaming APIs and services for on-prem and
 
 ### Consequences
 
-These [tenets](https://github.com/ansys-internal/theia/blob/tenets/adrs/01-theia-tenets.md) allow the project to change direction without transferring effort to the groups integrated with VISOR or at least with minimal effort. This means that the option decided now it doesn't have to be the only option going forward but it is going to necessitate engineering effort to add more targets or transition the project to a new visualization SDK or platform. The view of the project is to be itself a platform for visualization components for the Solutions Group and handle the engineering complexity of those components and integrating them in VISOR rather than pushing it to the Solutions Applications. This is also a matter of choosing vendor or making it possible to have different initial, running cost and maintenance cost for the different approaches as the deployment targets and the cost evaluation differs.
+These [tenets](https://github.com/ansys/visor/blob/main/doc/developer_docs/adrs/01-visor-tenets.md) allow the project to change direction without transferring effort to the groups integrated with VISOR or at least with minimal effort. This means that the option decided now it doesn't have to be the only option going forward but it is going to necessitate engineering effort to add more targets or transition the project to a new visualization SDK or platform. The view of the project is to be itself a platform for visualization components for the Solutions Group and handle the engineering complexity of those components and integrating them in VISOR rather than pushing it to the Solutions Applications. This is also a matter of choosing vendor or making it possible to have different initial, running cost and maintenance cost for the different approaches as the deployment targets and the cost evaluation differs.
 
 The current target is to release in Q4 2024 a VISOR MVP version. The consequences per option are outlined in the following table:
 

diff --git a/doc/developer_docs/adrs/14-save-load-state.md b/doc/developer_docs/adrs/14-save-load-state.md
@@ -224,7 +224,8 @@ diverge as requirements evolve.
 
 Note that as this will also require schema changes to the runtime data transfer object (DTO) that is sent from the
 backend to the frontend to initialize or update the viewer state.  There is a
-[separate ADR](https://github.com/ansys-internal/theia/blob/doc/adr-scene-description-1/developer_docs/adrs/13-scene-details.md) to align on this schema.  (This ADR will be updated to reflect the final results of that discussion
+[separate ADR](https://github.com/ansys/visor/blob/main/doc/developer_docs/adrs/13-scene-details.md) to align on this
+schema.  (This ADR will be updated to reflect the final results of that discussion
 once it is finalized.)
 
 ![VISOR State Model Diagram](../images/visor-state-model.png)
@@ -266,7 +267,7 @@ At the time the save/load state feature was started, the state representation fo
 to the per-part dataset state (opacity only).
 
 For the runtime state at the client/server boundary, we maintain the schema definition in a
-[separate ADR](https://github.com/ansys-internal/theia/blob/doc/adr-scene-description-1/developer_docs/adrs/13-scene-details.md).
+[separate ADR](https://github.com/ansys/visor/blob/main/doc/developer_docs/adrs/13-scene-details.md).
 This schema is intended to evolve as we expand the state representation to include all components required to
 capture the viewer state for the save/load feature.
 

diff --git a/doc/developer_docs/adrs/15-ansys-product-support.md b/doc/developer_docs/adrs/15-ansys-product-support.md
@@ -8,7 +8,8 @@ Team and Stakeholder Αpproved
 VISOR depends on legacy Ansys flagships to provide VTK format support and on PyAnsys APIs to enable those flagships to be used within Solutions Applications. These workflows improve maintainability and adoption by leveraging PyAnsys, which offers a specialized 3D viewer for examples and lowers the effort required for community users to access needed functionality. Each flagship product is responsible for converting its internal data to the common format. That format is aligned with SimAI requirements and maintained by the flagship teams, ensuring it stays optimized and in sync with the 3D viewer as products evolve.
 
 ## Context
-Our requirements for legacy Ansys product support were based on the requirements for legacy Ansys products namely, Discovery, SpaceClaim, Fluent, Mechanical, AEDT suite and EnSight. Our prioritized requirements are for Fluent, GeometryService, but all legacy Ansys flagship products are included in the VISOR roadmap as well as Electronics Simulation Products. VISOR is a component which will be available within the Solution Architecture Framework and it is in VISOR's scope to be able to visualize the models and the data produced in those products. It is out of scope for VISOR to be doing transformations of the Ansys product formats to its internal representation. VISOR is using a scene graph described in the [08-scene-graph ADR](https://github.com/ansys-internal/theia/blob/c5ec3e366c8dbe385b5de520ddff10da7eaf6f78/docs/adrs/07-scene-graph.md). This scene description graph supports VTK format.
+Our requirements for legacy Ansys product support were based on the requirements for legacy Ansys products namely, Discovery, SpaceClaim, Fluent, Mechanical, AEDT suite and EnSight. Our prioritized requirements are for Fluent, GeometryService, but all legacy Ansys flagship products are included in the VISOR roadmap as well as Electronics Simulation Products. VISOR is a component which will be available within the Solution Architecture Framework and it is in VISOR's scope to be able to visualize the models and the data produced in those products. It is out of scope for VISOR to be doing transformations of the Ansys product formats to its internal representation. VISOR is using a scene graph described in the
+[08-scene-graph ADR](https://github.com/ansys/visor/blob/3fdbf4413c63d1c7c2b2ef62792a638f8d6f2b85/doc/developer_docs/adrs/07-scene-graph.md). This scene description graph supports VTK format.
 
 VISOR supports VTK-based formats (including VTKHDF), which is the requirement for supporting 3D data along with the mixed OpenUSD and VTK formats from the [architecture board decision #29](https://github.com/ansys-internal/architecture-decision-records/blob/main/content/docs/adrs/0029-visualization-formats.md). Based on that decision, all legacy Ansys products need to support the mixed OpenUSD and VTK format, and for VTK they should be providing VTKHDF. This decision is based on achieving a common visualization format which covers the current needs and the upcoming view regarding OpenUSD format. Considerations for the legacy Ansys common data model may impact some of the decisions here but those discussions will need to make sure to include the requirements and constraints of the VISOR 3D viewer.
 

diff --git a/doc/developer_docs/adrs/16-visor-saf-integration.md b/doc/developer_docs/adrs/16-visor-saf-integration.md
@@ -5,7 +5,7 @@ Team approved
 
 ## Context
 
-VISOR is aiming to be the Solutions' Applications 3D viewer and as such the primary platform that VISOR is going to be used is through Solutions Applications Framework (SAF). The tenets of the VISOR project can be found [here](https://github.com/ansys-internal/theia/blob/054999e0152720954dde2ef2596fc46b8a44133c/docs/adrs/01-theia-tenets.md). Solutions Applications are required to be able to target desktop, on-premise deployment and cloud deployment through integration with SAF, REP and CISL/Cloud Burst platforms. VISOR as a Solutions Applications viewer is scoped to be aiming to the requirements of the Solutions Applications and ACE stakeholders rather than being a standalone application and as such it needs to comply with the requirements the Solutions Applications group, the Architecture Hub and the ACE stakeholders are providing. VISOR is not responsible for Authentication or Authorization of users, or directly deployments or running a service but its responsible for making sure that all the requirements set will be able to be implemented in VISOR through its architecture.
+VISOR is aiming to be the Solutions' Applications 3D viewer and as such the primary platform that VISOR is going to be used is through Solutions Applications Framework (SAF). The tenets of the VISOR project can be found [here](https://github.com/ansys/visor/blob/3fdbf4413c63d1c7c2b2ef62792a638f8d6f2b85/doc/developer_docs/adrs/01-visor-tenets.md). Solutions Applications are required to be able to target desktop, on-premise deployment and cloud deployment through integration with SAF, REP and CISL/Cloud Burst platforms. VISOR as a Solutions Applications viewer is scoped to be aiming to the requirements of the Solutions Applications and ACE stakeholders rather than being a standalone application and as such it needs to comply with the requirements the Solutions Applications group, the Architecture Hub and the ACE stakeholders are providing. VISOR is not responsible for Authentication or Authorization of users, or directly deployments or running a service but its responsible for making sure that all the requirements set will be able to be implemented in VISOR through its architecture.
 
 VISOR is targeting desktop, on-prem and cloud deployments. In terms of MVP, VISOR is targeting desktop deployment and it will iteratively target on-prem and cloud deployments as a component of the Solutions Applications Framework and not as a standalone service.
 
@@ -41,7 +41,7 @@ VISOR is going to be using HPS for orchestrating on-premise and cloud deployment
 In order for VISOR to support multiple users or sessions it needs to be containerized and deployed through the HPS which will be creating new instances to scale VISOR based on the users or sessions which are necessary for smoothly running the on-premise deployment.
 
 #### VISOR client-side rendering
-Based on the current technology components of VISOR described [here](https://github.com/ansys-internal/theia/blob/054999e0152720954dde2ef2596fc46b8a44133c/docs/adrs/02-theia-technology-components.md) it is using Trame VTK.WASM which is a client based rendering technology on the browser using VTK, Web assembly and OpenGL2.x and when its available WebGPU. This means that performance of VISOR is going to be impacted by network connectivity even though there is a websocket connecting directly to the client, it will still have the relative impact as there are models and data transferred to to the client.
+Based on the current technology components of VISOR described [here](https://github.com/ansys/visor/blob/3fdbf4413c63d1c7c2b2ef62792a638f8d6f2b85/doc/developer_docs/adrs/02-visor-technology-components.md) it is using Trame VTK.WASM which is a client based rendering technology on the browser using VTK, Web assembly and OpenGL2.x and when its available WebGPU. This means that performance of VISOR is going to be impacted by network connectivity even though there is a websocket connecting directly to the client, it will still have the relative impact as there are models and data transferred to to the client.
 
 *Additional requirements:*
 * Kubernetes-based containerized version of VISOR

diff --git a/doc/source/getting_started/configure_visor.rst b/doc/source/getting_started/configure_visor.rst
@@ -45,7 +45,7 @@ Settings defaults
 =================
 
 You can use a ``.visor`` file to override the following default values from the
-`Settings class <https://github.com/ansys-internal/theia/blob/707770cf39101281b16cfaa58ab1bee2aa1cebe2/src/ansys/theia/viewer/config.py>`_:
+`Settings class <https://github.com/ansys/visor/blob/main/src/ansys/visor/viewer/config.py>`_:
 
 .. code-block:: yaml
 

diff --git a/doc/source/index.rst b/doc/source/index.rst
@@ -36,7 +36,7 @@ You can use VISOR to integrate with the following tools:
 You run VISOR with VTK (Visual Toolkit) rendering through Trame for client-server architecture and Python
 integration workflows. You target VTK WASM with WebGL support.
 
-View a `demo <https://theia.dev.ansysapis.com/index.html>`_ to see VISOR in action.
+View a `demo <https://visor.dev.ansysapis.com/index.html>`_ to see VISOR in action.
 
 .. grid:: 2
   :gutter: 4

diff --git a/doc/source/user_guide/launching_visor/metadata.rst b/doc/source/user_guide/launching_visor/metadata.rst
@@ -149,7 +149,7 @@ Only the initial opacity is supported as a per-part property.
 Reference
 ~~~~~~~~~
 
-Reference: ``Metadata`` class (`source code <https://github.com/ansys-internal/theia/blob/main/src/ansys/theia/viewer/core/metadata.py>`_).
+Reference: ``Metadata`` class (`source code <https://github.com/ansys/visor/blob/main/src/ansys/visor/viewer/core/metadata.py>`_).
 
 .. literalinclude:: ../../../../src/ansys/visor/viewer/core/metadata.py
    :pyobject: Metadata

diff --git a/tests/e2e/regressions/test_update_variables.py b/tests/e2e/regressions/test_update_variables.py
@@ -43,7 +43,7 @@ def test_update_variables(visor_server, request):
     updates the variable values to constant values, and verifies the update took place.
 
     Test replicates example in documentation:
-    https://vigilant-lamp-162kw9z.pages.github.io/version/stable/examples/03-updating-theia-scene
+    https://supreme-fiesta-v6v17mm.pages.github.io/version/dev/examples/03-updating-visor-scene
     """
 
     visor = visor_server