Choose your App Hub setup model

Organize your infrastructure resources into App Hub applications using an app-enabled folder (Preview) or a host project.

App-enabled folder

Recommended

An app-enabled folder is a Google Cloud folder that lets you group infrastructure resources as services and workloads in App Hub applications. App-enabled folders provision application management across all the projects under the folder. App-enabled folders also have access to features such as Application Design Center and Gemini Cloud Assist. For more information on how to set up your App Hub applications in an app-enabled folder, see Set up App Hub for an app-enabled folder.

Host project

A host project is a Google Cloud project that that lets you group infrastructure resources as services and workloads in App Hub applications. For more information, see Set up App Hub for 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 following are recommended considerations for your resource hierarchy when choosing your setup model for managing applications:

If using host projects:

  • All resources must be in the specific service projects that you manually attach to the host project to be registrable in App Hub applications.

If using 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.

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 common patterns that we recommend for careful planning of your folder and project structure:

  • 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.
  • Create a nested structure of app-enabled folders: Organize by business units, teams, or environments with hierarchical control. For example, 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.

What's next