1de498340c
* spellcheck config * Merge remote-tracking branch 'origin/unstable' into spellcheck * spellcheck update * update spellcheck * spell check passes * Remove ignored and add other md files * Remove some words in wordlist * CI * test spell check CI * correct spell check * Merge branch 'unstable' into spellcheck * minor fix * Merge branch 'spellcheck' of https://github.com/chong-he/lighthouse into spellcheck * Update book * mdlint * delete previous_epoch_active_gwei * Merge branch 'unstable' into spellcheck * Tweak "container runtime" wording * Try `BeaconState`s
4.0 KiB
📦 Installation
Siren supports any operating system that supports containers and/or NodeJS 18, this includes Linux, macOS, and Windows. The recommended way of running Siren is by launching the docker container , but running the application directly is also possible.
Version Requirement
To ensure proper functionality, the Siren app requires Lighthouse v4.3.0 or higher. You can find these versions on the releases page of the Lighthouse repository.
Running the Docker container (Recommended)
The most convenient way to run Siren is to use the Docker images built and published by Sigma Prime.
They can be found on Docker hub, or pulled directly with docker pull sigp/siren
Configuration is done through environment variables, the easiest way to get started is by copying .env.example to .env and editing the relevant sections (typically, this would at least include adding BEACON_URL, VALIDATOR_URL, API_TOKEN and SESSION_PASSWORD)
Then to run the image:
docker compose up
or
docker run --rm -ti --name siren -p 4443:443 --env-file $PWD/.env sigp/siren
This command will open port 4443, allowing your browser to connect.
To start Siren, visit https://localhost:4443 in your web browser.
Advanced users can mount their own certificates, see the SSL Certificates section below
Building From Source
Docker
The docker image can be built with the following command:
docker build -f Dockerfile -t siren .
Building locally
To build from source, ensure that your system has Node v18.18 and yarn installed.
Build and run the backend
Navigate to the backend directory cd backend. Install all required Node packages by running yarn. Once the installation is complete, compile the backend with yarn build. Deploy the backend in a production environment, yarn start:production. This ensures optimal performance.
Build and run the frontend
After initializing the backend, return to the root directory. Install all frontend dependencies by executing yarn. Build the frontend using yarn build. Start the frontend production server with yarn start.
This will allow you to access siren at http://localhost:3000 by default.
Advanced configuration
About self-signed SSL certificates
By default, Siren will generate and use a self-signed certificate on startup. This will generate a security warning when you try to access the interface. We recommend to only disable SSL if you would access Siren over a local LAN or otherwise highly trusted or encrypted network (i.e. VPN).
Generating persistent SSL certificates and installing them to your system
mkcert is a tool that makes it super easy to generate a self-signed certificate that is trusted by your browser.
To use it for siren, install it following the instructions. Then, run mkdir certs; mkcert -cert-file certs/cert.pem -key-file certs/key.pem 127.0.0.1 localhost (add or replace any IP or hostname that you would use to access it at the end of this command)
The nginx SSL config inside Siren's container expects 3 files: /certs/cert.pem /certs/key.pem /certs/key.pass. If /certs/cert.pem does not exist, it will generate a self-signed certificate as mentioned above. If /certs/cert.pem does exist, it will attempt to use your provided or persisted certificates.
Configuration through environment variables
For those who prefer to use environment variables to configure Siren instead of using an .env file, this is fully supported. In some cases this may even be preferred.
Docker installed through snap
If you installed Docker through a snap (i.e. on Ubuntu), Docker will have trouble accessing the .env file. In this case it is highly recommended to pass the config to the container with environment variables.
Note that the defaults in .env.example will be used as fallback, if no other value is provided.