1. Home
  2. Docs
  3. Chainlink Node Setup
  4. Chainlink Node Security
  5. Failover Node Setup Example

Failover Node Setup Example

Failover Node Example

You may want to run multiple instances of the Chainlink node on the same machine so that if one instance goes down, the secondary instance can automatically pick up requests. Building off the concepts in the previous example, we’ll use Docker to have primary and secondary containers referencing the same database file.

To begin, edit your environment variable file to set DATABASE_TIMEOUT to 0:


This ensures that any secondary container will wait indefinitely for a lock on the database file.

Now, run the Chainlink node with a name option specified:

$ cd ~/.chainlink && docker run --name chainlink -p 6688:6688 -v ~/.chainlink:/chainlink -it --env-file=.env smartcontract/chainlink local n

You will now notice that you no longer receive a randomly generated name from Docker:

docker ps

Output (truncated):


… chainlink

This will remain your primary Chainlink container, and should always use port 6688 (unless configured otherwise). For the secondary instance, you will run the container in the same way, but with a different name and a different local port:

$ cd ~/.chainlink && docker run --name secondary -p 6687:6688 -v ~/.chainlink:/chainlink -it --env-file=.env smartcontract/chainlink local n

Notice the –name secondary was used for this container and the local port is 6687. Be sure to add this port to your SSH tunnel as well so that you can access the secondary node’s GUI if it has become active (it will not function until the primary container goes down).

Running docker ps now reveals two named containers running (output truncated):

docker ps


… secondary

… chainlink

If your primary container goes down, the secondary one will automatically take over. To start the primary container again, simply run:

$ docker start -i chainlink

This will start the container, but the secondary node still has a lock on the database. To give the primary container access, you can restart the secondary container:

$ docker restart secondary -t 0

You’ll notice the primary container takes control of the database file and resumes operation. You can attach to the secondary container by running:

$ docker attach secondary

However, it will not produce any output while waiting for a lock on the database.

Congratulations! You now have a redundant setup of Chainlink nodes in case your primary container goes down. Get comfortable with the process by passing control of the database file back and forth between the chainlink and secondary containers. 


Was this article helpful to you? Yes No

How can we help?