Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Use as Website host / Web server directly #58

Open
TheBlueKingLP opened this issue Jan 24, 2019 · 15 comments
Open

[Feature request] Use as Website host / Web server directly #58

TheBlueKingLP opened this issue Jan 24, 2019 · 15 comments

Comments

@TheBlueKingLP
Copy link

I would like to see website host in this docker
It should be like the proxy host, but instead of asking you for the Scheme,Forward Hostname / IP and Forward Port, it should ask for a path for the website contents.
It should also support php7 for hosting php files.

@brandonkal
Copy link

I can see adding support for static sites. This would be a nice feature. Setting fast-cgi parameters may even be a nice enhancement.

But executing php, ruby, node, etc should not be in the scope of this project. It should be done in its own docker container. Just add it to your docker-compose file. Or consider using Caddy @TheBlueKingLP with a php backend container.

@jc21
Copy link
Member

jc21 commented Feb 25, 2019

Yep :) I agree that if I open the floodgates with PHP support, I'd have to do it for others as well. Not to mention that PHP with Nginx requires yet another process to be running in the background and I'm not sure about other cgi handlers but I'd guess they might need them too. This doesn't make the proxy a lightweight solution.

I can see value in adding basic html support though. Seems overkill to spin up another docker container just to spit out plain text html files. Adding this feature costs nothing.

In future it might be possible to build spin-off docker images that extend the base functionality, so you might have latest, latest-php, latest-ruby etc and leave the choice up to the end user rather than trying to accommodate everyone. But don't hold your breath on that.

@ptr727
Copy link

ptr727 commented May 7, 2019

Yes please, static site, mapped in container path.

@brentco
Copy link

brentco commented Jun 15, 2019

It would be great! This is the thing I'm missing the most. I started up this image and I quickly realized "wait a minute, I don't have that many proxies". I have a wordpress website, a simple domain that makes a folder browseable, and some subdomains that are proxies but yeah... I'm conflicted now because the bulk of my configuration wouldn't be managed by the UI :(

So please, consider adding this website host feature, optionally with the spin-off docker images you mentioned! Let me know if you require assistance!

@lopugit
Copy link

lopugit commented Mar 6, 2020

At first I wanted static sites to be supported but I get why they're not, it would mean your nginx container would need to have a bunch of volumes attached to it for each static site, or just 1 volume for all of them, and that defeats the modular purpose of docker.

What I'm doing is running this, proxying to a certain ip, which then runs another deployment of an nginx container with 1 static site in it, so each static site gets its own nginx process and ip, effectively turning static sites into ip address sites.

Now then yeah you have to manage that config through text but managing one site's config through files is alright compared to managing numerous load-balanced proxies on your nginx-proxy-manager instance.

Just my thoughts

@realJoshByrnes
Copy link
Contributor

I've been doing this following for quite some time in my 404 hosts to enable some simple static hosting

root /var/www/html;

location / {
  index index.html index.htm;
}

Note: This will likely break your preset settings such as "Force SSL" settings for this host. (although certificates will work fine)

For PHP support

My docker compose is slightly different, I've added PHP FPM in a seperate container, and I'm exposing the host's /var/www directory to both the app and php container (the directory could be anything, but this is what I chose to use)

version: "3"
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: always
    ports:
      # Public HTTP Port:
      - '80:80'
      # Public HTTPS Port:
      - '443:443'
      # Admin Web Port:
      - '81:81'
    environment:
      # These are the settings to access your db
      DB_MYSQL_HOST: "db"
      DB_MYSQL_PORT: 3306
      DB_MYSQL_USER: "npm"
      DB_MYSQL_PASSWORD: "npm"
      DB_MYSQL_NAME: "npm"
      # If you would rather use Sqlite uncomment this
      # and remove all DB_MYSQL_* lines above
      # DB_SQLITE_FILE: "/data/database.sqlite"
      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
      - /var/www:/var/www
    depends_on:
      - db
    links:
      - php
  php:
    image: php:8-fpm
    restart: always
    volumes:
      - /var/www:/var/www
  db:
    image: 'jc21/mariadb-aria:latest'
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 'npm'
      MYSQL_DATABASE: 'npm'
      MYSQL_USER: 'npm'
      MYSQL_PASSWORD: 'npm'
    volumes:
      - ./data/mysql:/var/lib/mysql

Finally, for those hosts that you would like to enable PHP on, you should use something like the following in the advanced tab

root /var/www/html;

location / {
  index index.php index.html index.htm;
}

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass php:9000;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
}

I quite like that I can mix and match PHP and non-PHP sites quite easily on the same host. There may be a more elegant solution but this is what I've been using for quite some time, so thought I'd share it.

@ssrahul96
Copy link
Contributor

@jc21, without php support? will it be okay to add the static html files. (may be generated by fronted framework)

can we add another scheme here as path. (i know that scheme is not an appropriate term but,)

image

then update the path provided there and update the template file ??

image

@xannor
Copy link

xannor commented Sep 26, 2021

I agree with @ssrahul96 and think that a file scheme with only a required path box would be ideal. I would also like to suggest adding this to the custom locations as well (though in its template it would be alias instead of root). I would also suggest that no default location / or such be added, I believe file should be considered and "advanced" scheme and require any additional setup be done in the appropriate advanced configuration box.
This would handle most of the requests for static/cgi_pass issues without requiring a ton of custom code for npm, though it would not be as "easy" as a normal setup, this use is the exception not the rule.

@realJoshByrnes
Copy link
Contributor

realJoshByrnes commented Sep 26, 2021

I've been thinking about adding a file host, with an optional FPM style handler. I'd default to /var/www (Hello world!) and allow a user to change the location. Haven't thought it through too much, but would be interested in seeing others input before committing to a PR.

@xannor
Copy link

xannor commented Oct 2, 2021

I have been giving this a think for the past few days, and I think the following would work:
Adding a static file host type, with support for a (container/env local) path, that defaults to /var/www/1st domain but can be overridden with a path box, and an additional default for a default page of index.html, which can also be overridden with a defaults box, would do the trick. Also present should be the SSL/locations/and advanced tabs. However, in the locations (for both this host and a proxy host, could an additional "scheme" be added that would support static file locations as well (with similar options as above for the static host.)

As for FPM, there are some "basic" options you could provide, but I think that most of the time people would need to copy/paste a setup that is specific to the app they are forwarding, so I still feel this should be left as an "advanced" procedure.

Would you agree that this is a good starting point, and something you could make a PR for?

@JasSra
Copy link

JasSra commented Oct 5, 2021

We need another host type. File host. it could take a simple path that needs to be accessible for a start.

@DusterTheFirst
Copy link

Has there been any work on this? Is there any where I could lend my efforts to help get this feature added?

@dimkasta
Copy link

Having this would make this a full nginx manager. I understand that having fast cgi backends would significantly increase maintenance effort. The easiest way to do it would be to declare simple static sites plus the ability to declare fastcgi backends. And let the fastcgi service to be configured by the user as a separate backend that is not managed by npm.

The other issue would be that we would need custom directives per domain/backend. It's very common to require special config to support pretty URLs, secure sensitive data, define compression, and so on.

I am currently using Caddy for this reason, but I would love to have alternatives, especially with the speed and gravity of nginx.

Copy link

github-actions bot commented Apr 4, 2024

Issue is now considered stale. If you want to keep it open, please comment 👍

@github-actions github-actions bot added the stale label Apr 4, 2024
@tigusigalpa
Copy link

Default WWW/root folder/directory for docker container managed by Nginx Proxy Manager is /usr/share/nginx/html. Take a look here at StackOverflow

@github-actions github-actions bot removed the stale label Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests