Making sense of configuration in AEM as a Cloud Service | Community
Skip to main content
konstantyn_diachenko
Community Advisor
konstantyn_diachenkoCommunity Advisor
Community Advisor
February 2, 2026

Making sense of configuration in AEM as a Cloud Service

  • February 2, 2026
  • 1 reply
  • 26 views

Adobe Experience Manager as a Cloud Service (AEMaaCS) introduced a stricter and more explicit approach to configuration management. Configuration is no longer a runtime concern but a core part of application architecture, deployment, and governance.

This overview summarizes the primary configuration models available in AEMaaCS and their intended use cases. For a deeper explanation, architectural guidance, and practical examples, see:
https://medium.com/@konstantyn.diachenko/making-sense-of-configuration-in-aem-as-a-cloud-service-7f2fc567e58d

OSGi Configuration

OSGi configurations define technical and behavioral aspects of code execution, such as:

  • Service wiring

  • Feature flags

  • External integrations

  • System thresholds and limits

In AEMaaCS, OSGi configurations are:

  • Immutable at runtime

  • Deployed through CI/CD

  • Parameterized using environment variables where needed

Use OSGi configuration when values are developer-owned and affect application behavior.

Context-aware configuration

Context-Aware Configurations (CA Configs) support content- and site-specific variation, including:

  • Brand or site-level settings

  • Language or region behavior

  • Author-controlled decisions

Key characteristics:

  • Stored within content hierarchy

  • Inherited by structure

  • Editable by authors with proper governance

Use CA Configs when configuration depends on site context rather than environment.

Cloud environment variables

Cloud environment variables are used for environment-specific and sensitive values, such as:

  • Secrets and credentials

  • External service endpoints

  • Environment-dependent toggles

These values are managed outside of code and content and injected at runtime.

Use environment variables when values differ by environment or must remain secure.

Choosing the correct model

Selecting the correct configuration type depends on:

  • Ownership (developer vs author vs platform)

  • Scope (code, content, environment)

  • Frequency of change

  • Security requirements

Using the appropriate model improves deployment safety, clarity of ownership, and long-term maintainability.

Key takeaways

  • AEMaaCS enforces clear configuration boundaries

  • OSGi, Context-Aware Configs, and environment variables serve distinct purposes

  • Correct model selection is essential for safe cloud deployments

    1 reply

    kautuk_sahni
    Community Manager
    kautuk_sahniCommunity Manager
    Community Manager
    February 3, 2026

    ​@konstantyn_diachenko This is a really clear and timely breakdown, configuration in AEMaaCS is one of those areas where legacy habits from on-prem can quietly cause pain if teams don’t reset their mental model.

    Quick Question for you, when you work with teams new to AEMaaCS, which configuration model do they tend to misuse most often at first — OSGi vs CA Configs, or CA Configs vs environment variables — and why do you think that is?

    Kautuk Sahni
      konstantyn_diachenko
      Community Advisor
      konstantyn_diachenkoCommunity AdvisorAuthor
      Community Advisor
      February 3, 2026

      Hi ​@kautuk_sahni ,

      That’s a great question. Thank you!

      In practice, the most common initial misuse I see is OSGi configuration, especially among teams coming from on-prem or AMS backgrounds.

      Many teams continue to create OSGi configs the way they used to: treating them as something flexible that can be adjusted at runtime. This works well locally and during early development, so it feels natural at first. The problem is that in AEM as a Cloud Service, those configurations become effectively immutable after deployment unless they are explicitly parameterized using environment variables or secrets.

      This often surfaces during code reviews, where OSGi configs contain values that teams expect to “just change later” - but in reality require a new pipeline run to adjust.

      At the same time, CA Configuration is still underused, despite being a mature and very powerful model. I actively try to introduce CA Configs on new projects, especially for multi-site and multi-language setups. They solve a whole class of problems around content-driven behavior and ownership boundaries.

      I sometimes even use CA Configs as feature flags with configuration, not just on/off switches. When designed with backward compatibility, disabling a feature for a specific site or market doesn’t break anything - the default behavior remains intact.

      That distinction - OSGi for code behavior, CA Configs for content intent, environment variables for operational concerns — is the mental model I try to help teams adopt early. Most of the friction disappears once that separation is clear.

      Kostiantyn Diachenko, Community Advisor, Certified Senior AEM Developer, creator of free AEM VLT Tool, maintainer of AEM Tools plugin.
        Terms & ConditionsAccessibility statement

        Loading footer...