Choose your App Hub setup model

To effectively organize your infrastructure resources into App Hub applications, you must choose a setup model for application management. App Hub offers the following models:

App-enabled folder (Preview): The recommended model for new application grouping implementations. It configures a standard Google Cloud folder for application management, unlocking all available features from Application-centric Google Cloud.
Host project: The supported model for existing App Hub users, which configures a standard Google Cloud project to group resources.

The following table makes a comparison between the available application management setup models to give you a summarized view of key differences and help you choose the option that best suits your needs:

Feature	App-enabled folder	Host project
Recommendation	Recommended for new users	Supported model for existing users
Primary boundary	The app-enabled folder with all its descendants	The host project and any manually attached service projects
Resource discovery	Automatic within the folder and its descendants	Manual attachment of service projects required
Management project	Automatically created by Google	Not applicable
Key features	Full access to Application-centric Google Cloud features, including enhanced monitoring in Cloud Hub and Google Cloud Observability products, application design and deployment in Application Design Center, and application optimization using Gemini Cloud Assist	Basic application grouping, with limited support for viewing observability data in App Hub or in Cloud Logging, Cloud Monitoring, and Cloud Trace
IAM strategy	Granular permission control at the folder, management project, or individual application level	Project-level permission control
API enablement	Automatic on management project	Manual on host project
Scalability	Designed for organizational scale	Limited by project resource
Setup complexity	Upfront planning for folder structure	Direct initial setup with manual linking
Setup instructions	Set up App Hub with app-enabled folders	Set up App Hub with a host project

This page guides you through selecting the best model for your application management needs, detailing the benefits, considerations, and feature differences between them.

App-enabled folder

Recommended

An app-enabled folder is a standard Google Cloud folder that you configure for application management. This model acts as an administrative boundary for your applications and is the foundation for the application management experience on Application-centric Google Cloud.

When you enable a folder for application management, Google Cloud automatically creates a management project within it. This management project stores all your application models, metadata, and configurations for services like App Hub and Application Design Center. It also handles the automatic enablement of required APIs.

Benefits:

Hierarchical resource discovery: Group any supported services and workloads within all projects or nested folders in the app-enabled folder as single applications.
Full feature access: Unlock the complete range of application management capabilities, including Application Design Center for designing and deploying applications, and AI-powered assistance from Gemini Cloud Assist.
Centralized metadata: The management project created in the app-enabled folder provides a single source of truth for application definitions and attributes.
Scalable governance: Align application management with your organizational structure using folders.

Considerations:

Folder structure: Carefully plan your Google Cloud resource hierarchy. Applications within an app-enabled folder can include resources from any project within that folder or its descendants. Consider organizing folders by business unit, environment, or team to suit your needs.
IAM strategy: You can typically grant permissions on the app-enabled folder itself or the management project, following standard IAM inheritance rules. This practice enables fine-grained access control.
Billing: We recommend that you understand how billing is associated, particularly for APIs and services that are automatically enabled or used within applications.
API enablement: Key APIs for Application-centric Google Cloud are automatically enabled on the management project.

For setup instructions, see Set up App Hub with app-enabled folders.

Host project

A host project is a standard Google Cloud project that you can use to group services and workloads into App Hub applications. Host projects are a supported setup model for existing App Hub users. However, they don't support the full range of application management features from Application-centric Google Cloud and require manual configuration for resource inclusion.

Limitations:

Manual resource linking: You must manually attach each service project containing the resources you want to group as applications to the host project. Resources in unlinked projects are not visible to App Hub.
Limited feature set: Host projects don't support features available with app-enabled folders, such as Application Design Center integration and automatic API enablement through a management project.
Project resource boundary: Application management is confined within the limits of the host project and the manually attached service projects, which might not reflect your organizational structures.

We encourage existing host project users to plan for migration. For setup instructions, see Set up App Hub with a host project.

Plan for the structure of your resource hierarchy

The foundation for organizing App Hub applications is either the app-enabled folder or the host project, depending on your chosen setup model. App Hub's data model is built on top of the standard Google Cloud resource hierarchy, maintaining the same hierarchical rules and inheritance policies.

You can effectively combine the benefits of the Google Cloud resource hierarchy with the application capabilities of App Hub by mapping your expected application boundaries to the foundational app-enabled folder or host project of your setup model. Think of App Hub's data model as an overlay on the standard Google Cloud resource hierarchy:

Folders and projects are boundaries: Folders and projects in Resource Manager group resources for policy inheritance and organization in the same way that app-enabled folders or host projects define the administrative boundaries for applications.
Roles and permissions are inherited: IAM roles and permissions for App Hub are granted on the management project, the app-enabled folder itself, or the host project, following standard IAM inheritance rules.
Metadata is centralized: The management project or host project centralizes application metadata, adding an application-aware layer to resource management.

For more details on resource organization, see Resource organization concepts and Configure a folder for app management.

Resource hierarchy considerations

The choice between an app-enabled folder and a host project fundamentally shapes how you organize your resources for App Hub. As a best practice, thoughtful planning of your Google Cloud resource hierarchy is essential.

The following are recommended considerations for your resource hierarchy when choosing your setup model for managing applications:

App-enabled folders:
- Services and workloads must reside within projects in the app-enabled folder or its descendants to be registrable in App Hub applications within the folder's administrative boundary.
- The automatic discovery of services and workloads operates within the boundary of the specific app-enabled folder and its descendant projects.
- Carefully plan your folder structure:
  - Use a single app-enabled folder to manage applications across many projects within it.
  - Create nested app-enabled folders to delegate application management to different teams or business units, providing more granular control over applications.
Host projects:
- All resources must be in the service projects that you manually attach to the host project so that you can register the resources in App Hub applications.

Refer to Patterns for resource structures for common organizational approaches.

As illustrated in Managing applications in a folder, enabling application management on a parent folder, such as F1, allows applications within that folder to include resources from projects directly within it, such as P10 and P11, as well as from projects within nested folders, such as P20 and P21 within F2.

An application with
projects P10 and P20, spanning folder levels.

If you only enable application management on the nested folder F2, applications in that folder can only use resources from projects within it, such as P20 and P21. Resources in the parent folder F1, such as P10 and P11, aren't available to applications in F2. To include resources from a project in the parent folder, you would have to move that project to F2.

An application with
projects P10 and P20, but P10 has moved to folder F2.

Patterns for resource structures

The following are recommended patterns for structuring your folders and projects:

A single app-enabled folder: Start the configuration in small organizations or for initial adoption, consolidating application management within a single administrative boundary.
An app-enabled folder per environment: Enforce strong isolation between development environments, allowing different policies and reducing risk.
An app-enabled folder per business unit or team: Align management with your organizational structure and team responsibilities, promoting autonomy. You can implement this practice by structuring multiple separate app-enabled folders.
A nested structure of app-enabled folders: Organize with hierarchical control in mind, for example, by business unit, team, or environment. You can create top-level folders for business units, with nested folders for development, staging, and production environments within each unit. This pattern utilizes the app-enabled folder structures outlined in Resource hierarchy considerations.
A host project per application or group of applications: Organize existing resources from your standard projects, suitable for organizations accustomed to project-based separation of concerns or those with existing applications managed this way.