Automating Route 53, Nginx, and Let’s Encrypt for New Services

Deploying a small application is easy. Repeating the same DNS, proxy, and TLS steps for every new application is where mistakes start to appear.

I built a Bash-first workflow around AWS Route 53, Nginx, SSH, and Certbot so a new service can move from a local container port to a public HTTPS subdomain with minimal manual configuration.

The target workflow

The input is intentionally small:

subdomain=audit
port=8015

The automation handles the rest:

Route 53 A record
        |
        v
audit.richmackos.com
        |
        v
Nginx reverse proxy
        |
        v
127.0.0.1:8015
        |
        v
Let's Encrypt TLS

Route 53 from the Mac

The local side uses the AWS CLI with environment variables rather than embedding account values into scripts.

That gives the workflow two useful properties: credentials stay outside source control, and the same script can be reused for additional services.

A Route 53 UPSERT creates or updates the A record, then the script waits for the AWS change to reach INSYNC before continuing.

Reverse proxy automation on the server

The server-side helper takes the subdomain and application port as flags.

Its responsibilities are:

1. create the Nginx server block
2. proxy the hostname to the local application port
3. validate Nginx configuration
4. reload Nginx
5. wait for DNS resolution
6. request a Let's Encrypt certificate
7. validate and reload the final HTTPS configuration

The important part is idempotence. Running deployment automation twice should repair or confirm state rather than create a second conflicting configuration.

Environment variables instead of hard-coded secrets

Secrets and mutable deployment values belong in environment files or shell variables.

For application deployments I use patterns such as:

export ADMIN_USER="..."
export ADMIN_PASSWORD="..."
export SECRET_KEY="$(openssl rand -hex 32)"

The repository contains examples and variable names, not production secrets.

Why this matters

This workflow is small, but it represents the same principle used in larger infrastructure systems: describe the desired endpoint and automate the repeated infrastructure work around it.

The next application does not require remembering every Certbot or Nginx command. It follows the same deployment path.

That makes adding services faster, but more importantly, it makes the environment reproducible.