diff --git a/settings.conf b/settings.conf
index ea51b0697..641859424 100644
--- a/settings.conf
+++ b/settings.conf
@@ -7,79 +7,115 @@
 # directory or the keyword "local".
 # "local" means LIBDIR/calamares/modules with settings in SHARE/calamares/modules or
 # /etc/calamares/modules.
+# YAML: list of strings.
 modules-search: [ local ]
 
-# We define the module names in the order they should show up (QtWidget view modules,
-# with one or more pages) OR be executed if enqueued (all other modules).
-# Pages can also enqueue jobs for delayed execution in the order specified for the
-# install phase, so a viewmodule name can appear in more than one phase.
-
-# Phase 1 - prepare.
-# View modules are shown as UI pages, jobs from job modules are executed immediately in
-# the background.
-# Jobs should be executed sparingly (if at all) in this phase.
-prepare:
-- welcome
-- license
-- locale
-- keyboard
-- partition
-- users
-- webview
-- summary
-
-# Phase 2 - install.
-# View modules are not shown. Only the view modules shown in the previous phase are
-# allowed, their names should be added here as placeholders to specify the order in
-# which view module jobs should be enqueued. Job modules are also allowed.
-install:
-#- dummyprocess
-#- dummypython
-- partition
-- mount
-- unpackfs
-- machineid
-- fstab
-- locale
-- keyboard
-- localecfg
-- initcpiocfg
-- initcpio
-- users
-- displaymanager
-- networkcfg
-- hwclock
-- services
-#- dracut
-#- initramfs
-- grubcfg
-- bootloader
-- umount
-
-# Phase 3 - postinstall.
-# View modules are shown as UI pages, jobs from job modules are executed immediately in
-# the background.
-# Jobs should be executed sparingly (if at all) in this phase.
-postinstall:
-- finished
+# Instances section. This section is optional, and it defines custom instances for
+# modules of any kind. An instance entry has an instance name, a module name, and
+# a configuration file name.
+# The primary goal of this mechanism is to allow loading multiple instances of the
+# same module, with different configuration. If you don't need this, the instances
+# section can safely be left empty.
+# Module name plus instance name makes an instance key, e.g. "webview@owncloud",
+# where "webview" is the module name (for the webview viewmodule) and "owncloud"
+# is the instance name, which loads a configuration file named "owncloud.conf" from
+# any of the configuration file paths, including the webview module directory.
+# This instance key can then be referenced in the sequence section.
+# For all modules without a custom instance specification, a default instance is
+# generated automatically by Calamares. Therefore a statement such as "webview" in
+# the sequence section automatically implies an instance key of "webview@webview"
+# even without explicitly defining this instance, and the configuration file for
+# this default instance "<modulename>@<modulename>" is always assumed to be
+# "<modulename>.conf".
+# For more information on running module instances, run Calamares in debug mode
+# and check the Modules page in the Debug information interface.
+# YAML: list of maps of string:string key-value pairs.
+instances:
+- id:       owncloud
+  module:   webview
+  config:   owncloud.conf
 
+# Sequence section. This section describes the sequence of modules, both
+# viewmodules and jobmodules, as they should appear and/or run.
+# A jobmodule instance key (or name) can only appear in an exec phase, whereas
+# a viewmodule instance key (or name) can appear in both exec and show phases.
+# There is no limit to the number of show or exec phases. However, the same module
+# instance key should not appear more than once per phase, and deployers should
+# take notice that the global storage structure is persistent throughout the
+# application lifetime, possibly influencing behavior across phases.
+# A show phase defines a sequence of viewmodules (and therefore pages). These
+# viewmodules can offer up jobs for the execution queue.
+# An exec phase displays a progress page (with brandable slideshow). This progress
+# page iterates over the modules listed in the *immediately preceding* show phase,
+# and enqueues their jobs, as well as any other jobs from jobmodules, in the order
+# defined in the current exec phase.
+# It then executes the job queue and clears it. If a viewmodule offers up a job
+# for execution, but the module name (or instance key) isn't listed in the
+# immediately following exec phase, this job will not be executed.
+# WARNING: when upgrading from Calamares 1.1, this section requires manual
+# intervention. There are no fixed prepare/install/postinstall phases any more,
+# and all limitations on the number of phases, number of pages, and number of
+# instances are lifted.
+# YAML: list of lists of strings.
+sequence:
+- show:
+  - welcome
+  - locale
+  - keyboard
+  - partition
+  - users
+  - summary
+- exec:
+#  - dummyprocess
+#  - dummypython
+  - partition
+  - mount
+  - unpackfs
+  - machineid
+  - fstab
+  - locale
+  - keyboard
+  - localecfg
+  - initcpiocfg
+  - initcpio
+  - users
+  - displaymanager
+  - networkcfg
+  - hwclock
+  - services
+#  - dracut
+  - initramfs
+#  - grubcfg
+  - bootloader
+  - umount
+- show:
+  - webview@owncloud
+  - finished
 
 # A branding component is a directory, either in SHARE/calamares/branding or in
 # /etc/calamares/branding (the latter takes precedence). The directory must contain a
-# YAML file branding.desc which may reference additional resources (such as images or QML)
-# as paths relative to the current directory.
+# YAML file branding.desc which may reference additional resources (such as images) as
+# paths relative to the current directory.
+# A branding component can also ship a QML slideshow for execution pages, along with
+# translation files.
 # Only the name of the branding component (directory) should be specified here, Calamares
 # then takes care of finding it and loading the contents.
-branding: default
+# YAML: string.
+branding: netrunner-rolling
 
-# If this is set to true, Calamares will show an "are you sure?" prompt right before the
-# install phase, i.e. at the point of no return. If it's false, no prompt is shown.
+# If this is set to true, Calamares will show an "Are you sure?" prompt right before
+# each execution phase, i.e. at points of no return. If this is set to false, no prompt
+# is shown.
 # Default is false.
+# YAML: boolean.
 prompt-install: false
 
-# If this is set to true, all target environment calls will be executed on the current
-# (host) system rather than on the target (chrooted) system.
-# Only set this to true in exceptional circumstances, if you are not using Calamares as
-# a system installer.
+# If this is set to true, Calamares will execute all target environment commands in the
+# current environment, without chroot. This setting is considered experimental, and it
+# should only be used when setting up Calamares as a post-install configuration tool, as
+# opposed to a full operating system installer.
+# Some official Calamares modules are not expected to function with this setting.
+# Packagers beware, here be dragons.
 # Default is false.
+# YAML: boolean.
 dont-chroot: false