Guide | API Docs | Consulting | Community
OpenDAX is an open-source cloud-native multi-service platform for building a Blockchain/FinTech exchange of digital assets, cryptocurrency and security tokens.
Getting started with OpenDAX
1. Get a VM
Minimum VM requirements for OpenDAX:
- 8GB of RAM (12GB recommended)
- 4 cores vCPU (6 cores recommended)
- 300GB disk space (SSD recommended)
A VM from any cloud provider like DigitalOcean, Vultr, GCP, AWS as well as any dedicated server with Ubuntu, Debian or Centos would work
2. Prepare the VM
2.1 Create Unix user
SSH using root user, then create new user for the application
useradd -g users -s `which bash` -m app
2.2 Install Docker and docker compose
We highly recommend using docker and compose from docker.com install guide instead of the system provided package, which would most likely be deprecated.
2.3 Install ruby in user app
2.3.1 Change user using
su - app
2.3.2 Clone OpenDAX
git clone https://github.com/openware/opendax.git
2.3.3 Install RVM
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB curl -sSL https://get.rvm.io | bash -s stable cd opendax rvm install .
3. Bundle install dependencies
bundle install rake -T # To see if ruby and lib works
rake -T you can see all available commands, and can create new ones in
4. Run everything
4.1 Configure your domain
If using a VM you can point your domain name to the VM ip address before this stage.
Recommended if you enabled SSL, for local development edit the
Insert in file
4.2 Bring everything up
You can login on
www.app.local with the following default users from seeds.yaml
Seeded users: Email: firstname.lastname@example.org, password: 0lDHd9ufs9t@ Email: email@example.com, password: Am8icnzEI3d!
In order to accelerate customer interaction, reduce risks and simplify business processes you can use KYC Verification Service from KYCaid. KYC goal is to prevent fraud and to decline users that don’t fulfill certain standards of credibility. To learn more about KYCaid and pricing you can visit their website - kycaid.com
How to configure KYCAID on the platform?
KYCAID is already integrated into our stack, to use it you'd need to create an account on kycaid.com, and set up authentification creds there and the callback url: https://example.com/api/v2/barong/public/kyc
After that all you have to do is to change several lines in
kyc: provider: kycaid authorization_token: changeme # your production API token from the 'Settings' section of kycaid.com sandbox_mode: true # 'true' for test environments - documents will be verified/rejected automatically, without payment for verification api_endpoint: https://api.kycaid.com/
Additional settings for KYCAID
- Be sure to check
BARONG_REQUIRED_DOCS_EXPIREENV value inside
falseif you want to include
addressverification in your KYC process. You can set it to
trueif you need the document check only.
- Check if you have the correct list of
- Identity card
- Driver license
- Frontend KYC steps can be configured in
- Tower KYC labels can be configured in
Unless the installation wizard was disabled(
config/app.yml), it will be displayed upon the first startup.
There, you can set the initial superadmin email and password, configure the exchange name and URL, and configure upstream markets from OpenDAX Cloud
After the initial configuration, you can manage all the configuration variables at
private scope configurations can be both viewed and updated while
secret ones can only be updated to avoid credentials leakage.
As soon as any component's (barong, peatio, etc.) configuration is changed, it will restart and reload its config within 20 seconds.
You can also alter platform configurations directly from the terminal. To do this:
config/secrets.yamlor create a file with the same structure
- Add or edit new configuration data for component(s) you'd like to update
./tmp/kaisave --filepath *filepath*to load all configurations from a given file
Note: existing configurations would be overwritten by this process so make sure to only load relevant changes without resetting existing data with defaults for other components
All the OpenDAX deployment files have their confguration stored in
The following table lists the configurable parameters of the config/app.yml configuration file and its default values.
||global application name||
||base domain name||
||enable installation wizard||
||enable/disable landing page display for the frontend application||
||enable read-only mode for rendered files||
||enable CSRF protection on Barong||
||enable SSL certificate generation||
||email address used for SSL certificate issuing||
||update all image tags by fetching global ones for OpenDAX||
||Docker image tags per component|
||optional Git URL for a development frontend repo||
||KYC provider, can be
||optional API token for KYCAID use||
||enable KYCAID test mode||
||API endpoint for KYCAID||
||Root Vault authentication token||
||Peatio Server Vault authentication token||
||Peatio Daemons (cron_job, deposit, deposit_coin_address, withdraw_coin) Vault authentication token||
||Peatio Upstream Daemon Vault authentication token||
||Peatio Daemons (matching, order_processor, trade_executor) Vault authentication token||
||Barong Vault authentication token||
||Finex Engine Vault authentication token||
||database adapter kind either
||database host name||
||database root password||
||object storage provider||
||storage bucket name||
||S3-compatible storage API endpoint||
||S3-compatible storage API signature version(2 or 4)||
||storage access keys||
||Twilio SMS provider configs|
||Google Analytics tracker key inserted into the frontend app|
||SMTP configs used for sending platform emails|
||captcha configuration(Recaptcha or Geetest)|
||configs for wallets seeded during the initial deployment of Peatio|
||Parity cryptonode configuration(learn more)|
||Bitcoind cryptonode configuration|
||Litecoind cryptonode configuration|
||Bitcoin electrumd server configuration(learn more)|
||Litecoin electrumd server configuration(learn more)|
||local path to a GCP service account JSON key||
||GCP project name||
The following table lists configurable parameters of the
|images||Docker image tags per component|
|superset||Superset BI tool configs|
|arke||Arke liquidity bot configs|
Once you're done with the configuration, render the files using
rake render:config. You can easily apply your changes at any time by running this command.
Note: be sure to append all the subdomains based on app.domain to your /etc/hosts file if you're running OpenDax locally
Bringing up the stack
The OpenDAX stack can be brought up using two ways:
- Bootstrap all the components at once using
- Start every component one-by-one using
The components included in the stack are:
proxy- Traefik, a robust cloud-native edge router/reverse proxy written in Go
backend- Vault, MySQL, Redis and RabbitMQ grouped together
cryptonodes- cryptocurrency nodes such as parity [Optional]
daemons- Peatio and Ranger daemons [Optional]
setup- setup hooks for Peatio and Barong to run before the application starts (DB migration etc.)
app- Peatio is the crypto exchange software, Barong and the Ambassador API gateway
frontend- the frontend application located at
tower- the Tower admin panel application located at
monitoring- cAdvisor and Node Exporter monitoring tools [Optional]
For example, to start the
backend services, you'll simply need to run
Note: all the components marked as [Optional] need to be installed using rake service:*component*[start] explicitly
Go ahead and try your own OpenDAX exchange deployment!
Stopping and restarting components
Any component from the stack can be easily stopped or restarted using
rake service:*component*[stop] and
rake service:frontend[stop] would stop the frontend application container and
rake service:proxy[restart] would completely restart the reverse proxy container.
Managing component deployments
Each component has a config file (ex.
config/frontend/tower.js) and a compose file (ex.
All config files are mounted into respective component container, except from
config/app.yml - this file contains all the neccessary configuration of opendax deployment
Compose files contain component images, environment configuration etc.
These files get rendered from their respective templates that are located under
How to update component image?
config/app.yml with correct image and run
This will rerender all the files from
templates directory and restart all the running services.
Alternitavely you can update the following files:
How to update component config?
config/*component*/*config* and run
if you want the changes to be persistent, you also need to update
Render compose file
# Delete all generated files git clean -fdx # Re-generate config from config/app.yml values rake render:config # Restart the container you need to reload config docker-compose up frontend -Vd
Clone the vendors and start
source ./bin/set-env.sh rake vendor:clone docker-compose -f compose/vendor.yaml up -d
Opendax uses Vault Policies to restrict components' access to sensitive data. Each component has its own Vault token which allows granular access only to the data required.
OpenDAX has 2 rake tasks for Vault management:
rake vault:setup # Initial Vault configuration (root token generation, unseal, endpoints configuration) rake vault:load_policies # Components' Vault token generation
Vault is sealed
In case of such error:
- Restart the component
Make sure you're not using an existing Docker volume for Vault(i.e. one left after a different Vault container deployment):
docker volumes ps | grep vault
In case there are existing volumes, remove the running Vault container via
docker rm -f *id* and run
docker volume rm -f *volume name*
docker-compose up -Vd vault and re-run
Vault permission denied
Usually, this means that one of your Vault tokens has expired.
To fix the issue:
Restart Vault dependant components:
docker-compose up -Vd barong peatio cron_job deposit deposit_coin_address withdraw_coin upstream # If you are using Finex docker-compose up -Vd finex-engine # If you are using Peatio Matching Engine docker-compose up -Vd matching order_processor trade_executor
Terraform Infrastructure as Code Provisioning
You can easily deploy OpenDAX from scratch on Google Cloud Platform using Terraform!
To do this, just follow these simple steps:
app.ymlwith correct values
- Access your VM from the GCP Cloud Console
To destroy the provisioned infrastructure, just run
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/openware/opendax/master/bin/install)"
Using an OpenDAX deployment for local frontend development
If you'd like to use a real API from an existing OpenDAX deployment when developing frontend components(e.g. baseapp), modify
templates/config/gateway/envoy.yaml.erb file the following way:
Configure all the needed HTTP methods in
allow_methods. For example:
allow_methods: "PUT, GET, POST, DELETE, PATCH"
'total, page, x-csrf-token'to
expose_headersin a similar way
expose_headers: "total, page, x-csrf-token"
allow_credentials: trueto your CORS configuration
After completing these steps, you should have the following config:
cors: allow_origin: - "*" allow_methods: "PUT, GET, POST, DELETE, PATCH" allow_headers: "content-type, x-grpc-web, total, page, x-csrf-token" expose_headers: "total, page, x-csrf-token" allow_credentials: true
Afterwards, apply the config onto your deployment:
rake render:config docker-compose up -Vd gateway
Happy trading with OpenDAX!
If you have any comments, feedback and suggestions, we are happy to hear from you here at GitHub or here: crypto exchange software
2.6 Migration guide
To migrate from 2.5 to 2.6, do the following:
- Pull 2-6-stable branch
While rebasing, rename your
dc up -Vd vault