Hey everyone!
The Infrastructure and Allies folks on the Product Team have been busy updating the CHT documentation site. Most importantly, there’s now guides on
If you love reading, please click through the above links! However, if you’re more of a video person, here is a ~6 min walk through of the new docs changes and real time install of a production instance:
As a follow up to this post, we’ve just added a feature where it’s trivial to have a deep integration with Certbot to provision a free TLS certificate, like those that Let’s Encrypt offers.
The TLS documentation page has more details!
hello @mrjones @binod @jkuester
I have a 3.x instance that i have been using for testing and would like to keep using that.
However i would like to set up another similar instance(with the same configuration code and forms) to be used in pilot deployment, is it okay to use 4.x if i want to?.. are there any pros?.. or should i sticky to 3.x?
CHT 4.x has massive benefits over 3.x in terms of performance, functionality, security, and user interface! Our recommendation is that all 3.x instances be migrated to CHT 4.x and all new CHT instances being deployed should be 4.x. See the preparing for 4.x and migration guides for more information on how to upgrade an instance from 3.x to 4.x and the self-hosting docs for information on deploying a new 4.x instance.
Regarding using the same configuration for both 3.x and 4.x instances, in general you should be able to do this without any problems. There are some edge-case changes around form logic behavior that may require updates to some of your current forms for them to work on 4.x, but these required updates are backwards compatible to 3.x. The main drawback with using the same config on both a 3.x instance and a 4.x instance is that you will not be able to take advantage of new 4.x features.
thanks @jkuester for the detailed feedback …
So this means i have to develop new config from scratch suitable for 4.x ?
No, actually the opposite! 
All of your 3.x config should work fine on 4.x (excepting the previously mentioned form config edge cases). However, if you want to start taking advantage of new 4.x features in your config (e.g. using the new date comparison xpath functions in your form logic) the updated config will no longer be compatible with 3.x. There should not ever be any need to develop new config “from scratch”.
well said 
Thanks @jkuester
@jkuester have set 4.x what are the default credentials? username:medic password:password are not working
Check the COUCHDB_PASSWORD in your .env file. That should be set to a randomized value.
grep COUCHDB_PASSWORD /home/ubuntu/cht/upgrade-service/.env | cut -d'=' -f2
thanks @jkuester got it,
@jkuester Is it possible to load the config before loading the TLS ?
tried it here
> WARN No project package.json file found at /Users/cliff/Documents/projects/config-itech-1/package.json WARN Project has no dependency on cht-conf. INFO Checking that [http://medic](http://medic/):****@<ip-address>/medic/ is available... INFO Error: Failed to get a response from [http://medic](http://medic/):****@<ip-address>/medic/. Maybe you entered the wrong URL, wrong port or the instance is not started. Please check and try again. at Object.available (/usr/local/lib/node_modules/cht-conf/src/lib/api.js:113:13) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async module.exports (/usr/local/lib/node_modules/cht-conf/src/lib/main.js:212:5) at async /usr/local/lib/node_modules/cht-conf/src/bin/index.js:16:5 ERROR Failed to get a response from [http://medic](http://medic/):****@<ip-address>/medic/. Maybe you entered the wrong URL, wrong port or the instance is not started. Please check and try again.
You should be able to run the cht commands against a server before deploying your own SSL certs with the --accept-self-signed-certs flag.
thanks @jkuester