Decentralized communications that work with or without the Internet
- A pre-existing docker swarm already setup and configured is necessary for orchestration of this software service stack.
- A domain to use for production.
- A directory named
/var/www/dcomms
created on the hosts of all docker nodes for the website document root. - A subdomain with the A record pointed to the IP address of a node for automatic issuance of a Let's Encrypt SSL certificate.
- A subdomain with the MX record pointed to the A record of a node for DeltaChat mail delivery.
dcomms
is a bundle of decentralized communication software running as services in the form of a docker swarm stack.
It is used to rapidly deploy and orchestrate decentralized, federated, communications platforms such as Matrix and DeltaChat across multiple hosts.
Let's Encrypt TLS certificates are automatically issued and managed by the Caddy container across all services.
The dcomms stack leverages single node, non-replicated containers of the following services built from the latest images below:
- CENO client courtesy of censorship.no
- Synapse Docker courtesy of matrix.org
- Element courtesy of vector-im
- Caddy courtesy of the Caddy Docker Maintainers
- docker-mailadm, includes dovecot and postfix, courtesy of DeltaChat
CENO client: 28729/udp
Caddy (webserver): 443/tcp, 80/tcp, 8448/tcp
DeltaChat (postfix/dovecot): 587/tcp 143/tcp
- Note:
dcomms
leverages docker host networking and therefore we recommend denying access to all other unnecessary ports at the host level.
Point the following A records to the docker worker you wish to use for deployment:
matrix.server1.example.org -> IP of worker node
chat.server1.example.org -> IP of worker node
server1.example.org -> IP of worker node
Point the following MX record to the A record:
server1.example.org -> server1.example.org
Clone or download this repository. Review ./docker-compose.yml
and make any changes that may be required for your production environment.
Use labels to specify which docker nodes services should run on
- Obtain the node ID of a worker. From the manager node of the swarm type:
docker node ls
- Add the
node.labels.dwebstackrole
label to that node:
docker node update --label-add=dwebstackrole=bridge <nodeid>
- Add the
node.labels.dwebstackdomain
label that matches the subdomain you wish to provision to the node:
docker node update --label-add=dwebstackdomain=server1.example.org <nodeid>
Provision a dcomms server as server1.example.org
. From the manager node type:
DWEB_DOMAIN=server1.example.org ./provision.sh
- Note: This is an invasive action. Kindly take caution not to provision a node with the same
DWEB_DOMAIN
multiple times to prevent Synapse from overwriting data.
In the future, to redeploy or restart all dcomms services on server1.example.org
, from the manager node type:
DWEB_DOMAIN=server1.example.org ./redeploy.sh
- Copy a pre-existing website into
/var/www/dcomms/
across all docker nodes or checkout all files from./site
into the same location. - Optionally visit
https://server1.example.org
to view the website. - Optionally visit
https://chat.server1.example.org
to view the Element service. - Optionally configure a Matrix client to use
https://matrix.server1.example.org
as the homeserver.
You may desire to tag the images within docker-compose.yml
instead of relying upon the latest images for a more consistent deployment experience in production.
To review logs, from the manager node of the swarm, type:
docker service logs dwebstack-server1_example_org_bridge -ft
docker service logs dwebstack-server1_example_org_caddy -ft
docker service logs dwebstack-server1_example_org_dovecot -ft
docker service logs dwebstack-server1_example_org_element -ft
docker service logs dwebstack-server1_example_org_mailadm -ft
docker service logs dwebstack-server1_example_org_postfix -ft
docker service logs dwebstack-server1_example_org_synapse -ft