Be clear about this before you install
There is nobody to call at three in the morning
That is the first row on the comparison page and the one this project loses worst. It is worth saying plainly on its own page rather than burying it.
What that actually means
The commercial products come with support and a service level agreement: a number to ring and somebody contractually obliged to answer within a stated time. NGINX Plus has F5 behind it. Kemp sells tiered cover with 24 by 7 on the higher plans. HAProxy do not tier at all, and your ticket goes straight to an engineer with a thirty minute target on a critical issue.
This is a project on a box. When it breaks, the person fixing it is you.
If that matters where you work
It matters more than every feature on this site put together, and no amount of good design changes it. Buy one of the commercial products. The pricing page has the numbers, and this project is not trying to talk you out of it.
What there is instead
| Instead of | There is |
|---|---|
| A support portal | 326 searchable answers, written from the questions people actually ask |
| A knowledge base | 44 feature pages and 12 worked guides |
| A manual | A 41 chapter user guide in the repository, written for somebody handed two servers |
| An engineer on the phone | The source, which is deliberately small enough to read, and logs that say what happened |
| An SLA | Nothing. That is the honest answer. |
Working out a problem yourself
Most problems fall into a small number of shapes, and the troubleshooting section covers them in rough order of how often they happen. The four commands worth knowing:
# The management screen's log
sudo docker logs nginx-fleet-manager
# The agent's log
sudo journalctl -u nginx-mgr-agent -n 50
# nginx's error log
sudo tail -50 /var/log/nginx/error.log
# Whether nginx is happy at all
sudo nginx -t
Two things catch people out often enough to mention here rather than only in the how to section:
- Buttons that write are grayed out. You are on the standby. Changes are made on the active node.
- Nothing happened after you changed something. You saved it and did not apply it. The banner at the top of every page says when something is saved and not live.
Making a report that gets fixed
The manager log and what you were doing at the time is nearly always enough for somebody to work out what happened. Add these and it usually becomes obvious:
- Which node you were on, and whether it was active or standby.
- The config version from the dashboard.
- The nginx version and module count from the same panel, for both nodes.
- What you expected to happen, and what happened instead.
- Whether it happens every time or only sometimes.
Take the secrets out first
Logs can contain hostnames, addresses and, if you are unlucky, something you would rather not publish. Read what you are about to paste. Never include the contents of a .env file or a backup archive.
Reporting a security problem
Please report it privately rather than opening a public issue, and give it a reasonable amount of time before publishing. There is no bounty program. There is somebody who will read what you send and fix it.
If you want somebody to be responsible
Two honest options.
- Buy a commercial product. That is what the support row on the comparison page is telling you.
- Make somebody internally responsible for it, with time set aside to own the upgrades and to have run the failover test at least once. That is the version of support that free software actually has, and being honest with yourself about whether you will do it is the whole decision.