App Hub overview

As you develop your cloud infrastructure, you might organize your Google Cloud resources across multiple projects. You might also have many resources within one or multiple projects that provide an integrated business function that you want to group logically. The resource hierarchy in Google Cloud can make it challenging to manage and organize your infrastructure for these grouping purposes. App Hub provides an application-centric way to group and manage services and workloads, helping you align your infrastructure with your business functions.

App Hub acts as the foundational data model and central registry for your applications on Google Cloud. It creates a single source of truth that clarifies resource ownership, dependencies, and business context. This, in turn, supports other Google Cloud products with the application-centric context they need. For more information about this application-centric model and its features, see Application-centric Google Cloud .

This document provides a conceptual overview of App Hub to help you understand its capabilities and benefits before you set up or administer it.

Why use App Hub?

By shifting the focus from individual infrastructure resources to the applications they form, App Hub helps you streamline governance and operations at scale.

App Hub helps you implement the following application-centric capabilities:

Organize and catalog your applications: Group scattered Google Cloud resources from one or more projects into logical App Hub applications. You can then find properties and categorize these applications with attributes like owners, business criticality, and environment to improve discoverability and accountability. For more information, see Support discoverability and governance .
Create a unified view for your teams: By defining an application in App Hub, you provide essential context to other Google Cloud products. For example, you might enable the following features:
- A central view of operations and insights in Cloud Hub , which displays alerts, incidents, and performance data in an application context.
- AI-powered assistance from Gemini Cloud Assist , which uses App Hub's data model to help you design, operate, and troubleshoot your applications.
- Application monitoring with Google Cloud Observability to help you troubleshoot errors and improve performance by displaying telemetry data for your applications and their components.
Clarify ownership and dependencies: Understand how your applications are composed and how their components depend on each other. This feature helps developers and operators visualize application architecture, identify owners, and resolve issues.

To learn more about how App Hub fits into the broader application lifecycle, see Application-centric Google Cloud .

App Hub concepts and data model

App Hub is built on a data model based on the following key concepts: applications, services, and workloads. These terms are common in the industry, but App Hub uses them in a specific way.

The following table compares the App Hub definition with common industry usage:

Concept	App Hub definition	Common industry usage
Application	A logical grouping of services and workloads that together deliver a business function.	Can refer to a single deployable unit, a codebase, or a broad system.
Service	A network or API interface that exposes functionality to clients and can route requests to workloads, such as a load balancer.	Often refers to a microservice, a deployable component, or binary code with its own business logic and data.
Workload	The compute resources where the binary deployments of your application are installed. The application code from these resources performs a discrete part of your business logic. For example, a workload can be a GKE deployment or a Compute Engine managed instance group (MIG) running the code of an AI agent.	A more general term for any process or component that consumes computing resources.

For more information about these and other Application-centric Google Cloud central concepts, see Key concepts . For a list of supported resources in App Hub that you can register as services or workloads in your applications, see App Hub supported resources .

You can define App Hub applications based on your geographic distribution requirements. Your location choice impacts which services and workloads you can register in applications and can be important for data residency requirements. You can designate the following locations:

Global applications:group services and workloads from multiple Google Cloud regions.
Regional applications:group services and workloads that all reside within a single region.

For a detailed comparison to help you choose the right location, see Global and regional applications .

Services and workloads show a registration status in your applications. Additionally, applications, services, and workloads can contain metadata in the form of properties and attributes to support discoverability and governance .

You can view details of your deployed applications and their services and workloads, including location, registration status, and metadata. For more information, see View details of services and workloads and View application details .

Registration status of services and workloads

The organizational structure of your Google Cloud resources affects how App Hub can manage services and workloads and lets you register them in applications. Services and workloads that you can register to an application have one of the following registration status:

Discovered: Services and workloads that you can register to an application because they are part of the application management boundary that you define and aren't registered to any other application or can be registered to multiple applications. Discovered services and workloads also include services or workloads that you delete or unregister from an application but that you can register again.

Note: Some services are designated as shared services and you can register them to multiple applications. This is indicated by their registration type property . Even if you have registered shared services to an application, they can have a registration status of discovered in other applications.
Registered: Services and workloads registered to an application and managed by App Hub. You can only register discovered services and workloads. After you register the service or workload, the registration status updates from discovered to registered .
Detached: Services or workloads that have been registered to an application, but that App Hub can't manage or monitor because their underlying Google Cloud resources are no longer part of the application management boundary that you have defined. The registration status of services and workloads registered to an application can change to detached for the following reasons:
- The underlying resource is deleted. For example, if you delete a forwarding rule represented by a service, the service's registration status changes to detached .
- A project or folder containing underlying resources for registered services or workloads is moved out of the application management boundary.
Detached services and workloads remain in the application until you unregister them.

If you move a project out of the application management boundary, its detached services and workloads can become discoverable for applications in a different boundary. You can register discoverable services and workloads again, adhering to the resource hierarchy established by the application management boundary.

To select an application management boundary that fits your resource hierarchy in Google Cloud and let App Hub discover and register the services and workloads that your business needs, see Choose your application setup model . To view the registration status of services and workloads, see View details of services and workloads .

Support discoverability and governance

To enrich the data model, App Hub lets you expose properties and attributes to support application discoverability, accountability, and governance. Defining these values as application metadata helps you filter, manage, and apply policies to your application components at scale.

To view the properties and attributes of the services and workloads in your applications, see View details of services and workloads .

The following are the definitions and features of properties and attributes:

Propertiesare immutable fields that describe the underlying infrastructure of a registered service or workload, such as the project ID, location, or type. These are discovered automatically and cannot be edited in App Hub. Key supported properties include:
- Registration type: for services, an output-only property that indicates if a service can be registered to one or multiple applications. The following are the possible values for this property:
  - EXCLUSIVE : you can only register the service to a single application.
  - SHARED : you can register the service to multiple applications. This value indicates that the service is a shared service .
- Functional type: an output-only property that identifies the known function of a service or workload. For example, when an AI agent is deployed through a managed platform like Vertex AI Agent Engine , App Hub automatically classifies the resource with the AGENT functional type value to indicate that the workload runs an AI agent.
- Extended metadata: an schema-driven property that provides rich, structured information about the service or workload. It refers to a key-value field that adds detailed, type-specific data. For example, workloads with a functional type value of AGENT can include apphub.googleapis.com/AgentProperties metadata, which contains information about an agent that is compatible with the Agent2Agent (A2A) Agent Card . For a list of supported metadata types and their schemas, see Extended metadata schemas .
- Identity: an output-only property that contains the service account or managed workload identity name for a service or workload.
Attributesare mutable, user-defined metadata that you can apply to applications, services, and workloads to organize and govern them. You can add attributes to applications, services, and workloads when you create an application and register resources to it . You can also update service and workload attributes and update application attributes . Key attributes include:
- Owners:Contact information for developer, operator, and business teams. The supported owner types are:
  - developer_owners : Development team that owns development and coding.
  - operator_owners : Operator team that ensures runtime and operations integrity.
  - business_owners : Business team that ensures quality and user expectations are met.
- Criticality:The importance of the component to your business. The supported values are:
  - MISSION_CRITICAL
  - HIGH
  - MEDIUM
  - LOW
- Environment:The lifecycle stage of the component. The supported values are:
  - PRODUCTION
  - STAGING
  - DEVELOPMENT
  - TEST

The App Hub resource model

To enable application-centric features, App Hub uses a resource model centered on the concepts of the management project and the application management boundary .

This application management layer that App Hub introduces on top of your resource hierarchy in Google Cloud lets App Hub discover services and workloads that you can group in applications. You can choose a setup model for applications and set an application management boundary that best fits your resource hierarchy and governance needs:

Recommended: Folder-level boundary: If your components are organized within a Google Cloud folder structure, you can use a folder as your boundary. This approach aligns your application management boundary with your organization's structure by business unit, environment, or team, and automatically includes all projects within that folder.
Single-project boundary: For small applications where all Google Cloud resources reside in one project, you can designate that single project as your boundary. This is the quickest way to get started with application management. You can define single-project boundaries by configuring the project as a host project.
(Legacy) Multiple-project boundary with a host project: For existing users, App Hub supports a legacy model where you can designate a host project for application management by enabling the App Hub API on a Google Cloud project. Then, you manually connect other Google Cloud projects, known as service projects, to it for multi-project resource discovery.

For information about data handling in this resource organization and other application-centric features, see Application-centric Google Cloud . For detailed instructions on getting started and to define an application management boundary, see Choose your application setup model .

What's next

To see which Google Cloud resources you can register in App Hub, see Supported resources .
To get started with defining an application management boundary, see Choose your application setup model .
To understand the permissions required to use App Hub, see Roles and permissions .