New deployment system for Linux and Azure
When BTCPay Server has been created, we understood that one of the reason why centralized services are attractive is the ease of use.
If you are a merchant, your goal should be to concentrate on increasing your sales, not messing up with google trying to figure out why the server is not working, or why you can’t install.
A big factor of adoption of BTCPay has been until now the “Deploy to Azure” button.
A simple button which would bootstrap a simple to use wizard to configure your server
Explained in an easy to follow video:
By following this, you have a fully functional HTTPS enabled BTCPayServer on a server that you control. No tech skill required (hardest thing is configuring the DNS).
Inside this server, you would have a tool called btcpay-update.sh which allow you to freshly backed improvement of BTCPay.
This ease of use is a big reason we can quickly iterate and incorporate feedback. Merchants update because they are excited to see the features they asked quickly developed, and easy to deploy on their servers.
What is the problem with Azure?
Azure is a wonderful solution, we advise you to continue to use it if you don’t have technical skills.
The downside of it: The basic server (BTC+LTC+Lightning) cost around 60 USD per month. This might still be a drop in the bucket compared to the fee other payment processors would take from you.
You can optimize it once synched by following this guide to 25 USD per month, it might work for you… or not. It depends on the load of your server, and you can only know by trial and error.
You may want to host BTCPayServer on your own on-premise infrastructure, or on more cost effective solutions. (like Markus)
So basically, with Azure we are trading simplicity against flexibility and server cost. But what if you have enough technical skill and want more flexibility?
So how to host on your own server without Azure?
Counter-intuitively before today’s release, you would also need to go on btcpayserver-azure and run entrypoint.sh .
This was not easily discoverable by users, so most of people started just running the docker-compose from btcpayserver-docker repository.
This was working great, except you did not had access to tools like changedomain.sh or btcpay-update.sh . Also you needed to install docker and docker-compose by yourself, as well as schedule both of them for reboot.
So how did we solved the problem?
We created a script called btcpay-setup.sh in btcpayserver-docker , and migrated the tools from btcpayserver-azure to btcpayserver-docker.
We also extensively documented how to use it and what it does in the readme.
Adding more flexibility to your deployment
Before, we were pre-generating and committing to the repo all the docker-compose of supported configurations of BTCPay.
However, given the multiplication of altcoin and lightning network implementation supports (coming soon), pre-generating all those docker-compose files would have soon become a problem.
For this reason we only pre generate docker-compose for btc, ltc, clightning combinaison of configuration.
The new deployment system will not use those, but instead generate the docker-compose when running btcpay-setup.sh based on your environment variables documented here. So if you have a server powerful enough to support many altcoins, you can easily generate a docker-compose for your need.
On top of this, if you change your mind and decide to change your configuration, you can just change your environment variables and run. btcpay-setup.sh -i.
Old deployment migration
This update concerns only those who have Azure deployment or ran ./entrypoint.sh on their own server to setup their BTCPay instance (instead relying directly on the docker-compose).
Good care have been taken to not break existing deployments, but still we advise you to migrate. It is luckily quite easy. (See documentation)
If any problem, come to the slack.
