Originally posted on 2023-01-30 at blog.tlarsendataguy.com, and shared here with permission.
A while back, I created a web server for my web app, timegiver.app. I hosted it on a Windows VM in Azure. The VM is something I occasionally use for analytics. I decided to host my web app there because it is under-utilized most of the time.
It worked so well, I decided to self-host my blog using the same web server code. But I did not want to stand up another VM. After a few changes to the code, my web server could serve multiple hosts from a single VM.
This also worked well. I decided to package it as a generic, easily-customized web server. I ripped out the code for my specific APIs and Echidna was born. Echidna is a web server designed to serve static websites. It includes the following features:
- Automatic TLS and certificate management with Let’s Encrypt. No configuration required!
- Serve multiple hosts from the same VM. Move fast and ideate without incurring additional infrastructure costs.
- Serves static files by default. Extend the code and implement your own APIs. Echidna is not a module and is not opinionated. Make it your own.
- Each site only requires 2 files: index.html for the home page and 404.html for 404 responses. Otherwise, Echidna uses the URL path to serve files from the root host folder. You decide how your site is structured.
- Use git repositories to manage your site without leaking the repositories to the internet. Echidna will not serve files in the host’s root .git folder, nor will it serve .gitignore or .gitattributes.
Now, whenever I want to try a new idea, I add a new host to the configuration file and restart the web server. It’s that easy! If the new idea requires an API, it’s trivial to build it out and hook it into the Echidna code. As of today, I am serving 3 sites with my single instance of Echidna (timegiver.app, blog.tlarsendataguy.com, kneeboard.tlarsendataguy.com).
To wrap up this post, here are the steps I followed to stand up my Echidna web server. They include configuration steps needed in Azure and the VM before Echidna can receive incoming connections.
- Stand up a Windows Server VM with a public IP address
- Open ports 80 and 443 from Azure Portal
- Copy the Echidna executable to a folder on the data disk (e.g. f:/echidna)
- Set up sub-folders for certificates and static web files (e.g. f:/echidna/certs and f:/echidna/serve)
- Allow the Echidna executable through the Windows Firewall on the VM
- Set the Echidna configuration file
- Copy static files into their appropriate directories in the serve folder
- Set up Echidna as a service using Non Sucking Service Manager (NSSM)
- Start the service
- Add the necessary CNAME and/or A records to my domain registrar
Responses