Google Cloud AppLifecycle Manager Adds Feature Flags for Production Releases

Deploying new code to production does not always mean a new feature should become available to every user immediately. A feature might work correctly in testing but introduce unexpected errors under real traffic, increase database load, or behave differently for a particular customer.

Feature flags help developers manage this risk by separating code deployment from feature release. Teams can deploy a feature while keeping it disabled, enable it for selected users, and expand access after validating its behavior.

Google Cloud introduced AppLifecycle Manager Feature Flags in public preview on May 21, 2026. The capability allows developers to manage application behavior through centrally controlled flags, targeted releases, and progressive rollouts.

For developers working on SaaS applications and cloud-native systems, this provides a way to control when features become available without requiring a new application deployment for every release decision.

What Is AppLifecycle Manager?

Google Cloud AppLifecycle Manager is a service for managing application deployments, updates, and operations at scale. It supports deployment and rollout workflows for applications, including SaaS offerings that may serve multiple tenants.

Its feature flag capability extends this management model to application functionality.

Instead of treating every release as a single event, developers can deploy code first and manage feature availability separately. A flag can determine whether a particular capability is enabled for an application, tenant, environment, or eligible group of users.

For example, a SaaS application might introduce a new reporting dashboard. The team can deploy the code with the dashboard disabled, enable it for internal testers, and then expand availability after monitoring its behavior.

AppLifecycle Manager supports both integrated and standalone approaches:

Integrated approach: Manage feature flags alongside application deployments and rollouts controlled by AppLifecycle Manager.
Standalone approach: Use its feature flag capabilities for applications whose infrastructure is managed independently.

This flexibility allows teams to adopt centralized feature management without necessarily moving their entire deployment process to AppLifecycle Manager.

Why Separate Deployment From Feature Release?

Traditional deployment workflows often make a new feature available as soon as the updated application reaches production. If the feature introduces a problem, teams may need to roll back the application or deploy another fix.

Feature flags introduce an additional control point.

Deployment approach	Traditional release	Feature-flag-based release
Code deployment	Often makes the new feature available immediately	Can deploy code while keeping the feature disabled
Initial exposure	May affect all users at once	Can target a limited audience
Gradual release	Requires additional deployment or traffic-management mechanisms	Can use controlled flag rollouts
Response to a feature problem	May require a code rollback	Can disable the feature if the flag and application are designed for this
Testing in production	Requires a separate release strategy	Can expose the feature to selected users
Configuration changes	May require application configuration updates or redeployment	Supported flag values can be updated through the flag management workflow

The distinction is especially useful for applications that deploy frequently but need tighter control over customer-facing changes.

However, disabling a flag only changes the behavior controlled by that flag. It does not reverse database migrations, undo external side effects, or repair unrelated application defects. Teams still need a rollback strategy for changes that cannot be safely disabled.

How AppLifecycle Manager Feature Flags Work

Feature flag management involves two related parts: defining the desired behavior and making that configuration available to the application.

1. Define a Feature Flag

A flag has a key that application code can use to identify the feature. For example:

enable-new-dashboard

The flag can represent a Boolean decision, such as whether the dashboard is enabled, or a supported configuration value that changes application behavior.

AppLifecycle Manager also uses concepts such as units, unit kinds, revisions, releases, and rollouts to organize and distribute configuration.

A unit can represent a managed application instance, tenant, or other deployment target. A unit kind groups compatible units that receive a particular configuration.

2. Create a Release

A flag definition describes the configuration to manage. A release captures the intended flag configuration for the relevant targets.

This makes it possible to prepare a change before distributing it to application instances.

3. Initiate a Rollout

Creating or updating a flag does not necessarily make the change immediately available to every target. In the integrated workflow, the configuration must be provisioned through an AppLifecycle Manager rollout.

This gives teams a controlled point at which to distribute the new configuration.

4. Evaluate the Flag in Application Code

The application reads the flag through a compatible OpenFeature SDK and the configured flagd provider.

The application then decides which implementation path to execute.

The overall workflow looks like this:

Define Feature Flag
        |
        v
Create Flag Revision
        |
        v
Prepare Flag Release
        |
        v
Initiate Controlled Rollout
        |
        v
Application Receives Configuration
        |
        v
Evaluate Flag in Application Code
        |
        v
Enable or Disable Feature

The exact setup depends on whether the application uses AppLifecycle Manager for deployment management or uses the feature flag service independently.

Practical Example: Releasing a New Dashboard in ASP.NET Core

Consider an ASP.NET Core application that provides analytics dashboards to SaaS customers.

The team has developed a new dashboard, but it wants to validate the implementation with internal users before making it available to every customer.

The feature flag can control which dashboard implementation the application uses.

The following example illustrates the application-level decision. It is a simplified C# example, not a complete AppLifecycle Manager SDK integration.

app.MapGet("/dashboard", async (
    HttpContext context,
    IDashboardService dashboardService,
    IFeatureFlagService featureFlags) =>
{
    var userId = context.User.FindFirst("sub")?.Value;

    if (string.IsNullOrWhiteSpace(userId))
    {
        return Results.Unauthorized();
    }

    var useNewDashboard = await featureFlags
        .IsEnabledAsync("enable-new-dashboard", userId);

    if (useNewDashboard)
    {
        var newDashboard = await dashboardService
            .GetNewDashboardAsync(userId);

        return Results.Ok(newDashboard);
    }

    var existingDashboard = await dashboardService
        .GetExistingDashboardAsync(userId);

    return Results.Ok(existingDashboard);
});

The example assumes that IDashboardService and IFeatureFlagService are application-defined abstractions. Their implementations must connect to the application's database and configured feature flag provider.

The important part is the separation between the feature decision and the business logic.

The team can keep the new dashboard code deployed while controlling whether eligible users receive the new implementation.

In a real application, the developer must also ensure that the user identity is trustworthy, that authorization is enforced independently of the flag, and that both implementations handle failures correctly.

Gradual Rollouts With Common Expression Language

One of the useful capabilities of AppLifecycle Manager is support for targeting rules based on Common Expression Language (CEL).

CEL allows teams to express conditions using attributes associated with a request, user, tenant, or other supported evaluation context.

For example, a team may want to expose a new search algorithm to a small percentage of traffic before expanding the rollout.

A simplified targeting condition might look like this:

userID == "internal-tester-01"

This illustrates an allowlisting rule. It is not a complete production rollout configuration.

For percentage-based targeting, AppLifecycle Manager documentation describes allocation and rollout mechanisms that can gradually increase exposure, such as moving from 1% to 5%, then to 25%, and eventually to all eligible users.

The exact rule syntax and supported attributes depend on the configured flag and evaluation context.

A controlled rollout generally follows these stages:

Enable the feature for internal testers.
Verify functionality using representative workloads.
Expose the feature to a small percentage of eligible traffic.
Monitor application errors, latency, and business metrics.
Expand the rollout if the results remain acceptable.
Pause or disable the feature if predefined thresholds are exceeded.

Percentage-based exposure is useful only when the targeting strategy consistently identifies the intended users or requests. Teams should verify how traffic allocation is implemented rather than assuming that every request receives an independent random decision.

Using Feature Flags for AI Application Configuration

Feature flags are not limited to switching between two implementations of a user interface.

AppLifecycle Manager also supports configuration values that can influence application behavior. This is relevant for AI applications, where developers may need to adjust prompts, select an implementation, or enable an experimental workflow.

For example, an application might use a configuration value to select between two approved prompt templates.

public sealed class PromptConfiguration
{
    public string ActivePrompt { get; init; } =
        "assistant-default";
}

public async Task<string> GenerateResponseAsync(
    string question,
    PromptConfiguration configuration)
{
    var prompt = configuration.ActivePrompt switch
    {
        "assistant-v2" =>
            $"Use the updated response instructions.\n{question}",

        _ =>
            $"Answer clearly and accurately.\n{question}"
    };

    return await modelClient.GenerateAsync(prompt);
}

This example illustrates how application behavior can depend on a configuration value. It does not implement a Google Cloud flag provider.

In production, the selected value should come from the application's approved configuration source, and the application should validate it before use.

Changing a prompt through configuration can avoid a code deployment when the application is already designed to read that configuration dynamically. It does not eliminate the need to evaluate prompt changes for correctness, security, cost, and output quality.

OpenFeature and Avoiding Vendor Lock-In

AppLifecycle Manager Feature Flags are built around the OpenFeature standard and use the flagd evaluation engine.

OpenFeature provides a vendor-neutral approach to feature flag evaluation through standardized SDK interfaces. This can reduce the amount of application code tied directly to one feature management implementation.

The distinction is useful when an organization expects its deployment architecture or feature management requirements to change.

Approach	Main consideration
Direct provider-specific integration	Can offer provider-specific functionality but may increase application coupling
OpenFeature-based integration	Provides a standard evaluation interface while allowing a compatible provider to supply flag values
Application-defined abstraction	Gives the team control over its internal API but requires additional implementation and maintenance

Using OpenFeature does not make every provider interchangeable without configuration changes. Provider capabilities, targeting rules, configuration management, and rollout processes can differ.

Teams should keep provider-specific setup separate from business logic and test the behavior when configuration cannot be retrieved.

Production Considerations and Limitations

Feature flags reduce the risk associated with releasing new functionality, but they also introduce additional operational responsibilities.

Flag Configuration Is Not Always Immediately Available

In AppLifecycle Manager's integrated workflow, configuration changes are distributed through rollouts. Developers should understand the propagation process and verify when a new value becomes effective.

Do not assume that creating a flag automatically updates every application instance.

A Feature Flag Is Not an Authorization Mechanism

A flag can control feature availability, but it should not replace authentication, authorization, or access-control policies.

A disabled user interface element does not prevent a user from directly calling a protected API. The backend must enforce access independently.

Flag Evaluation Can Fail

Applications should define a safe default when a flag cannot be evaluated or its configuration is unavailable.

For a new payment workflow or destructive operation, the appropriate fallback may be to keep the feature disabled. For a noncritical display enhancement, a fallback to the existing implementation may be reasonable.

The correct choice depends on the feature's risk and business requirements.

Too Many Flags Increase Complexity

Long-lived flags can create multiple code paths that need testing and maintenance. Teams should assign ownership, document the purpose of each flag, and remove obsolete flags when they are no longer required.

Preview Status Matters

AppLifecycle Manager Feature Flags were announced in public preview. Google's documentation continues to label the feature as Preview, which means availability, support, and terms may differ from a generally available production service.

Teams should review the current product documentation and pre-GA terms before adopting the capability for critical workloads.

Best Practices for Using AppLifecycle Manager Feature Flags

Follow these practices when introducing feature flags into a production application:

Use meaningful flag names. Names such as enable-new-dashboard communicate purpose more clearly than generic identifiers.
Define a safe default. Decide what should happen when the flag is unavailable or its value cannot be evaluated.
Separate flags from authorization. Continue to enforce permissions in the backend and data layer.
Monitor each rollout. Track errors, latency, resource consumption, and business outcomes as exposure increases.
Use staged releases. Begin with a limited audience and expand only after validating the results.
Assign flag ownership. Record who owns the flag, why it exists, and when it should be removed.
Test both code paths. Verify the enabled and disabled behavior, including failure scenarios.
Plan flag cleanup. Remove obsolete conditional logic and configuration after a feature becomes the standard behavior.
Maintain a separate rollback strategy. Use feature flags for reversible behavior changes, but retain deployment and database rollback procedures where necessary.

These practices help prevent feature management from becoming a source of hidden complexity.

Conclusion

Google Cloud AppLifecycle Manager Feature Flags introduce a controlled way to manage application behavior independently of code deployment.

By combining flag definitions, releases, targeting rules, and progressive rollouts, teams can expose new functionality gradually and disable problematic features without necessarily rolling back an entire application deployment.

The integration with OpenFeature also provides a standards-based approach to flag evaluation, while support for integrated and standalone management makes the capability relevant to different deployment architectures.

For developers, the practical approach is to start with a low-risk feature, establish clear rollout criteria, monitor real application behavior, and plan for flag cleanup. Feature flags do not replace testing or safe deployment practices, but they provide an additional control point between deploying code and making it available to users.