Internal Mechanics

Using a NetGet Gateway for application-specific logic and Nginx for SSL termination and initial request handling.

—Nginx for robust web serving and SSL, and NetGet for dynamic, application-level routing and middleware services.

This is how this works, considering the use of wildcards and specific domain handling:

Using Wildcard SSL with Nginx

If your applications follow a subdomain structure like username.cleaker.me or realm.mdrn.me, you can indeed use a wildcard SSL certificate for each root domain (*.cleaker.me, *.mdrn.me) to secure them. This setup simplifies the SSL configuration in Nginx because you won't need a separate certificate for each subdomain.

Generic server block in Nginx that handles all subdomains for a given root domain:

nginx

server {

 listen 443 ssl;

 server_name *.cleaker.me;


 ssl_certificate /path/to/wildcard.cleaker.me.crt;

 ssl_certificate_key /path/to/wildcard.cleaker.me.key;


 location / {

 proxy_pass http://localhost:3000; # Pass to the NetGet Gateway

 proxy_set_header Host $host;

 # Other proxy settings...

 }

}


You would have a similar block for *.mdrn.me and any other domains you manage.

Domain Routing in NetGet Gateway

The NetGet gateway should then handle the logic to determine what to do based on the Host header, which includes the subdomain and domain. In the gateway, you'll inspect this header to route the request to the appropriate application or handler.

For instance, when a request comes in for username.cleaker.me, the gateway identifies it's for cleaker.me and further processes the username subdomain part to route internally to the correct user space.

Adding New Domains

When you want to add a new domain like mlisa.me, you'd:

Concerning Nginx Configuration

While you can handle many domains with generic wildcard blocks in Nginx, each unique root domain (cleaker.me, mdrn.me, mlisa.me) still requires its server block for SSL configuration. However, once the SSL is configured and the traffic is forwarded to the NetGet gateway, all the application-specific logic is handled there, avoiding the need to adjust Nginx for each new subdomain.

The wildcard SSL and a generic server block per root domain reduce the need for frequent Nginx configuration changes. You'll mostly deal with the initial setup per new root domain and then manage the specifics within the NetGet gateway, maintaining the agility to add and modify application behaviors without modifying Nginx each time.

In conclusion, your strategy effectively separates concerns: Nginx deals with SSL and basic request forwarding, while NetGet takes on application routing and middleware logic. This setup offers a scalable and flexible approach to managing multiple applications and domains.