Maintenance status

[mike2307]

!!!PLEASE READ!!!

Questions

If you have a question, DO NOT SUBMIT a new issue. Please ask the question on the Q&A Group: https://groups.google.com/forum/#!forum/nginx-proxy
Well, isn't accessible any more...

Is this repository abandoned? If yes: is there any successor project? I don't want to run outdated software for handling secure communication...

[buekera]

Seems like this is abandoned, yes. I have difficulties getting this working but I'm not even asking for help I think.
Did anyone make a fork and is working actively on this?

[thaJeztah]

ping @jwilder PTAL

[ehough]

FWIW I replaced nginx-proxy with Traefik. It was pretty easy to setup, met all of my requirements, and doesn't have any of the bugs I was experiencing with this app. Might be worth taking a look.

[iamjaredwalters]

@ehough How do you handle local dev with Traefik given it requires a real domain name?

[buchdag]

@jwilder as the current maintainer of jrcs/docker-letsencrypt-nginx-proxy-companion, I'm getting more and more concerned by the apparent abandonment of this project and the lack of feedback on your commitment to it.

jwilder/nginx-proxy is not some barely used project but a 11k+ stars one with 172 millions pulls on Dockerhub.

I'm not saying that you owe the users of this project your time and/or efforts (not at all), but I think that some update on what you intend to do with it is required.

edit : the same goes for jwilder/docker-gen

[ehough]

@iamjaredwalters I don't personally use Traefik for local dev, but perhaps you could just add an entry into your host machine's /etc/host to get things started?

In case it's helpful, here's the docker-compose.yml for my Traefik server, and here's a sample of a backend service.

[thomasd3]

yes, it would be nice to get some statement from Jason; it is a super useful project but I would understand if he wanted to move on and do something else.. it would just be great to know what's up.

[thaJeztah]

perhaps some trusted contributors can be assigned as maintainers by @jwilder, and give merge permissions.

before doing so, it's probably good to define a clear scope of the project (feature creep is always a risk, and it's good to set clear boundaries as to what the project is intended to do, and what is out of scope for the project)

[tbpoetke]

Well, I'm just a User , not a developer, but I see alot of pull requests here, and jwilder is not answering anymore here and at docker-gen, so why not creating a fork and put more maintainer into the fork?

[jwilder]

This project is not abandoned, but I am not actively developing it currently. I do merge small maintenance and security fixes as quickly as I can. Bug fixes for existing features is fair game, but I could really use help with tests, documentation and external verification of changes by others.

My hesitation with new features is mainly about ensuring backwards compatibility, keeping the project easy to use and keeping it stable. It is amazing how many people use this project considering how it started. It was never really intended to support the myriad of features that have been proposed. In fact, the framework it relies on (go templates/docker-gen) is getting increasingly difficult to maintain with every new option added. I had started to refactor it to make it easier to extend, but didn’t have time to really complete it.

I’m open to suggestions and ways to improve things though.

[thaJeztah]

Would replacing it with (e.g) https://github.com/hairyhenderson/gomplate be a solution? (not sure if it supports all features that are needed) /cc @hairyhenderson

[hairyhenderson]

@thaJeztah thanks for the mention! gomplate could be useful from a templating perspective, and I've definitely used gomplate to generate nginx config plenty in the past, but not being that familiar with this project I'm not sure either where the gaps are...

[thomasd3]

@jwilder many of us rely on you ;)

[tbpoetke]

This project is not abandoned, but I am not actively developing it currently. I do merge small maintenance and security fixes as quickly as I can. Bug fixes for existing features is fair game, but I could really use help with tests, documentation and external verification of changes by others.

My hesitation with new features is mainly about ensuring backwards compatibility, keeping the project easy to use and keeping it stable. It is amazing how many people use this project considering how it started. It was never really intended to support the myriad of features that have been proposed. In fact, the framework it relies on (go templates/docker-gen) is getting increasingly difficult to maintain with every new option added. I had started to refactor it to make it easier to extend, but didn’t have time to really complete it.

I’m open to suggestions and ways to improve things though.

Thank you very much for your work and your answer! I love this project, just have problems with the not starting docker-gen, and we dont see an update there for a long time :(
Keep it up with your good work.

Cheers

[ngoonee]

@jwilder the suggestion by @thaJeztah on adding maintainers (assuming volunteers can be found) deserves consideration. You owe no one anything beyond what you yourself are able to commit, but the sheer adoption rate of this project suggests that increasing the bus factor would be beneficial.

[buchdag]

@tkw1536 will do

Sorry folks, not much update last week. This has been taken care of since my last reply :

if possible we're going to get authorisation from Jason to push to jwilder/nginx-proxy on Dockerhub

So the same images are now pushed to both jwilder/nginx-proxy and nginxproxy/nginx-proxy.

I'll let you know how

the nginx-proxy org is going to contact Jason Wilder regarding ownership of jwilder/docker-gen. Ideally we'd like it transferred to the org so we can maintain it, but if this isn't possible we'll fork the project under the nginx-proxy org.

goes as soon as I have update on it.

[buchdag]

Quick update:

the nginx-proxy org is going to contact Jason Wilder regarding ownership of jwilder/docker-gen. Ideally we'd like it transferred to the org so we can maintain it, but if this isn't possible we'll fork the project under the nginx-proxy org.

This is still ongoing.

I'm currently blocked on docker-gen update / CI fix by nginx-proxy/docker-gen#349

[kamermans]

Hi all, great to see some life breathed back into this project @buchdag and @jwilder! I don't have a ton of extra time, but I'm happy to chat if you think there is a way I might be useful with the transition and/or in the new org. I have been running a private fork of this project for many years now and it sits in front of more than a hundred production containers in my environment.

[buchdag]

@kamermans I'm happy to see that you're still around and a strong user of nginx-proxy 👍

I'll gladly accept help if you have some spare time to put into mulching through those ~ 550 issues and ~ 80 PR (or into contributing to nginx-proxy/acme-companion). I'm still not fixed on how I'll proceed but obviously some triage will be needed.

@tkw1536 you'll be welcome too by the way.

As stated by @thaJeztah a while ago

before doing so, it's probably good to define a clear scope of the project (feature creep is always a risk, and it's good to set clear boundaries as to what the project is intended to do, and what is out of scope for the project)

I can't agree more.

@jwilder replied that

My hesitation with new features is mainly about ensuring backwards compatibility, keeping the project easy to use and keeping it stable.

Agreed too, I don't think the goal here would be to compete with something like Traefik and answer each and everyone specific need. This project is mostly liked (imho) for its ease of use and stability, so we should try to keep it that way. There are however a few "big" features that have proved to be highly sought after by the community (the biggest one being path based routing, and It deserves a discussion of its own).

Other than that I think that some focus should be given to tests and documentation. Sure they're not the most glamorous thing but having as many feature properly tested as possible and all of them documented with a clear, easy to navigate doc is one of the pillar of a maintainable project in my eyes.

In this regard:

• I'm pretty sure some features aren't tested at all and it will take some time to find which one.
• I'm personally not fond of the one page doc format.

Another area of interest would be the mutual integration of ningx-proxy and the acme-companion. I now that we have some room for improvement here.

Do you have any feedback or suggested directions from the experience you collected running you rather large nginx-proxy production workload ?

[kamermans]

I agree with your comments and I think that the scope is really important here. There are PRs and issues for every imaginable feature, but if we actually added every imaginable feature it would probably be hard to use and impossible to maintain.

I see nginx-proxy as an easy-to-use ingress controller, just like the role Traefik plays in Kubernetes (which I also use).
In my environment, we have a modified nginx-proxy to:

1. Include Brotli by default and enable it and GZIP.
2. Increase the max upload size.
3. Mount and translate SSL certificates from our internal format to that of nginx-proxy.

This makes it very easy to get a web project up-and-running - we simply deploy the SSL certs and an instance of nginx-proxy and everything on the host has SSL, etc.

Personally, I think it makes sense to merge the LetsEncrypt companion into the main repo since HTTPS support is critical now. Also, it's fairly easy to contribute something to the main repo that breaks the LetsEncrypt companion. Merging these allows us to test compatibility via an integration test in the main repo.

In the past I have forked nginx-proxy in order to manually compile OpenSSL (and other SSL libs) in order to mitigate security risks and add support for new protocols like TLS 1.3. We should consider tagging issues/PRs that have a security concern related to them and prioritize them (there shouldn't be very many). HTTP/3 will present a similar problem (I'd evaluate integrating nginx-quic or Cloudflare Quiche for HTTP/3 support).

[DannyBen]

I see nginx-proxy as an easy-to-use ingress controller.

I totally agree that feature creep should be avoided. Simplicity is a key attribute in projects like this (especially given its spotty maintenance record). I would even go as far as to say that perhaps some features or complexities should be removed, in order to simplify future development and maintenance.

You mentioned LetsEncrypt - I for one, hope that this feature stays out of the nginx-proxy repo completely. Some people have no use for it, or choose to handle SSL in different ways or different layers.

Of course, if adding it is simple, and will not complicate the codebase or its maintenance, my point might be moot - but I am assuming it is not the case.

[kamermans]

Ah, great point @DannyBen I don't use the LetsEncrypt companion at all, so my point wasn't that we should enable it by default (I don't think most people would want it anyway), just that the code should not live in a different repo because it makes it harder to test and for contributors to foresee compatibility issues.

Since @buchdag is the primary maintainer going forward, and he is also the author of the LetsEncrypt companion, I figured it would make maintenance and testing more easy. That said, I really don't have a strong opinion either way since I don't use it.

[edit] After re-reading your comment, I think I might have missed your point. We already have LetsEncrypt support and are going to be maintaining it anyway, so there's no new development here, just removing the separation of the two repos.

[buchdag]

Sorry for the month long delay since the last update :

the nginx-proxy org is going to contact Jason Wilder regarding ownership of jwilder/docker-gen. Ideally we'd like it transferred to the org so we can maintain it, but if this isn't possible we'll fork the project under the nginx-proxy org.

The repository has been transferred and is now named nginx-proxy/docker-gen

I'll answer to the points raised by @kamermans and @DannyBen asap

[buchdag]

@AndriynomeD that's not the topic of this issue. Could you please open a discussion instead ?

[psy0rz]

Sorry for the month long delay since the last update :

the nginx-proxy org is going to contact Jason Wilder regarding ownership of jwilder/docker-gen. Ideally we'd like it transferred to the org so we can maintain it, but if this isn't possible we'll fork the project under the nginx-proxy org.

The repository has been transferred and is now named nginx-proxy/docker-gen

I'll answer to the points raised by @kamermans and @DannyBen asap

great! so this scary issue can be closed now? :)

[rodrigoaguilera]

There is new maintainers but I feel the project can receive a bit more love.
I see some folks maintaining forks with features that can be interesting for the main project. An example:
#2050

Maybe is time to welcome more maintainers trying to find the balance between keeping the project updated and the complexity of having many people taking decisions over the code.

Personally I have some features that I would like to contribute upstream to nginx-proxy but seeing that there is little chance for them to be reviewed so I don't feel very motivated to tidy them up.

[psy0rz]

ahh right ok :)

[buchdag]

Hi folks.

Sorry for the disappearance those past seven months, it's been a rough year.

I'm getting my sh*t together and I plan to get back to the maintenance of this project (and yes it'll mean onboarding more people).

[rhansen]

I'd be happy to help with the maintenance burden @buchdag.