Mutable vs Immutable Content

The split

AEM as a Cloud Service divides the repository in two, and the line is absolute:

• Immutable — /apps and /libs. Written only at deployment time. Read-only at runtime, for everyone, including admin.
• Mutable — /content, /conf, /var, /home, /etc. Writable at runtime by authors, workflows and your code.

This is not a policy someone can relax. It is enforced by the runtime, and it is what makes Cloud Service's deployment model possible: because /apps can only change through a deployment, Adobe can build a new instance from the deployed artefact, run both versions side by side, and cut over — the blue/green rollout you get for free on every deploy.

Where things actually go

• Component definitions, HTL, dialogs, clientlibs, template types → /apps, from ui.apps.
• OSGi configuration → /apps/<appId>/osgiconfig, from ui.config.
• Editable templates and policies → /conf, from ui.content. Authors with the right permissions can edit these at runtime, which is the entire point of "editable".
• Pages and assets → /content, owned by authors.

Note the asymmetry that trips people up: template types are immutable code, but the templates made from them are mutable configuration. That is deliberate — developers define what kinds of pages are possible, authors compose specific ones.

repoinit: creating mutable things at startup

Some mutable structures must exist before any author touches the system — a service user, a folder with specific ACLs, a base content path. You cannot ship those in ui.apps (wrong side of the line) and shipping them in ui.content would overwrite them on every deploy.

The answer is repoinit: a small declarative language, delivered as an OSGi configuration, executed at startup. It is idempotent, so running it repeatedly is safe:

create service user wknd-content-reader with path system/wknd

create path (sling:Folder) /content/wknd/settings

set ACL for wknd-content-reader
    allow jcr:read on /content/wknd
end

This is the supported way to create service users and ACLs on Cloud Service, and it is what day 31 builds on. Because it lives in ui.config, it is versioned in Git and deployed by the pipeline like everything else.

The Repository Structure Package

FileVault will not let a package define a filter for a path that no package in the build actually creates — it cannot know whether the parent exists. But your ui.apps and ui.content packages legitimately need to write into shared roots like /apps/wknd and /conf/wknd.

The Repository Structure Package solves this. It is an (almost empty) package whose only job is to declare the roots your other packages depend on. Sub-packages reference it via <repositoryStructurePackages> in their filevault-package-maven-plugin configuration, and the build then validates that every filter falls inside a declared root.