redhat-developer · themr0c · Mar 5, 2026 · lhite8041 · Mar 5, 2026 · lhite8041
diff --git a/assemblies/assembly-about-rhdh.adoc b/assemblies/assembly-about-rhdh.adoc
@@ -9,22 +9,24 @@ ifdef::context[]
 endif::[]
 = About {product}
 
+[role="_abstract"]
+Learn about {product}, an enterprise-grade internal developer portal that helps teams simplify software delivery and accelerate development.
+
 :context: about-rhdh
 
-{product} ({product-very-short}) is an enterprise-grade internal developer portal (IDP) that helps simplify and accelerates software delivery. It provides a customizable web-based interface that centralizes access to key development resources, including source code repositories, CI and CD pipelines, APIs, documentation, and runtime environments.
+{product} ({product-very-short}) is an enterprise-grade internal developer portal (IDP) that helps simplify and accelerate software delivery. It provides a customizable web-based interface that centralizes access to key development resources, including source code repositories, CI and CD pipelines, APIs, documentation, and runtime environments.
 
 {product} is designed for cloud-native environments, including supported Kubernetes platforms, {ocp-brand-name}, and hybrid infrastructure. By consolidating tools and standardizing development workflows, it helps teams deliver software faster with more consistency.
 
 Designed for enterprise-scale software teams, {product-very-short} helps developers focus on building software rather than managing tools. Developers can onboard quickly, create environments, and integrate with existing systems. With enterprise-grade security, role-based access control, and 24x7 support, teams stay productive while meeting compliance and reliability standards.
 
 include::modules/about/con_understanding-internal-developer-platforms.adoc[leveloffset=+1]
-
-// {product-very-short} integrates software templates, pre-designed solutions, and dynamic plugins into a centralized platform, providing tailored solutions for operations and development teams in a unified environment.
-
-// include::modules/about/con-benefits-of-rhdh.adoc[leveloffset=+1]
 include::modules/about/con-system-architecture-for-deployment-planning.adoc[leveloffset=+1]
 include::modules/about/con-achieve-high-availability-with-database-and-cache-layers.adoc[leveloffset=+1]
 include::modules/about/con-integrations-in-rhdh.adoc[leveloffset=+1]
 include::modules/about/ref-supported-platforms.adoc[leveloffset=+1]
 include::modules/about/ref-rhdh-sizing.adoc[leveloffset=+1]
 include::modules/about/ref-customer-support-info.adoc[leveloffset=+1]
+
+ifdef::parent-context-of-about-rhdh[:context: {parent-context-of-about-rhdh}]
+ifndef::parent-context-of-about-rhdh[:!context:]
diff --git a/modules/about/con-achieve-high-availability-with-database-and-cache-layers.adoc b/modules/about/con-achieve-high-availability-with-database-and-cache-layers.adoc
@@ -1,11 +1,12 @@
 :_mod-docs-content-type: CONCEPT
 
 [id="con-achieve-high-availability-with-database-and-cache-layer_{context}"]
-= Achieve high availability with database and cache layers
+= High availability with database and cache layers
 
-To achieve high availability (HA) in {product}, you must implement redundancy and failover for the backend service and its external data dependencies. This configuration uses horizontal scaling, database replication, and a shared logical cache to make sure {product-very-short} remains operational during component failures.
+[role="_abstract"]
+High availability in {product} requires redundancy and failover for the backend service and data dependencies by using horizontal scaling, database replication, and shared caching to ensure continuous operation during failures.
 
-.Backend scalability
+== Backend scalability
 
 {product-very-short} backend uses a stateless design to support horizontal scaling. PostgreSQL stores persistent data and the database manages sessions, allowing multiple backend instances to serve any request simultaneously. To improve performance, you can configure an optional logical cache using Redis.
 
@@ -16,15 +17,15 @@ Configure a load balancer:: Use platform-provided load balancing, such as OpenSh
 Enable health checks:: Configure the load balancer to probe backend health and remove failed instances from rotation.
 Disable session affinity (sticky sessions):: Database-backed sessions allow any instance to serve any request.
 
-.Database high availability
+== Database high availability
 {product-very-short} operations rely on PostgreSQL for persistence. A database outage renders the deployment non-functional until the database is restored. For production deployments, you must configure PostgreSQL with high availability (primary-replica replication) to minimize downtime.
 
 [IMPORTANT]
 ====
 If you use catalog providers exclusively, the database acts as an indexed cache. You do not require disaster recovery backups because you can repopulate catalog data from external sources of truth, such as Git repositories, CI/CD platforms, and monitoring tools.
 ====
 
-.Cache high availability (optional)
+== Cache high availability (optional)
 
 Configuring Redis as a shared logical cache improves production performance by sharing cached data across multiple backend instances. A shared cache makes sure that all instances access the same processed data, such as rendered TechDocs.
 

diff --git a/modules/about/con-integrations-in-rhdh.adoc b/modules/about/con-integrations-in-rhdh.adoc
@@ -3,6 +3,7 @@
 [id="integrations-in-rhdh_{context}"]
 = Integrations in {product}
 
+[role="_abstract"]
 {product} integrates seamlessly with {ocp-brand-name} and other tools, enabling comprehensive development and deployment workflows across enterprise.
 
 == Integration with {ocp-brand-name}

diff --git a/modules/about/con-system-architecture-for-deployment-planning.adoc b/modules/about/con-system-architecture-for-deployment-planning.adoc
@@ -3,7 +3,8 @@
 [id="con-system-architecture-for-deployment-planning_{context}"]
 = System architecture for deployment planning
 
-{product} ({product-very-short}) uses a client-server architecture with a browser-based frontend and a stateless backend service layer. Use this architecture to plan for horizontal scaling, high availability, and efficient data synchronization across the Software Catalog.
+[role="_abstract"]
+Understanding {product} client-server architecture helps you plan deployments for horizontal scaling, high availability, and efficient data synchronization across the Software Catalog.
 
 By understanding the {product-very-short} architecture, you can perform the following planning tasks:
 
@@ -17,10 +18,10 @@ image::rhdh/rhdh-architecture-diagram.png[]
 
 The {product-very-short} architecture includes three primary layers. While the data layer (PostgreSQL and optional Redis cache) stores the indexed Software Catalog, the source of truth remains in external systems, such as Git repositories, CI/CD platforms, and other integrations. Catalog providers continuously scan these external systems and synchronize data to the database for fast querying.
 
-.Frontend (Client)
+== Frontend (Client)
 The frontend is a browser-based single-page application (SPA). Use the frontend interface to browse the Software Catalog, interact with plugins, and connect to external integrations. The frontend communicates with the backend exclusively using REST API calls.
 
-.Backend (Service Layer)
+== Backend (Service Layer)
 The backend provides REST API endpoints for the frontend. It manages the Software Catalog (an inventory of your organization's software components, APIs, and resources) and handles authentication.
 
 The stateless design allows you to scale the backend horizontally by running multiple instances behind a load balancer. The backend externalizes all persistent state to a PostgreSQL database, including:
@@ -29,7 +30,7 @@ The stateless design allows you to scale the backend horizontally by running mul
 * Task history
 * Session data (managed through a database-backed session store)
 
-.External data dependencies
+== External data dependencies
 {product-very-short} requires PostgreSQL for persistence. For production environments, use a logical cache to improve performance.
 
 PostgreSQL database::

diff --git a/modules/about/con_understanding-internal-developer-platforms.adoc b/modules/about/con_understanding-internal-developer-platforms.adoc
@@ -3,7 +3,8 @@
 [id="understanding-internal-developer-platforms_{context}"]
 = Understanding internal developer platforms
 
-An internal developer platform (IDP) is a curated set of tools and services that supports developer self-service. Instead of navigating multiple systems, developers use a unified interface to provision environments, deploy code, and access APIs.
+[role="_abstract"]
+Internal developer platforms enable developer self-service through a unified interface for provisioning environments, deploying code, and accessing APIs, reducing complexity across development workflows.
 
 Why IDPs matter::
 
@@ -30,7 +31,7 @@ For developers::
 * *Cross-team visibility:* Developers can discover shared service catalogs and documentation to improve reuse and reduce duplication.
 * *Higher productivity:* Developers can spend more time building features and less time configuring infrastructure or resolving toolchain inconsistencies.
 
-.Key features
+== Key features
 
 Centralized dashboard::
 Access development tools, CI/CD pipelines, APIs, monitoring tools, and documentation from a single interface. Integrate with systems like Git, {ocp-brand-name}, Kubernetes, and JIRA.

diff --git a/modules/about/ref-customer-support-info.adoc b/modules/about/ref-customer-support-info.adoc
@@ -3,6 +3,9 @@
 [id="ref-customer-support-info_{context}"]
 = {product} support
 
+[role="_abstract"]
+{company-name} provides support resources through the Customer Portal, including technical support articles and the ability to create support cases for Global Support Services.
+
 If you experience difficulty with a procedure described in this documentation, visit the {company-name} Customer Portal.
 You can use the {company-name} Customer Portal for the following purposes:
 

diff --git a/modules/about/ref-rhdh-sizing.adoc b/modules/about/ref-rhdh-sizing.adoc
@@ -3,7 +3,9 @@
 [id="rhdh-sizing_{context}"]
 = Sizing requirements for {product}
 
-Learn about sizing requirements for {product}.
+[role="_abstract"]
+Plan infrastructure resources for {product} deployments using sizing requirements for the application, database, and Operator based on deployment scale.
+
 Table 1 lists the sizing requirements for installing and running {product}, including {product-short} application, database components, and Operator.
 Table 2 lists recommended sizing requirements for {product-docs-link}/html-single/configuring_red_hat_developer_hub/index#configuring-external-postgresql-databases[external PostgreSQL deployment] based on the deployment scale.
 

diff --git a/modules/about/ref-supported-platforms.adoc b/modules/about/ref-supported-platforms.adoc
@@ -3,7 +3,8 @@
 [id="supported-platforms_{context}"]
 = Supported platforms
 
-You can find the supported platforms and life cycle dates for both current and past versions of {product} on the Life Cycle page.
+[role="_abstract"]
+Verify platform compatibility and life cycle support for {product} versions to plan deployments and ensure continued product support.
 
 .Additional resources
 * link:https://access.redhat.com/support/policy/updates/developerhub[Life Cycle page]