Every server-wide setting this install runs on, in one searchable place. Change a value for the whole server, or override it for a single project, then review the diff before it is written.
What the Settings page is
Settings is the server's own configuration, read and written from the dashboard. It holds the values the server runs on: ingestion limits, session rules, password policy, log verbosity, and one section per plugin that registers settings of its own.
The page lives under Manage, in the Operations section, at /manage/settings, and it is admin only. The left rail groups sections into Core and Plugins. Core is ordered rather than alphabetical, running API, Frontend, Security, Logs, Tracking, then Sharing, and a core section the server does not report simply does not appear. Plugins holds a section for each plugin that registers settings of its own.
Inside a section, related keys sit in named groups. The API section, for example, separates Limits from Geolocation, Write batching, and Read caching. A section with no groups defined renders as one flat list.
Settings has two scopes. Server scope is the configuration the whole install runs on. Project scope is the override layer of a single project, and it lists only the settings a project is allowed to override. The scope you are in rides in the URL, so a link to a setting carries its scope with it.
Saving sends only the keys you changed, so nothing you did not touch is rewritten, and the page states that a change applies within about ten seconds with no restart.
How a value resolves
Every setting has up to three layers behind it, read in one order: the project's override first, then the server value, then the default the plugin registered at install time. The first layer that has a value wins.
That order is why the same key can read differently in the two scopes. Server scope shows the value the install runs on. Project scope shows what that one project actually gets, which is the override when it has set one and the inherited server value when it has not. Each row in project scope carries a badge saying which of the two it is.
Reset means different things at each scope, and the row label says which. In server scope, Reset puts the key back to its registration default. In project scope, the action reads Use server value, and it removes the override so the project follows the server again.
A key whose default Countly does not know offers no reset at all. It is never flagged as non-default and never gets a reset button, because the alternative is offering to reset it to a guess.
Some settings have no curated description. A setting the server reports but this page does not describe still appears, with a control matched to the type of its stored value. It just arrives without a friendly label, description, or unit.
Use Cases
Change a setting for the whole server
Raise a limit, tighten a policy, or turn a behavior on for the whole install.
- Open Manage, then Operations, then Settings. Global admins land in Server scope, which the scope card at the top confirms.
- Pick the section in the left rail, or type part of the name into the search box above it if you are not sure which section owns the key.
- Read the colored dots next to the setting's stored key before you touch it. They warn that the key has a known effect on performance, on how incoming data is processed, or on what the dashboard can display.
- Edit the control. The row marks itself as modified and the unsaved-changes bar appears at the bottom of the page.
- Choose Review and save, read the list of old and new values, and save from the dialog.
If the setting is one a project may override, a project that has already overridden it keeps its own value and will not see yours. SDK behavior settings are the exception: turned off for the server, they are off for every project, whatever the project's own value.
Override a setting for one project
One project needs a different limit from the rest of the install, and you do not want to move the server value for everyone.
- Open Settings and switch the scope card from Server to Project. The picker beside it chooses which project you are editing.
- Read the left rail. Project scope lists only the sections a project is allowed to override, so it is shorter than the server list.
- Find the row and read its badge. Inherited means the project follows the server value; Project override means it has already set its own.
- Edit the control. The badge flips to Project override and the row shows the server value it is now hiding.
- Review and save. The dialog names the project so a save in the wrong scope is hard to make by accident.
To undo it later, use the row's Use server value action. That removes the override rather than writing the server's number into the project, so the project starts following the server again, including future changes to it.
From Server scope, a global admin sees the other direction. A row that some project has overridden carries a badge counting them, and opening it lists those projects. Picking one jumps straight into that project's scope at that row.
Find a setting you cannot name
You know what you want to change, but not which section keeps it.
- Type into the search box at the top of the left rail. Search matches the stored key, the label, the description, and the section, so
event_limit, "events", and "API" all reach the same row. - Read the results card. It lists every match across every section as an editable row, each captioned with the section it belongs to.
- Narrow further with the filter icon beside the search box. State covers Modified and Non-default in server scope, and Modified and Overridden in project scope. Impact covers the three warning tags.
- Edit in place if that is all you came for. Results rows are live controls, not a preview.
- Click the section caption on a row, whose tooltip reads Open in its section, when you want the surrounding context. It clears the search and flashes the row where it lives.
Filters combine the way you would expect. Picking two values inside one facet widens the result, and picking values in both facets narrows it: a row must match something in State and something in Impact to survive.
The rail counts with you. While a search or a filter is active, each section shows how many of its settings match, and sections with no matches drop out of the list.
Review changes before they are written
See exactly what is about to be written before it is written.
- Make your edits. Nothing reaches the server while you do. The bar at the bottom of the page counts how many settings changed and how many sections they are spread across.
- Choose Review and save. The dialog lists every pending change as its key, its label, and the old value next to the new one.
- Read the long ones carefully. A multi-line value such as a headers block or a robots file gets a word-level diff instead, with removals and additions marked inline.
- Drop any change you have thought better of with the revert arrow on its row. Reverting the last one closes the dialog, because there is nothing left to review.
- Save from the dialog. Discard is there too, and it throws away every pending change at once.
Drafts are kept per scope. Switching from Server to Project and back does not lose what you had typed in either one, and the bar always describes the scope you are looking at.
Secrets never appear in the review. A password or key row shows a masked value on both sides of the change, so the dialog confirms that a credential moved without putting it on screen.
FAQs
Do I have to restart the server after saving?
No. The scope caption on the page states it: a change applies within about ten seconds, with no restart.
Why can I only see Project scope?
Writing the server configuration is a global-admin action, so the scope switch is not rendered for anyone else and the page opens on a project instead. A project admin can still override the settings their projects are allowed to override.
Why is a value shown as dots?
It is a credential. Password-type rows and any setting declared sensitive are masked on the page and on both sides of the review dialog, so a change can be confirmed without the value appearing on screen.
What does the Non-default filter mean?
It lists settings whose current value differs from the one the plugin registered at install time. It measures against your unsaved edits too, so resetting a key to its default drops it out of the filter straight away.
Is a settings change recorded anywhere?
Yes. Saving writes an entry to Audit Logs recording that the configuration changed, with secret values masked on both the before and the after side so credentials do not accumulate in the audit trail.
I changed a server value and one project did not follow.
That project has an override on the key. Open the row in Server scope: if any project overrides it, the row carries a badge counting them, and opening the badge lists those projects. Picking one jumps into that project's scope at that row.
Where are push credentials?
Under Manage, then General, then Projects. They are a property of the project, not an override of a server setting, so they are not part of this page's project scope.
Where do I set up sign-in with LDAP, Okta or Amazon Cognito?
In the provider's own section, under Plugins in the list of sections on the left. The section appears only after the provider is enabled on the Features page, under Manage, then General. Open ID Connect and Active Directory sign-in have their own sections there too.