Skip to main content

Running a Coinweb node


In order to be able to run a Coinweb node the following configuration is required:

  1. A Kubernetes environment (cluster or computer) where you want to run Coinweb.
  2. helm which is a package manager for Kubernetes.
  3. A domain you want the Coinweb APIs to be available at.
  4. Jaeger tracing installed in the Kubernetes environment, which can be installed like this.
helm repo add jaegertracing
helm install jaeger jaegertracing/jaeger -n monitoring --create-namespace

API access to layer 1 (L1) blockchains

Coinweb is a cross-chain computation framework that uses various layer 1 blockchains as input. Running a Coinweb installation requires access to the APIs of the layer 1 blockchains required for the shards you want to run, and by default all shards are run by a Coinweb installation. These APIs are sometimes called "RPC access" or similar and can be bought from various companies as a SaaS service, or you can run your own service. To increase decentralization, we suggest that you run at least some of these L1 blockchains in your own Kubernetes environment.

Access to the Coinweb container images

In the closed beta-net release, you need access to the container registry hosting the Coinweb container images. This access consists of a username and password (a Gitlab deploy token with the read_registry scope). The username is usually of the form: gitlab+deploy-token-1234567

Selecting a storage class

In values/postgres-prod-like.yaml, set the storageClass for the postgres instance. For GCP, standard-rwo can be a good choice.

Configuring the wallet and broadcaster-wallet secrets

The custodial wallet (wallet) and the broadcaster each have wallets with associated secrets. These secrets are specified in the values/common.yaml file. The default secrets must be changed for a production setup.

Installing Coinweb

../scripts/ download_chart
../scripts/ --registry-user myuser \
--registry-password password \
--registry-email [email protected] \
../scripts/ --deploy-mode production \
--hosts \
--no-wait deploy

During startup of a production version, it is natural that some pods are temporarily in a CrashLoopBackOff state as they are waiting for the databases to be available.

Uninstalling Coinweb

$ kubectl delete namespace coinweb

Alternatively the individual helm releases can be deleted without affecting the state of the system which is stored in the persistent value claim (pvc) associated with the Postgresql installation. This pvc is not deleted by default when deleting the corresponding helm release. This is a convenient way of reinstalling without doing unnecessary synchronization work.

$ helm delete coinweb -n coinweb
$ helm delete coinweb-postgresql -n coinweb