anchor.diff:  db-url-host=mykeycloakdb
   ```
   
  -The configuration source and the corresponding format you should use is use-case specific. That decision depends on the platform the server is deployed to
  -as well as on the optimizations you can get for an optimal runtime. For instance, when deploying the server into Kubernetes you would probably rely
  -on environment variables to configure the server. However, you are not limited to use a single configuration source and format.
  +The configuration source and the corresponding format you should use is use-case specific. That decision depends on the platform where the server is deployed and the runtime optimizations you are seeking. For instance, if you deploy the server into Kubernetes, you would probably rely
  +on environment variables to configure the server. However, you are not limited to a single configuration source or format.
   
  -== Configuring the server
  +== Configuration commands and stages
   
  -The server options are narrowed to a specific command or configuration stage. This clear separation is one of the key aspects
  -of the server configuration and is related to a series of optimizations that are done in order to deliver the best runtime when starting and running the server.
  +The server options are narrowed to a specific command or configuration stage. The goal is to perform a series of optimizations in a specific order to achieve optimal startup and runtime performance. This configuration occurs in two stages:
   
  -Configuration is basically done in two stages:
  +First stage:: Configuration performed before starting the server in order to build an optimized server image for use at runtime
  +Second stage:: Configuration performed as part of starting the server
   
  -* Before starting the server in order to build an optimized server image for an optimal runtime
  -* When starting the server
  +=== First stage: Build an optimized Keycloak image
   
  -The first stage involves running the `build` command and set any **build option** available from this command to configure the server.
  +The first stage involves running the `build` command and setting any **build option** available from this command to configure the server.
   
  -By looking at the individual configuration options at <@links.server id="all-config"/>, you notice
  -that some options are marked with an icon to indicate they are a build option. In other words, they can only be set and only take effect when running the `build` command.
  -You can also check all the options that require a build by looking at the `help` message of the `build` command:
  +The configuration options at <@links.server id="all-config"/> include options that are marked with a tool icon. This icon indicates they are build options. Build options take effect only when you apply them to the `build` command.
  +
  +You can also check which options require a build by looking at the `help` message of the `build` command:
   
   <@kc.build parameters="--help"/>
   
  -The `build` command is responsible for producing an immutable and optimized server image, which is similar to building a container image. In addition to persisting
  -any build option you have set, this command also performs a series of optimizations to deliver the best runtime when starting and running the server. As a result,
  -a lot of processing that would usually happen when starting and running the server is no longer necessary and the server can start and run faster.
  +The `build` command can produce an immutable and optimized server image, which is similar to building a container image. In addition to persisting build options, this command also performs optimizations for the best startup and runtime performance. The result is that much processing for starting and running the server is performed before starting Keycloak, so Keycloak is able to start up and run faster later on.
   
  -Some optimizations performed by the `build` command are:
  +The following are some optimizations performed by the `build` command:
   
  -* Closed-world assumption about installed providers, which means that no need to re-create the registry every time the server starts
  -* Configuration files are pre-parsed to reduce IO when starting the server
  -* Database specific resources are configured and prepared to run against a specific database vendor
  +* Closed-world assumption about installed providers, which means that no need exists to re-create the registry at every startup
  +* Configuration files are pre-parsed to reduce I/O when starting the server
  +* Database specific resources are configured and prepared to run against a certain database vendor
   * By persisting build options into the server image, the server does not perform any additional step to interpret configuration options and (re)configure itself
   
  -Once you run the `build` command, you won't need to set the same **build options** again when starting the server.
  -
  -.First stage, run the `build` command to set any build option
  +.Run the `build` command to set the database to PostgreSQL before startup:
   <@kc.build parameters="--db=postgres"/>
   
  -The second stage involves starting the server using any **configuration option** available from the `start` command.
  +Once you run the `build` command, you do not need to set the same **build options** when you start the server.
   
  -.Second stage, run the `start` command to set any configuration option when starting the server
  +=== Second stage: Starting Keycloak
  +
  +The second stage involves starting the server by using the `start` command and including **configuration options** with the appropriate values.
  +
  +.Run the `start` command to start the server while setting various database options
   <@kc.start parameters="--db-url-host=keycloak-postgres --db-username=keycloak --db-password=change_me --hostname mykeycloak.acme.com"/>
   
  -At this stage, you are free to set any value you want to any of the configuration options.
  +Note that if you invoke commands containing special shell characters such as `;` using the CLI, you need to escape those characters. In that situation, you might choose to use the `keycloak.conf` file to set configuration options instead.
   
  -Be aware that you need to escape characters when invoking commands containing special shell characters such as `;` using the CLI, so you might want to set it in the configuration file instead.
  +== Optimization by using a configuration file
   
  -== Configuring the server for an optimal startup time
  -
  -In addition to the optimizations performed when you run the `build` command, you might want to avoid using CLI options when running the
  -`start` command in favor of using environment variables or configuration options from the `conf/keycloak.conf` file.
  +Most optimizations to startup and memory footprint can be achieved by using the `build` command. Additionally, you can use the `conf/keycloak.conf` file to set configuration options. Using this file avoids some necessary parsing steps when providing configuration options using the CLI or environment variables.
   
   .Set any build option
   <@kc.build parameters="--db=postgres"/>
  
positive.code: .Start the server
  <@kc.start/>
  
  By following that approach, the server is going to skip some steps at startup and start faster.
  
  == Using the `auto-build` option when starting the server
  
  The `auto-build` option allows you to perform the two configuration stages using a single command. Under certain circumstances, you might want to sacrifice the server startup time and update the values of build options when starting the server.
  
  For that, you can start the server as follows:
  
  .Using the `auto-build` option
  <@kc.start parameters="--auto-build --db postgres --db-url-host keycloak-postgres --db-username keycloak --db-password change_me --hostname mykeycloak.acme.com"/>
  
  By using this option, the server is going to calculate the build options that have changed and automatically runs the `build` command, if necessary, before starting the server.
  
  == Configuring the server using configuration files
  
  By default, the server is going to always fetch any configuration option you set from the `conf/keycloak.conf` file. When you are using a fresh distribution,
  this file holds only the recommended settings for running in production, which are initially commented out.
  
  You can also specify a different configuration file by using the `[-cf|--config-file] option as follows:
  
  .Running the `build` command using a custom configuration file
  <@kc.build rootParameters="-cf myconfig.conf"/>
  
negative.code: title="Configuring Keycloak"
  summary="An overview of the server configuration">
  
  This guide describes underlying core concepts of Keycloak configuration. It includes configuration guidelines for optimizing Keycloak for faster startup and low memory footprint.
  
  == Server options
  
  You can view the server options by adding the `help` option for individual commands:
  
  .Listing build options
  <@kc.build parameters="--help"/>
  
  .Listing configuration options
  <@kc.start parameters="--help"/>
  
  Alternatively, you can see the server options at <@links.server id="all-config"/>.
  
  Server options are loaded from different sources in a specific order and they use different formats. If an option is defined in different sources, the order of resolution is the order in the following table:
  
  |===
  |*Source* | *Format*
  