Best practice for using reverse proxy hosting of multiple .NET Core apps

I’m currently looking into hosting some .NET Core apps on an Ubuntu server with Hestia CP.

I’m wondering what the best practice is to do so.
Is it best to create different Nginx templates for each .NET app/port?

Or is there an easier/better way to achieve this effect?

I’ve seen that there currently is no plan to include a port parameter in the web admin for reverse proxying as suggested here:

hey mischak, I’d say it depends on how you want to differentiate your apps. if it is by domain/sub-domain then I’d say a teamplate for each app is the way to go for now.

if it is via path (location) then you obviously have to put everything into one template and hard-code your paths there.

a third option could be to create a template that is nearly empty but apart from servername/alias/ssl config only includes the custom conf files.
you could then easily reuse this but add your app specifics within the custom config directly in domain conf folder…

@falzo Thanks for your input.

I think most apps would be domain / subdomain.
So either full .NET Core website on domain or perhaps something like an api.domain.ext.

Are there any of these almost empty templates out there which I could use as a starting point or would starting from the included templates make the most sense?

I’d probably copy the the default.tpl/default.stpl into a new one and remove all location blocks, so that it looks something like this (as example the ssl one):

#=======================================================================#

server {
    listen      %ip%:%proxy_ssl_port% ssl http2;
    server_name %domain_idn% %alias_idn%;
    ssl_certificate      %ssl_pem%;
    ssl_certificate_key  %ssl_key%;
    ssl_stapling on;
    ssl_stapling_verify on;
    error_log  /var/log/%web_system%/domains/%domain%.error.log error;

    include %home%/%user%/conf/web/%domain%/nginx.hsts.conf*;

    include %home%/%user%/conf/web/%domain%/nginx.ssl.conf_*;
}

#=======================================================================#

you could leave the location /error/ block in there if you want to use custom error-docs and if it does not conflict with your app.

you also might need to think of something to pass through to apache (if using that) for handling letsencrypt requests properly.

PS: ofc then you still need to create your individual location blocks with proxy directives and whatnot in an nginx.ssl.conf_custom for your app in the /home/<user>/conf/web/<domain> folder :wink:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.