Short answer: Keep public URLs, encryption settings, database values, and execution settings in a documented environment layer. Change one group at a time. Restart n8n and verify the effective configuration.

Which variables should be treated as deployment-critical?

The encryption key protects stored credentials. Keep it stable for an existing instance. Public and webhook URLs affect links and incoming requests. Database variables select workflow and execution storage.

Keep these values outside the workflow editor. Store them in the deployment secret store or protected environment file. Do not commit them to a repository or paste them into issue comments.

How should environment changes be applied?

Record variable names in a change note. Never record secret values. Apply one related change at a time. Restart the service. Check the startup log before testing a workflow.

Use the same names in local, staging, and production when possible. Different names hide deployment differences. They also make a copied compose file harder to review.

What should be checked after a restart?

Open the editor and confirm the public address. Test one webhook with a safe payload. Run a small workflow that reads a credential. Check that execution storage and binary data behave as expected.

For a URL, confirm the scheme, host, and path. A correct-looking value can still make a webhook unreachable when the proxy uses another public address.

Where should the reference live?

Keep a redacted variable table with purpose, owner, default behavior, and restart impact. Link each entry to the relevant n8n documentation. The self-hosted operations guide covers the release and backup checks around these settings.

For a full container stack, compare the Docker variable reference with your deployment file before upgrading.