2i2c-org · choldgraf · Oct 18, 2021 · Oct 18, 2021 · Oct 18, 2021
diff --git a/content/about/compass.md b/content/about/compass.md
@@ -9,4 +9,4 @@ title = ""
   columns = "1"
 +++
 
-2i2c is an open, transparent, and participatory organization. To learn more about 2i2c, [check our Team Compass](https://team-compass.2i2c.org). To learn the details about our infrastructure, [see the 2i2c DevOps guide](https://devops.2i2c.org).
+2i2c is an open, transparent, and participatory organization. To learn more about 2i2c, [check our Team Compass](https://team-compass.2i2c.org). To learn the details about our infrastructure, [see the 2i2c Infrastructure guide](https://devops.2i2c.org).
diff --git a/content/pilot-hubs/index.html b/content/pilot-hubs/index.html
@@ -1 +1 @@
-<meta http-equiv="refresh" content="0; URL='http://devops.2i2c.org'" />
+<meta http-equiv="refresh" content="0; URL='http://infrastructure.2i2c.org'" />
diff --git a/content/pilot/index.html b/content/pilot/index.html
@@ -1 +1 @@
-<meta http-equiv="refresh" content="0; URL='http://pilot.2i2c.org'" />
+<meta http-equiv="refresh" content="0; URL='http://docs.2i2c.org'" />
diff --git a/content/posts/2021/q3-update/index.md b/content/posts/2021/q3-update/index.md
@@ -24,7 +24,7 @@ Our Managed JupyterHub Service will be a sustainable, scalable, and participator
 
 We focused on a few major areas for work, outlined below:
 
-- **Automation across cloud providers**. We wish to serve communities that run on any of the major commercial cloud providers. We can standardize some of our infrastructure through abstractions like Kubernetes, but must still create cloud-specific deployment infrastructure as well (that Kubernetes cluster has to come from somewhere first!). In the last four months we've worked on automating Kubernetes and JupyterHub deployments on [AWS](https://github.com/2i2c-org/pilot-hubs/issues/627) as well as [Azure](https://github.com/2i2c-org/pilot-hubs/issues/512) to complement our Google Cloud deployments. We would soon like to run more hubs on this infrastructure to test how well it scales.
+- **Automation across cloud providers**. We wish to serve communities that run on any of the major commercial cloud providers. We can standardize some of our infrastructure through abstractions like Kubernetes, but must still create cloud-specific deployment infrastructure as well (that Kubernetes cluster has to come from somewhere first!). In the last four months we've worked on automating Kubernetes and JupyterHub deployments on [AWS](https://github.com/2i2c-org/infrastructure/issues/627) as well as [Azure](https://github.com/2i2c-org/infrastructure/issues/512) to complement our Google Cloud deployments. We would soon like to run more hubs on this infrastructure to test how well it scales.
 - **Monitoring and reporting infrastructure**. We have worked on the JupyterHub [`grafana-dashboards` project](https://github.com/jupyterhub/grafana-dashboards) to improve dashboarding around JupyterHub deployments in general, and will soon automatically deploy Grafana dashboards for our hubs so that communities have insight into what is going on in their hubs. 
 - **User environment management**. We want communities to have control over the environments that are available on their hubs. We also want to encourage that our communities follow community standards for reproducible environments that can be re-used elsewhere. For this reason, we've improved the [repo2docker GitHub action](https://github.com/jupyterhub/repo2docker-action) to work with more image registries, and created a [2i2c user image template repository](https://github.com/2i2c-org/hub-user-image-template) for users to re-use for their hubs. See [the User Environment docs](https://docs.2i2c.org/en/latest/admin/howto/environment.html#bring-your-own-docker-image) for more information.
 - **Support and collaboration roles**. In addition to technology changes, we have developed an alpha-level support and collaboration model for the communities we serve. Most relevant for our communities is the **community representative** role, who acts as the main point of contact with 2i2c engineers, and leads administrators on the hub to guide its customization for the community it serves. See [the user roles documentation](https://docs.2i2c.org/en/latest/about/roles.html) for more information. We have also begun prototyping a [FreshDesk support model](https://docs.2i2c.org/en/latest/admin/howto/support.html) and team processes around monitoring our support channels and responding to requests and incidents.

diff --git a/content/posts/2021/six-month-update/index.md b/content/posts/2021/six-month-update/index.md
@@ -26,8 +26,8 @@ They'll be built entirely with open source tools that are community-driven, and
 In order to accomplish this, 2i2c is running several pilots with partners and interested organizations, supported by our [funding from CZI](/posts/czi-core-support), as well as from [the JROST rapid response fund](https://investinopen.org/blog/jrost-rapid-response-fund-awardees/).
 These pilots are meant to be learning opportunities to understand what kind of infrastructure and service it needs to build moving forward.
 
-The [documentation for our pilot hubs infrastructure](https://devops.2i2c.org/en/latest/) contains information about our deployments and infrastructure.
-It is served from [this `2i2c-org/pilot-hubs` repository](https://github.com/2i2c-org/pilot-hubs), a centralized location for configuring and deploying a federated network of JupyterHubs.
+The [documentation for our pilot hubs infrastructure](https://infrastructure.2i2c.org/en/latest/) contains information about our deployments and infrastructure.
+It is served from [this `2i2c-org/infrastructure` repository](https://github.com/2i2c-org/infrastructure), a centralized location for configuring and deploying a federated network of JupyterHubs.
 Each JupyterHub is independent of one another, and could be spun out from the centralized repository with minimal extra work, giving hub users the ability to [replicate their infrastructure, with or without 2i2c](/right-to-replicate).
 We will continue refining the code in this repository as we learn more from our hub infrastructure pilots.
 

diff --git a/content/service/getahub.md b/content/service/getahub.md
@@ -23,7 +23,7 @@ We are prioritizing running infrastructure for a diverse group of organizations
 {{% callout note %}}
 **Would your community benefit from a managed JupyterHub?**
 
-Send us an email and we'd be happy to discuss your community's needs to understand if it is a good fit for the pilot.
+Send us an email and we'd be happy to discuss your community's needs to understand if it is a good fit for our JupyterHub service.
 
 {{< cta cta_text="Send us an email" cta_link="mailto:[email protected]?subject=Interested in a 2i2c JupyterHub" cta_new_tab="true" >}}
 

diff --git a/content/service/open-service.md b/content/service/open-service.md
@@ -11,5 +11,5 @@ This helps [give our communities the Right to Replicate their infrastructure](/r
 
 - [**Our service overview**](https://docs.2i2c.org/en/latest/about/overview.html) has more information about the service, its goals and strategy, and the latest information on features, pricing, and use-cases.
 - [**The hub administrator's guide**](https://docs.2i2c.org/en/latest/) is a hands-on guide for community leaders that administer JupyterHubs managed by 2i2c.
-- [**Our Infrastructure Guide**](https://devops.2i2c.org/) is the guide that _2i2c Engineers_ use to manage your cloud infrastructure. It describes all the details of our cloud infrastructure.
+- [**Our Infrastructure Guide**](https://infrastructure.2i2c.org/) is the guide that _2i2c Engineers_ use to manage your cloud infrastructure. It describes all the details of our cloud infrastructure.
 - [**Our Team Compass**](https://team-compass.2i2c.org/) has everything you might want to know about 2i2c - our structure, strategy, team practices and policies, major projects, and how to get involved.