At this point, your GitLab instance should be up and running. Verify you are
able to login, and create issues and merge requests. If you have troubles check the [Troubleshooting section](#troubleshooting).
### Example configuration
Here we'll show you some fully expanded example configurations.
#### Example recommended setup
This example uses 3 consul servers, 3 postgresql servers, and 1 application node.
We start with all servers on the same 10.6.0.0/16 private network range, they
can connect to each freely other on those addresses.
Here is a list and description of each machine and the assigned IP:
*`10.6.0.11`: Consul 1
*`10.6.0.12`: Consul 2
*`10.6.0.13`: Consul 3
*`10.6.0.21`: PostgreSQL master
*`10.6.0.22`: PostgreSQL secondary
*`10.6.0.23`: PostgreSQL secondary
*`10.6.0.31`: GitLab application
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
The external_url for GitLab is `http://gitlab.example.com`
Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
##### Example recommended setup for Consul servers
On each server edit `/etc/gitlab/gitlab.rb`:
```ruby
# Disable all components except Consul
bootstrap['enable']=false
gitlab_rails['auto_migrate']=false
gitaly['enable']=false
gitlab_workhorse['enable']=false
mailroom['enable']=false
nginx['enable']=false
postgresql['enable']=false
redis['enable']=false
sidekiq['enable']=false
prometheus['enable']=false
unicorn['enable']=false
consul['enable']=true
consul['configuration']={
server: true,
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
```
[Reconfigure Omnibus GitLab][reconfigure Gitlab] for the changes to take effect.
##### Example recommended setup for PostgreSQL servers
On each server edit `/etc/gitlab/gitlab.rb`:
```ruby
# Disable all components except PostgreSQL and Repmgr and Consul
This example uses 3 postgresql servers, and 1 application node.
It differs from the [recommended setup](#example_recommended_setup) by moving the consul servers into the same servers we use for PostgreSQL.
The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with postgres [failover](#failover_procedure) and [restore](#restore_procedure) procedures in addition to [consul outage recovery](consul.md#outage_recovery) on the same set of machines.
In this example we start with all servers on the same 10.6.0.0/16 private network range, they can connect to each freely other on those addresses.
Here is a list and description of each machine and the assigned IP:
*`10.6.0.21`: PostgreSQL master
*`10.6.0.22`: PostgreSQL secondary
*`10.6.0.23`: PostgreSQL secondary
*`10.6.0.31`: GitLab application
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
The external_url for GitLab is `http://gitlab.example.com`
Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
##### Example minimal configuration for database servers
On each server edit `/etc/gitlab/gitlab.rb`:
```ruby
# Disable all components except PostgreSQL, Repmgr, and Consul