Storage modes of configurations
Sitefinity has the following modes for storing configuration files:
Auto-storage mode
Environment configurations are stored on the file system and application settings in the database. This means that the configuration value persistence depends on what API is used.
- The default persistence API stores the config values in the database.
- Advanced/Basic settings UI use API that explicitly stores the values in the filesystem (assuming that what is updated from advanced setting is always a configuration), except if the updated config element already lives in the database.
Environment configurations can be made read-only on the Live environment.
Advantages:
- This storage mode allowed for safe runtime modification of application settings when load-balanced.
- This storage mode allows you to apply configuration transformations during delivery easily.
When read-only mode of configurations is turned on on the Live environment, configurations remain the same on all instances of the load-balancing. It also prevents changes to environment configurations to be made runtime.
Limitations: Synchronization of labels and messages between the nodes of a load-balanced environment has to be done manually.
For more information, see NLB: Synchronize labels and messages between the nodes from a load balanced setup.
NOTE: By default, Sitefinity CMS uses Auto-storage mode for its configurations. This is the recommended configuration storage option. FileSystem and Database storage modes are legacy options and are available for backward compatibility.
FileSystem
Configurations are stored on the file system
Advantages: This storage method allows you to apply configuration transformations during delivery easily.
Limitations:
- Subsequent deployment overwrites environment configurations and application settings made runtime.
Configuration files contain not only environment configurations, but also application settings that needed to be modified runtime. Therefore, there is no way to push environment configuration changes with the source code, without overwriting the change to application settings made runtime. You have to manually apply these changes on the Live database.
- Prevents Sitefinity CMS to run in a load-balanced scenario
Each instance from the load-balancing has its own configuration files and with time configurations between different nodes become inconsistent.
FileSystem (shared location)
Configurations are stored on the FileSystem, but on shared location.
Advantages:
- This storage method allows you to apply configuration transformations during delivery easily.
- It also allows Sitefinity CMS to safely modify configurations and settings during runtime when load-balanced, because all nodes can share the configurations.
Limitations:
- Subsequent deployment overwrites environment configurations and application settings made runtime.
- Creates availability issues during deployment to Live and creates concurrency issues.
Database
Configurations are stored in the Database
Advantages: This storage mode allowed for safe runtime modification of application settings when load-balanced.
Limitations: If different environments are required, different configuration values are harder to maintain if needed.
Priorities in applying configurations
When applying configurations, Sitefinity CMS has the following hierarchy:
- Environment variables have the highest priority. These are variables managed by the environment and can be stored in the web.config file.
- Configurations persisted in the database in
sf_xml_config_items
database table.
- FileSystem configurations stored in .../App_Data/Sitefinity/Configuration.
- Default configuration values declared in the code.