docker-swag

Nginx webserver and reverse proxy with php support and a built-in Certbot (Let's Encrypt) client. It also contains fail2ban for intrusion prevention.

2,791

239

2,791

View on GitHub

Top Related Projects

nginx-proxy

18,478

Automated nginx proxy for Docker containers using docker-gen

nginx-proxy-manager

21,962

Docker container for managing Nginx proxy hosts with a simple, powerful interface

traefik

50,858

The Cloud Native Application Proxy

caddy

56,905

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

Quick Overview

SWAG (Secure Web Application Gateway) is a Docker container that combines Nginx, Let's Encrypt, and Fail2Ban to provide a secure and easy-to-use reverse proxy solution. It simplifies the process of setting up HTTPS for web applications and offers additional security features out of the box.

Pros

Easy setup and configuration for secure web applications
Automatic SSL certificate management with Let's Encrypt integration
Built-in security features like Fail2Ban for protection against brute-force attacks
Regular updates and active community support

Cons

Requires basic understanding of Docker and networking concepts
May have a steeper learning curve for users new to reverse proxies
Limited customization options compared to manual setups
Potential performance overhead due to the all-in-one nature of the container

Getting Started

To get started with SWAG, follow these steps:

Pull the SWAG Docker image:

docker pull linuxserver/swag

Create a Docker Compose file (e.g., docker-compose.yml) with the following content:

version: "3"
services:
  swag:
    image: linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      - URL=yourdomain.com
      - SUBDOMAINS=www,
      - VALIDATION=http
      - CERTPROVIDER=letsencrypt
    volumes:
      - /path/to/appdata/config:/config
    ports:
      - 443:443
      - 80:80
    restart: unless-stopped

Replace yourdomain.com with your actual domain name and adjust the SUBDOMAINS as needed.
Start the SWAG container:

docker-compose up -d

Configure your web applications to use SWAG as a reverse proxy by adding appropriate location blocks to the Nginx configuration files in the /config/nginx/proxy-confs/ directory.

For more detailed instructions and advanced configuration options, refer to the official documentation on the GitHub repository.

Competitor Comparisons

nginx-proxy

18,478

Automated nginx proxy for Docker containers using docker-gen

Pros of nginx-proxy

Automatic container discovery and configuration
Supports multiple networks and custom networks
Lightweight and focused solely on reverse proxy functionality

Cons of nginx-proxy

Limited built-in SSL/TLS support (requires additional containers)
Less comprehensive out-of-the-box features compared to SWAG
May require more manual configuration for advanced setups

Code Comparison

SWAG configuration example:

server {
    listen 443 ssl;
    server_name example.com;
    include /config/nginx/ssl.conf;
    location / {
        proxy_pass http://backend;
    }
}

nginx-proxy configuration example:

server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend;
    }
}

Summary

SWAG offers a more comprehensive solution with built-in SSL/TLS support, while nginx-proxy focuses on simplicity and automatic container discovery. SWAG provides a wider range of pre-configured features, making it easier for users to set up complex environments. nginx-proxy, on the other hand, offers more flexibility and is lighter weight, but may require additional setup for SSL/TLS and other advanced features. The choice between the two depends on the specific needs of the project and the user's preference for simplicity versus out-of-the-box functionality.

nginx-proxy-manager

21,962

Docker container for managing Nginx proxy hosts with a simple, powerful interface

Pros of nginx-proxy-manager

User-friendly web interface for managing proxy hosts and SSL certificates
Built-in Let's Encrypt integration for easy certificate management
Supports multiple users with different access levels

Cons of nginx-proxy-manager

Less customizable than docker-swag for advanced Nginx configurations
May have a slightly higher resource overhead due to the web interface

Code Comparison

nginx-proxy-manager configuration (in docker-compose.yml):

version: '3'
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    ports:
      - '80:80'
      - '81:81'
      - '443:443'

docker-swag configuration (in docker-compose.yml):

version: '3'
services:
  swag:
    image: linuxserver/swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      - URL=yourdomain.com
      - SUBDOMAINS=www,
      - VALIDATION=http

Both projects provide reverse proxy and SSL management solutions, but nginx-proxy-manager focuses on ease of use with its web interface, while docker-swag offers more flexibility for advanced users who prefer direct configuration. docker-swag also includes additional features like fail2ban and organizr integration.

traefik

50,858

The Cloud Native Application Proxy

Pros of Traefik

More feature-rich and flexible, supporting multiple providers and backends
Built-in dashboard for monitoring and management
Better suited for complex, dynamic environments with service discovery

Cons of Traefik

Steeper learning curve due to more complex configuration
May be overkill for simple setups or single-server environments
Requires more resources to run compared to SWAG

Code Comparison

SWAG (nginx configuration):

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
    # ...
}

Traefik (YAML configuration):

http:
  routers:
    myrouter:
      rule: "Host(`example.com`)"
      service: myservice
      tls:
        certResolver: myresolver
  services:
    myservice:
      loadBalancer:
        servers:
          - url: "http://backend:8080"

SWAG is simpler for basic reverse proxy and SSL termination, while Traefik offers more advanced features and dynamic configuration. SWAG is easier to set up for beginners, but Traefik provides greater scalability and flexibility for complex environments.

caddy

56,905

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS

Pros of Caddy

Automatic HTTPS with Let's Encrypt integration out of the box
Simpler configuration syntax, making it easier to set up and maintain
Built-in HTTP/3 support for improved performance

Cons of Caddy

Less comprehensive feature set compared to SWAG's Nginx-based solution
May require additional configuration for advanced use cases
Limited support for legacy systems and protocols

Code Comparison

SWAG (Nginx) configuration:

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://backend;
    }
}

Caddy configuration:

example.com {
    reverse_proxy backend
}

The Caddy configuration is significantly simpler, automatically handling HTTPS and certificate management. SWAG requires more explicit configuration but offers greater flexibility for complex setups.

Both projects provide Docker-based solutions for web serving and reverse proxying, with SWAG offering a more comprehensive suite of tools and Caddy focusing on simplicity and ease of use. The choice between them depends on specific project requirements and the level of customization needed.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

The LinuxServer.io team brings you another container release featuring:

regular and timely application updates
easy user mappings (PGID, PUID)
custom base image with s6 overlay
weekly base OS updates with common layers across the entire LinuxServer.io ecosystem to minimise space usage, down time and bandwidth
regular security updates

Find us at:

Blog - all the things you can do with our containers including How-To guides, opinions and much more!
Discord - realtime support / chat with the community and the team.
Discourse - post on our community forum.
Fleet - an online web interface which displays all of our maintained images.
GitHub - view the source for all of our repositories.
Open Collective - please consider helping us by either donating or contributing to our budget

linuxserver/swag

SWAG - Secure Web Application Gateway (formerly known as letsencrypt, no relation to Let's Encryptâ¢) sets up an Nginx webserver and reverse proxy with php support and a built-in certbot client that automates free SSL server certificate generation and renewal processes (Let's Encrypt and ZeroSSL). It also contains fail2ban for intrusion prevention.

Supported Architectures

We utilise the docker manifest for multi-platform awareness. More information is available from docker here and our announcement here.

Simply pulling lscr.io/linuxserver/swag:latest should retrieve the correct image for your arch, but you can also pull specific arch images via tags.

The architectures supported by this image are:

Architecture	Available	Tag
x86-64	â	amd64-<version tag>
arm64	â	arm64v8-<version tag>
armhf	â

Application Setup

Validation and initial setup

Before running this container, make sure that the url and subdomains are properly forwarded to this container's host, and that port 443 (and/or 80) is not being used by another service on the host (NAS gui, another webserver, etc.).
If you need a dynamic dns provider, you can use the free provider duckdns.org where the URL will be yoursubdomain.duckdns.org and the SUBDOMAINS can be www,ftp,cloud with http validation, or wildcard with dns validation. You can use our duckdns image to update your IP on duckdns.org.
For http validation, port 80 on the internet side of the router should be forwarded to this container's port 80
For dns validation, make sure to enter your credentials into the corresponding ini (or json for some plugins) file under /config/dns-conf
- Cloudflare provides free accounts for managing dns and is very easy to use with this image. Make sure that it is set up for "dns only" instead of "dns + proxy"
- Google dns plugin is meant to be used with "Google Cloud DNS", a paid enterprise product, and not for "Google Domains DNS"
- DuckDNS only supports two types of DNS validated certificates (not both at the same time):
  1. Certs that only cover your main subdomain (ie. yoursubdomain.duckdns.org, leave the SUBDOMAINS variable empty)
  2. Certs that cover sub-subdomains of your main subdomain (ie. *.yoursubdomain.duckdns.org, set the SUBDOMAINS variable to wildcard)
--cap-add=NET_ADMIN is required for fail2ban to modify iptables
After setup, navigate to https://yourdomain.url to access the default homepage (http access through port 80 is disabled by default, you can enable it by editing the default site config at /config/nginx/site-confs/default.conf).
Certs are checked nightly and if expiration is within 30 days, renewal is attempted. If your cert is about to expire in less than 30 days, check the logs under /config/log/letsencrypt to see why the renewals have been failing. It is recommended to input your e-mail in docker parameters so you receive expiration notices from Let's Encrypt in those circumstances.

Certbot Plugins

SWAG includes many Certbot plugins out of the box, but not all plugins can be included. If you need a plugin that is not included, the quickest way to have the plugin available is to use our Universal Package Install Docker Mod.

Set the following environment variables on your container:

DOCKER_MODS=linuxserver/mods:universal-package-install
INSTALL_PIP_PACKAGES=certbot-dns-<plugin>

Set the required credentials (usually found in the plugin documentation) in /config/dns-conf/<plugin>.ini. It is recommended to attempt obtaining a certificate with STAGING=true first to make sure the plugin is working as expected.

Security and password protection

The container detects changes to url and subdomains, revokes existing certs and generates new ones during start.
Per RFC7919, the container is shipping ffdhe4096 as the dhparams.pem.
If you'd like to password protect your sites, you can use htpasswd. Run the following command on your host to generate the htpasswd file docker exec -it swag htpasswd -c /config/nginx/.htpasswd <username>
You can add multiple user:pass to .htpasswd. For the first user, use the above command, for others, use the above command without the -c flag, as it will force deletion of the existing .htpasswd and creation of a new one
You can also use ldap auth for security and access control. A sample, user configurable ldap.conf is provided, and it requires the separate image linuxserver/ldap-auth to communicate with an ldap server.

Site config and reverse proxy

The default site config resides at /config/nginx/site-confs/default.conf. Feel free to modify this file, and you can add other conf files to this directory. However, if you delete the default file, a new default will be created on container start.
Preset reverse proxy config files are added for popular apps. See the README.md file under /config/nginx/proxy_confs for instructions on how to enable them. The preset confs reside in and get imported from this repo.
If you wish to hide your site from search engine crawlers, you may find it useful to add this configuration line to your site config, within the server block, above the line where ssl.conf is included add_header X-Robots-Tag "noindex, nofollow, nosnippet, noarchive"; This will ask Google et al not to index and list your site. Be careful with this, as you will eventually be de-listed if you leave this line in on a site you wish to be present on search engines
If you wish to redirect http to https, you must expose port 80

Using certs in other containers

This container includes auto-generated pfx and private-fullchain-bundle pem certs that are needed by other apps like Emby and Znc.
- To use these certs in other containers, do either of the following:
1. (Easier) Mount the container's config folder in other containers (ie. -v /path-to-swag-config:/swag-ssl) and in the other containers, use the cert location /swag-ssl/keys/letsencrypt/
2. (More secure) Mount the SWAG folder etc that resides under /config in other containers (ie. -v /path-to-swag-config/etc:/swag-ssl) and in the other containers, use the cert location /swag-ssl/letsencrypt/live/<your.domain.url>/ (This is more secure because the first method shares the entire SWAG config folder with other containers, including the www files, whereas the second method only shares the ssl certs)
- These certs include:
1. cert.pem, chain.pem, fullchain.pem and privkey.pem, which are generated by Certbot and used by nginx and various other apps
2. privkey.pfx, a format supported by Microsoft and commonly used by dotnet apps such as Emby Server (no password)
3. priv-fullchain-bundle.pem, a pem cert that bundles the private key and the fullchain, used by apps like ZNC

Using fail2ban

This container includes fail2ban set up with 5 jails by default:
1. nginx-http-auth
2. nginx-badbots
3. nginx-botsearch
4. nginx-deny
5. nginx-unauthorized
To enable or disable other jails, modify the file /config/fail2ban/jail.local
To modify filters and actions, instead of editing the .conf files, create .local files with the same name and edit those because .conf files get overwritten when the actions and filters are updated. .local files will append whatever's in the .conf files (ie. nginx-http-auth.conf --> nginx-http-auth.local)
You can check which jails are active via docker exec -it swag fail2ban-client status
You can check the status of a specific jail via docker exec -it swag fail2ban-client status <jail name>
You can unban an IP via docker exec -it swag fail2ban-client set <jail name> unbanip <IP>
A list of commands can be found here: https://www.fail2ban.org/wiki/index.php/Commands

Updating configs

This container creates a number of configs for nginx, proxy samples, etc.
Config updates are noted in the changelog but not automatically applied to your files.
If you have modified a file with noted changes in the changelog:
1. Keep your existing configs as is (not broken, don't fix)
2. Review our repository commits and apply the new changes yourself
3. Delete the modified config file with listed updates, restart the container, reapply your changes
If you have NOT modified a file with noted changes in the changelog:
1. Delete the config file with listed updates, restart the container
Proxy sample updates are not listed in the changelog. See the changes here: https://github.com/linuxserver/reverse-proxy-confs/commits/master
Proxy sample files WILL be updated, however your renamed (enabled) proxy files will not.
You can check the new sample and adjust your active config as needed.

Migration from the old `linuxserver/letsencrypt` image

Please follow the instructions on this blog post.

Usage

To help you get started creating a container from this image you can either use docker-compose or the docker cli.

docker-compose (recommended, click here for more info)

---
services:
  swag:
    image: lscr.io/linuxserver/swag:latest
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - URL=yourdomain.url
      - VALIDATION=http
      - SUBDOMAINS=www, #optional
      - CERTPROVIDER= #optional
      - DNSPLUGIN=cloudflare #optional
      - PROPAGATION= #optional
      - EMAIL= #optional
      - ONLY_SUBDOMAINS=false #optional
      - EXTRA_DOMAINS= #optional
      - STAGING=false #optional
    volumes:
      - /path/to/swag/config:/config
    ports:
      - 443:443
      - 80:80 #optional
    restart: unless-stopped

docker cli (click here for more info)

docker run -d \
  --name=swag \
  --cap-add=NET_ADMIN \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Etc/UTC \
  -e URL=yourdomain.url \
  -e VALIDATION=http \
  -e SUBDOMAINS=www, `#optional` \
  -e CERTPROVIDER= `#optional` \
  -e DNSPLUGIN=cloudflare `#optional` \
  -e PROPAGATION= `#optional` \
  -e EMAIL= `#optional` \
  -e ONLY_SUBDOMAINS=false `#optional` \
  -e EXTRA_DOMAINS= `#optional` \
  -e STAGING=false `#optional` \
  -p 443:443 \
  -p 80:80 `#optional` \
  -v /path/to/swag/config:/config \
  --restart unless-stopped \
  lscr.io/linuxserver/swag:latest

Parameters

Containers are configured using parameters passed at runtime (such as those above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container.

Parameter	Function
`-p 443`	Https port
`-p 80`	Http port (required for http validation and http -> https redirect)
`-e PUID=1000`	for UserID - see below for explanation
`-e PGID=1000`	for GroupID - see below for explanation
`-e TZ=Etc/UTC`	specify a timezone to use, see this list.
`-e URL=yourdomain.url`	Top url you have control over (`customdomain.com` if you own it, or `customsubdomain.ddnsprovider.com` if dynamic dns).
`-e VALIDATION=http`	Certbot validation method to use, options are `http` or `dns` (`dns` method also requires `DNSPLUGIN` variable set).
`-e SUBDOMAINS=www,`	Subdomains you'd like the cert to cover (comma separated, no spaces) ie. `www,ftp,cloud`. For a wildcard cert, set this exactly to `wildcard` (wildcard cert is available via `dns` validation only)
`-e CERTPROVIDER=`	Optionally define the cert provider. Set to `zerossl` for ZeroSSL certs (requires existing ZeroSSL account and the e-mail address entered in `EMAIL` env var). Otherwise defaults to Let's Encrypt.
`-e DNSPLUGIN=cloudflare`	Required if `VALIDATION` is set to `dns`. Options are `acmedns`, `aliyun`, `azure`, `bunny`, `cloudflare`, `cpanel`, `desec`, `digitalocean`, `directadmin`, `dnsimple`, `dnsmadeeasy`, `dnspod`, `do`, `domeneshop`, `dreamhost`, `duckdns`, `dynudns`, `freedns`, `gandi`, `gehirn`, `glesys`, `godaddy`, `google`, `he`, `hetzner`, `infomaniak`, `inwx`, `ionos`, `linode`, `loopia`, `luadns`, `namecheap`, `netcup`, `njalla`, `nsone`, `ovh`, `porkbun`, `rfc2136`, `route53`, `sakuracloud`, `standalone`, `transip`, and `vultr`. Also need to enter the credentials into the corresponding ini (or json for some plugins) file under `/config/dns-conf`.
`-e PROPAGATION=`	Optionally override (in seconds) the default propagation time for the dns plugins.
`-e EMAIL=`	Optional e-mail address used for cert expiration notifications (Required for ZeroSSL).
`-e ONLY_SUBDOMAINS=false`	If you wish to get certs only for certain subdomains, but not the main domain (main domain may be hosted on another machine and cannot be validated), set this to `true`
`-e EXTRA_DOMAINS=`	Additional fully qualified domain names (comma separated, no spaces) ie. `extradomain.com,subdomain.anotherdomain.org,*.anotherdomain.org`
`-e STAGING=false`	Set to `true` to retrieve certs in staging mode. Rate limits will be much higher, but the resulting cert will not pass the browser's security test. Only to be used for testing purposes.
`-v /config`	Persistent config files

Portainer notice

This image utilises cap_add or sysctl to work properly. This is not implemented properly in some versions of Portainer, thus this image may not work if deployed through Portainer.

Environment variables from files (Docker secrets)

You can set any environment variable from a file by using a special prepend FILE__.

As an example:

-e FILE__MYVAR=/run/secrets/mysecretvariable

Will set the environment variable MYVAR based on the contents of the /run/secrets/mysecretvariable file.

Umask for running applications

For all of our images we provide the ability to override the default umask settings for services started within the containers using the optional -e UMASK=022 setting. Keep in mind umask is not chmod it subtracts from permissions based on it's value it does not add. Please read up here before asking for support.

User / Group Identifiers

When using volumes (-v flags), permissions issues can arise between the host OS and the container, we avoid this issue by allowing you to specify the user PUID and group PGID.

Ensure any volume directories on the host are owned by the same user you specify and any permissions issues will vanish like magic.

In this instance PUID=1000 and PGID=1000, to find yours use id your_user as below:

id your_user

Example output:

uid=1000(your_user) gid=1000(your_user) groups=1000(your_user)

Docker Mods

We publish various Docker Mods to enable additional functionality within the containers. The list of Mods available for this image (if any) as well as universal mods that can be applied to any one of our images can be accessed via the dynamic badges above.

Support Info

Shell access whilst the container is running:
```
docker exec -it swag /bin/bash
```
To monitor the logs of the container in realtime:
```
docker logs -f swag
```

Container version number:

docker inspect -f '{{ index .Config.Labels "build_version" }}' swag

Image version number:

docker inspect -f '{{ index .Config.Labels "build_version" }}' lscr.io/linuxserver/swag:latest

Updating Info

Most of our images are static, versioned, and require an image update and container recreation to update the app inside. With some exceptions (noted in the relevant readme.md), we do not recommend or support updating apps inside the container. Please consult the Application Setup section above to see if it is recommended for the image.

Below are the instructions for updating containers:

Via Docker Compose

Update images:

All images:
```
docker-compose pull
```
Single image:
```
docker-compose pull swag
```

Update containers:

All containers:
```
docker-compose up -d
```
Single container:
```
docker-compose up -d swag
```

You can also remove the old dangling images:
```
docker image prune
```

Via Docker Run

Update the image:

docker pull lscr.io/linuxserver/swag:latest

Stop the running container:
```
docker stop swag
```
Delete the container:
```
docker rm swag
```
Recreate a new container with the same docker run parameters as instructed above (if mapped correctly to a host folder, your /config folder and settings will be preserved)
You can also remove the old dangling images:
```
docker image prune
```

Image Update Notifications - Diun (Docker Image Update Notifier)

tip: We recommend Diun for update notifications. Other tools that automatically update containers unattended are not recommended or supported.

Building locally

If you want to make local modifications to these images for development purposes or just to customize the logic:

git clone https://github.com/linuxserver/docker-swag.git
cd docker-swag
docker build \
  --no-cache \
  --pull \
  -t lscr.io/linuxserver/swag:latest .

The ARM variants can be built on x86_64 hardware using multiarch/qemu-user-static

docker run --rm --privileged multiarch/qemu-user-static:register --reset

Once registered you can define the dockerfile to use with -f Dockerfile.aarch64.

Versions

30.08.24: - Fix zerossl cert revocation.
24.07.14: - Rebase to Alpine 3.20. Remove deprecated Google Domains certbot plugin. Existing users should update their nginx confs to avoid http2 deprecation warnings.
01.07.24: - Fall back to iptables-legacy if iptables doesn't work.
23.03.24: - Fix perms on the generated priv-fullchain-bundle.pem.
14.03.24: - Existing users should update: authelia-location.conf, authelia-server.conf - Update Authelia conf samples with support for 4.38.
11.03.24: - Restore support for DynuDNS using certbot-dns-dynudns.
06.03.24: - Existing users should update: site-confs/default.conf - Cleanup default site conf.
04.03.24: - Remove stream.conf inside the container to allow users to include their own block in nginx.conf.
23.01.24: - Rebase to Alpine 3.19 with php 8.3, add root periodic crontabs for logrotate.
01.01.24: - Add GleSYS DNS plugin.
11.12.23: - Deprecate certbot-dns-dynu to resolve dependency conflicts with other plugins.
30.11.23: - Existing users should update: site-confs/default.conf - Fix index.php being downloaded on 404.
23.11.23: - Run certbot as root to allow fix http validation.
01.10.23: - Fix "unrecognized arguments" issue in DirectAdmin DNS plugin.
28.08.23: - Add Namecheap DNS plugin.
12.08.23: - Add FreeDNS plugin. Detect certbot DNS authenticators using CLI.
07.08.23: - Add Bunny DNS Configuration.
27.07.23: - Added support for dreamhost validation.
25.05.23: - Rebase to Alpine 3.18, deprecate armhf.
27.04.23: - Existing users should update: authelia-location.conf, authelia-server.conf, authentik-location.conf, authentik-server.conf - Simplify auth configs and fix Set-Cookie header bug.
13.04.23: - Existing users should update: nginx.conf, authelia-location.conf, authentik-location.conf, and site-confs/default.conf - Move ssl.conf include to default.conf. Remove Authorization headers in authelia. Sort proxy_set_header in authelia and authentik.
25.03.23: - Fix renewal post hook.
10.03.23: - Cleanup unused csr and keys folders. See certbot 2.3.0 release notes.
09.03.23: - Add Google Domains DNS support, google-domains.
02.03.23: - Set permissions on crontabs during init.
09.02.23: - Existing users should update: proxy.conf, authelia-location.conf and authelia-server.conf - Add Authentik configs, update Authelia configs.
06.02.23: - Add porkbun support back in.
21.01.23: - Unpin certbot version (allow certbot 2.x). !!BREAKING CHANGE!! We are temporarily removing the certbot porkbun plugin until a new version is released that is compatible with certbot 2.x.
20.01.23: - Rebase to alpine 3.17 with php8.1.
16.01.23: - Remove nchan module because it keeps causing crashes.
08.12.22: - Revamp certbot init.
03.12.22: - Remove defunct cloudxns plugin.
22.11.22: - Pin acme to the same version as certbot.
22.11.22: - Pin certbot to 1.32.0 until plugin compatibility improves.
05.11.22: - Update acmedns plugin handling.
06.10.22: - Switch to certbot-dns-duckdns. Update cpanel and gandi dns plugin handling. Minor adjustments to init logic.
05.10.22: - Use certbot file hooks instead of command line hooks
04.10.22: - Add godaddy and porkbun dns plugins.
03.10.22: - Add default_server back to default site conf's https listen.
22.09.22: - Added support for DO DNS validation.
22.09.22: - Added certbot-dns-acmedns for DNS01 validation.
20.08.22: - Existing users should update: nginx.conf - Rebasing to alpine 3.15 with php8. Restructure nginx configs (see changes announcement).
10.08.22: - Added support for Dynu DNS validation.
18.05.22: - Added support for Azure DNS validation.
09.04.22: - Added certbot-dns-loopia for DNS01 validation.
05.04.22: - Added support for standalone DNS validation.
28.03.22: - created a logfile for fail2ban nginx-unauthorized in /etc/cont-init.d/50-config
09.01.22: - Added a fail2ban jail for nginx unauthorized
21.12.21: - Fixed issue with iptables not working as expected
30.11.21: - Move maxmind to a new mod
22.11.21: - Added support for Infomaniak DNS for certificate generation.
20.11.21: - Added support for dnspod validation.
15.11.21: - Added support for deSEC DNS for wildcard certificate generation.
26.10.21: - Existing users should update: proxy.conf - Mitigate https://httpoxy.org/ vulnerabilities. Ref: https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx#Defeating-the-Attack-using-NGINX-and-NGINX-Plus
23.10.21: - Fix Hurricane Electric (HE) DNS validation.
12.10.21: - Fix deprecated LE root cert check to fix failures when using STAGING=true, and failures in revoking.
06.10.21: - Added support for Hurricane Electric (HE) DNS validation. Added lxml build deps.
01.10.21: - Check if the cert uses the old LE root cert, revoke and regenerate if necessary. Here's more info on LE root cert expiration
19.09.21: - Add an optional header to opt out of Google FLoC in ssl.conf.
17.09.21: - Mark SUBDOMAINS var as optional.
01.08.21: - Add support for ionos dns validation.
15.07.21: - Fix libmaxminddb issue due to upstream change.
07.07.21: - Rebase to alpine 3.14.
24.06.21: - Update default nginx conf folder.
28.05.21: - Existing users should update: authelia-server.conf - Use resolver.conf and patch for CVE-2021-32637.
20.05.21: - Modify resolver.conf generation to detect and ignore ipv6.
14.05.21: - Existing users should update: nginx.conf, ssl.conf, proxy.conf, and the default site-conf - Rework nginx.conf to be inline with alpine upstream and relocate lines from other files. Use linuxserver.io wheel index for pip packages. Switch to using ffdhe4096 for dhparams.pem per RFC7919. Added worker_processes.conf, which sets the number of nginx workers, and resolver.conf, which sets the dns resolver. Both conf files are auto-generated only on first start and can be user modified later.
21.04.21: - Existing users should update: authelia-server.conf and authelia-location.conf - Add remote name/email headers and pass http method.
12.04.21: - Add php7-gmp and php7-pecl-mailparse.
12.04.21: - Add support for vultr dns validation.
14.03.21: - Add support for directadmin dns validation.
12.02.21: - Clean up rust/cargo cache, which ballooned the image size in the last couple of builds.
10.02.21: - Fix aliyun, domeneshop, inwx and transip dns confs for existing users.
09.02.21: - Rebasing to alpine 3.13. Add nginx mods brotli and dav-ext. Remove nginx mods lua and lua-upstream (due to regression over the last couple of years).
26.01.21: - Add support for hetzner dns validation.
20.01.21: - Add check for ZeroSSL EAB retrieval.
08.01.21: - Add support for getting certs from ZeroSSL via optional CERTPROVIDER env var. Update aliyun, domeneshop, inwx and transip dns plugins with the new plugin names. Hide donoteditthisfile.conf because users were editing it despite its name. Suppress harmless error when no proxy confs are enabled.
03.01.21: - Existing users should update: /config/nginx/site-confs/default.conf - Add helper pages to aid troubleshooting
10.12.20: - Add support for njalla dns validation
09.12.20: - Check for template/conf updates and notify in the log. Add support for gehirn and sakuracloud dns validation.
01.11.20: - Add support for netcup dns validation
29.10.20: - Existing users should update: ssl.conf - Add frame-ancestors to Content-Security-Policy.
04.10.20: - Existing users should update: nginx.conf, proxy.conf, and ssl.conf - Minor cleanups and reordering.
20.09.20: - Existing users should update: nginx.conf - Added geoip2 configs. Added MAXMINDDB_LICENSE_KEY variable to readme.
08.09.20: - Add php7-xsl.
01.09.20: - Existing users should update: nginx.conf, proxy.conf, and various proxy samples - Global websockets across all configs.
03.08.20: - Initial release.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Getting Started

Competitor Comparisons

Pros of nginx-proxy

Cons of nginx-proxy

Code Comparison

Summary

Pros of nginx-proxy-manager

Cons of nginx-proxy-manager

Code Comparison

Pros of Traefik

Cons of Traefik

Code Comparison

Pros of Caddy

Cons of Caddy

Code Comparison

Convert designs to code with AI

README

Supported Architectures

Application Setup

Validation and initial setup

Certbot Plugins

Security and password protection

Site config and reverse proxy

Using certs in other containers

Using fail2ban

Updating configs

Migration from the old linuxserver/letsencrypt image

Usage

docker-compose (recommended, click here for more info)

docker cli (click here for more info)

Parameters

Portainer notice

Environment variables from files (Docker secrets)

Umask for running applications

User / Group Identifiers

Docker Mods

Support Info

Updating Info

Via Docker Compose

Via Docker Run

Image Update Notifications - Diun (Docker Image Update Notifier)

Building locally

Versions

Top Related Projects

Convert designs to code with AI

Migration from the old `linuxserver/letsencrypt` image