docker-nginx

Official NGINX Dockerfiles

Systems & Infrastructure DevOps & Cloud

Explore on GitHub Read Hacker News discussions

2Distinct people

3Mentions

0Explicit recommenders

3.5KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Official NGINX Dockerfiles

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year3 dated mentions

Observed mentions: 2019-03-17 09:26:09 UTC to 2022-09-23 14:10:17 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	2	2
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1

What Hacker News says

3 sources

e12e·Sep 23, 2022

It's a bit odd to use a custom docker image, rather than the one maintained by nginx Inc though: https://github.com/signalapp/Signal-TLS-Proxy/blob/main/ngin... Vs https://github.com/nginxinc/docker-nginx For one, this is 5 versions behind (1.18 vs 1.23). In general seems caddy or haproxy might be a better fit - but nginx is a perfectly fine choice I suppose.

In Signal TLS Proxy

ricardbejarano·Mar 17, 2019

OP and maintainer of the image here. I understand your concerns. I would have them too. To be fair, I tried pushing these changes to the official NGINX image, but they weren't accepted because I'm using a multi-stage build, which are not allowed to official images for a series of reasons. I mostly disagree with those reasons, but I don't own the Docker Hub. Here's the PR: https://github.com/nginxinc/docker-nginx/pull/310 As for traceability, we've had some discussion over at Lobsters about that. I believe you can do it from outside the container, and avoid bloat that will only get used in 1% of the cases. About reproducibility, my CI process for this image uses GitHub and the Docker Hub, I don't build and push the images myself (which I consider a very big red flag in A LOT of images, even official ones), so it must be reproducible as the

Read the rest

Docker Hub must be able to build it. I've responded to another user about maintenance. TL;DR is: I use it, so I must keep it up-to-date, usually in less than 24h of the release of a new patch. If for whatever reason I stop using it, upgrading is just changing two lines in the Dockerfiles, so it's not tiring. But if for whatever reason I can't maintain it anymore... This is an inherent problem of volunteer maintained open source software. I might have convinced you, or not. Again, I'd have the same concerns as you do, it's fair.

In Show HN: Small, secure Nginx Docker image

ricardbejarano·Mar 17, 2019

> Will this git repo still be updated then? Will the user remember to pull latest version and regenerate latest image? I use this image myself, so I have an incentive to keep it up-to-date and secure. Usually, I upgrade in less than 24h from the release of a new patch. Based on the system I use to get notified of upgrades such as NGINX's, I could even automate the upgrades to get triggered as soon as the patch is released, but I don't like the idea of commiting without human review. But I see your point. There's no guarantees. What happens if I get tired (highly doubt so), or, what happens if I die? These problem is inherent with open source software maintained by volunteers. I tried pushing my changes to the official NGINX image, but they can't be merged because I'm using multi-stage builds, which for some reason are not allowed for offi

Read the rest

cial images. Here's the PR: https://github.com/nginxinc/docker-nginx/pull/310 Multi-stage builds is the core of what makes this image great, so I can't renounce to it. I think we can also agree that, because Docker is very new, we cannot guarantee that it's as secure as other well-tested technologies, but if Docker/Kubernetes were to be secure, it let's admins take security to another level. You could have 2 stacks, with all their components, running on the same metal, but isolated at the network level. Doing this is possible without containers, sure, but it takes less than 5 lines of YAML in Docker Swarm. Exciting time in the world right now. Exciting time...

In Show HN: Small, secure Nginx Docker image