---
title: Package and deploy CMS apps
slug: cms-13/docs/package-and-deploy-cms-apps
docTags: 
createdAt: 2026-07-30T20:22:08.991Z
---

Shell modules define an app's folder structure, routing, and configuration. Configure them to register your app's assemblies, define virtual paths, and control access.

An app (sometimes called an add-on) contains components that extend the functionality of an Optimizely website: initializable modules, gadgets, audience criteria, virtual path providers, and page and search providers. See also [Apps platform compatibility](docId\:oGp5aaps96qkEIgnCuF_p).

## Configure shell modules

An app (add-on) is packaged and deployed as a shell module. Configure modules in `appSettings.json` to associate a virtual path to an assembly that contains gadgets and other plug-ins. The following example defines a module of the assembly `QuickChat.dll` and associates it with the virtual path `/modules/QuickChat`.

```xml
<episerver.shell>
	<publicModules rootPath="~/modules/" autoDiscovery="Minimal">
		<add name="QuickChat">
			<assemblies>
				<add assembly="QuickChat" />
			</assemblies>
		</add>
	</publicModules>
</episerver.shell>
```

The following example configures a `PublicTemplates` module. The module's disk location is the root of the application (`~/`), which means that relative references to client resources and menu items are based on this URL. Furthermore, Optimizely maps the module to an assembly, `EPiServer.Templates.Public`, which means Optimizely routes controllers in this assembly through the path format `modules/PublicTemplates/{controller}/{action}`. The shell initialization module set up this route.

```xml
<episerver.shell>
	<publicModules rootPath="~/modules/" autoDiscovery="Minimal">
		<add name="PublicTemplates" resourcePath="~/">
			<assemblies>
				<add assembly="EPiServer.Templates.Public" />
			</assemblies>
		</add>
	</publicModules>
</episerver.shell>
```

## `protectedModules` and `publicModules`

These elements contain collections of shell modules. `protectedModules` maps to a path protected by ASP.NET authorization rules. `publicModules` maps to a path open to everyone.

**Attributes**

- `rootPath` – (Required) The root path where modules are located and routed.
- `autoDiscovery` – Option for probing the module folder and loading module assemblies automatically on start-up. The default is `Minimal`. If you change this to `Modules`, folders are automatically added as modules below the root path.

### Module (add element)

The `publicModules` and `protectedModules` elements in `web.config`contains a collection of registered modules. These modules define assemblies and virtual paths. By default, a module resides in a folder whose name matches the module. This folder should be located in the configured `rootPath` (as configured per public and protected modules).

**Attributes**

- `name` – (Required) The name of the module used to find the module directory.
- `resourcePath` – (Optional) The path of the module overrides the default location of the module.
- `clientResourcePath` – (Optional) An alternative location for client resources. By default, this path is the same as `resourcePath`.

**Elements**

- `assemblies` – Assemblies to load and associate with the module. Combine this value with assemblies defined by the module, depending on the auto-discovery option.

Example (`web.config`):

```xml
<add name="ShellExtras" 
         resourcePath="~/Somewhere/Else/Extras"&#160;clientResourcePath="~/Somewhere/Else/Entirely/Extras">
	<assemblies>
		<add assembly=" EPiServer.Shell.Extras" />
	</assemblies>
</add>
```

## Module manifest

Use the module manifest (`module.config`) to define module-specific settings such as assemblies, descriptions, and tags.

Each module has a manifest file (`module.config`) in its root directory for additional module-specific settings.