Deployment Protocol


$ cd wallet-webex

# check dependencies
$ ./configure

# edit version and version_name
$ $EDITOR manifest.json

$ make package-stable

The built wallet is now ready in taler-wallet-stable-${version_name}${version}.zip.

FIXME: here, we should do some semi-automated testing with selenium, to see that everything works against

The package can now be uploaded to

FIXME: include asset links and descriptions we use in the webstore in this document

FIXME: include instructions for other app stores

Deploying to stable

First, make sure that the deployment AND the deployment scripts work on the deployment.

For all repositories that have a separate stable branch (currently exchange.git, merchant.git, merchant-frontends.git, bank.git, landing.git) do:

$ cd $REPO
$ git pull origin master stable
$ git checkout stable

# option a: resolve conflicts resulting from hotfixes
$ git merge master
$ ...

# option b: force stable to master
$ git update-ref refs/heads/stable master

$ git push # possibly with --force

# continue development
$ git checkout master

Log into with the account that is not active by looking at the sockets symlink of the demo account.

The following instructions wipe out the old deployment completely.

$ ls -l ~demo/sockets

[...] sockets -> /home/demo-green/sockets/

In this case, demo-green is the active deployment, and demo-blue should be updated. After the update is over, the /home/demo/sockets symlink will be pointed to demo-blue.

# Remove all existing files
$ find $HOME -exec rm -fr {} \;

$ git clone /var/git/deployment.git
$ ./deployment/bootstrap-bluegreen demo

# set environment appropriately
$ . activate
$ taler-deployment-build

# upgrade the database!  this
# process depends on the specific version

$ taler-deployment-start

# look at the logs, verify that everything is okay

Now the symlink can be updated.

Database upgrades

The exchange db can be re-initialized with

$ taler-exchange-dbinit -r


Standalone deployment

This tecnique aims to set a thorough Taler installation up on a machine whose nginx configuration is configured by config files from

This installation assumes that all the steps are run with $HOME as $CWD.

The first step is to fetch the deployment repository, which hosts all the needed scripts.

# Adapt the repository's URI to your needs.
$ git clone /var/git/deployment.git/

The next step is to fetch all the codebases from all the components.

$ ./deployment/bootstrap-standalone

If the previous step succeeded, a file named activate should be now in the $CWD. It contains environmental definitions for $PATH and database names.


Please ignore the output from the previous script when it succeeds, which is

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

/usr/lib/postgresql/9.5/bin/pg_ctl -D talerdb -l logfile start

The reason is that this message is generated by Postgresql’s utilities and you never need to start your database manually; it will be started by the init script that launches all the Taler processes.

Now we need to compile and install all the downloaded codebases.

# We first update ``$PATH``, in order to make all the compilation
  and configuration utilities available.
$ source activate

# Double check if the previous step worked: $PATH should
# contain $HOME/local/bin.
$ echo $PATH

# The actual compilation:
$ taler-deployment-build

The following step will generate config files for all the components. Please note that although a default currency will be picked up by the script, it is possible to have a custom currency by setting the environment variable TALER_CONFIG_CURRENCY to the wanted currency, and then runing the config generator.

$ taler-deployment-config-generate

whereas the following one will place signatures inside wireformat JSON files.

$ taler-deployment-config-sign

The next step is to generate signkeys and denomkeys.

$ taler-deployment-keyup

It may be necessary to define database tables for the exchange. The following command does that.

# Erase all the data!
$ taler-exchange-dbinit -r

As of the merchant backend, it creates tables at launch time, so it is not required to define tables before launching it. However, if some table’s definition changed over the time, and there is a need to force a redefinition of tables, then the following command accomplishes that for the merchant:

# Erase all the data!
$ taler-merchant-dbinit -r

If all previous steps succeeded, it is now possible to launch all the processes. That is accomplished by the following command:

$ taler-deployment-start


Please make sure your nginx works correctly with its configuration at <DEPLOYMENT-REPO>/etc/nginx.