Cloud
Production architecture and infrastructure
Introduction
Our production infrastructure runs on AWS (Amazon Web Services) and comprises of three main components: the web server hosted on EC2 (Elastic Compute Cloud), the MySQL database hosted on RDS (Relational Database Service), and blob storage hosted on S3 (Simple Storage Service).

When a web request from the Internet is directed to our domain, the following happens:
The request for edroplets.org (or www.edroplets.org) undergoes DNS lookup to retrieve the corresponding records. The DNS service we use is GoDaddy. You can check for DNS issues locally using
nslookupor trying an online service like https://www.nslookup.io.

If there is no issue with DNS, the domain name is translated to our public elastic IP address 54.241.15.160 and then the request reaches our EC2 web server.

Web Server (EC2)
The web server is hosted on an EC2 (Elastic Cloud Compute) virtual machine. It handles serving both the frontends and backend of the eDroplets platform as well as running the Caddy web server that reverse proxies requests.
The Caddy server serves two main purposes
It automatically generates and renews SSL certificates through LetsEncrypt for our domain ensuring that we can use HTTPS. If you encounter issues with HTTPS and visiting our domain redirects you to an HTTP "unsafe" page, there is likely some issue with the Caddy server.
It reverse proxies requests to either the static HTML files for the website or the backend API as needed (i.e. requests to
/apiare sent to backend and all others are sent to static files)
@try_files {
not path /api/* # Redirect all paths not /api to the corresponding file
file {
try_files {path} {path}/ /index.html
}
}
rewrite @try_files {http.matchers.file.relative}
handle_path /api/* { # Redirect API requests to docker container running backend
reverse_proxy edroplets_backend:3000
}Any requests to the backend are handled appropriately by the respective controller. The main differences in production compared to development are:
MySQL in a Docker container is replaced by AWS RDS. So we read/write from a database on AWS instead of on the machine in a Docker container.
Ngrok is no longer needed to tunnel webhook requests (which we need since localhost is not exposed to the Internet). Since our machine has a public-facing IP address, webhook requests can be sent directly to our backend.
Last updated