Applying changes

Press Apply config. Everything you have saved is built into a full configuration, staged on every node, tested with each node's own nginx binary, and only then swapped in.

If any node refuses, every node keeps what it had and you are told exactly what was wrong.

You saved it and did not apply it. Saving changes nothing for your visitors, which is the point: you can save as often as you like and apply when you are ready. The banner at the top of every page says when something is saved and not live.

The Changes page shows what is saved and not yet live, and what it changes. Read it before applying, particularly if somebody else has been working on the same thing, because you are about to make their changes live along with your own.

Changes page, look at the history, and put an earlier version back. It applies the same way any other change is applied: built, checked, staged on every node, tested, then swapped in. So a rollback cannot break the fleet either.

The most common one is a pool with no healthy servers in it, which means the site would serve errors. A warning is not a refusal: sometimes serving an error page from a pool you are about to fill is exactly what you meant to do.

It does not block the change. The change goes into that node's queue and is replayed when it comes back, so it catches up rather than quietly drifting.

No. An nginx reload is graceful: the master starts new workers with the new config, hands them the new connections, and lets the old workers finish what they were doing before they stop. Nobody is disconnected and no request is dropped.

The one thing to know is that very long lived connections, such as WebSockets, keep old workers around until they close.