--- title: "Settings" description: "The settings a server stores, what each one does, where its value can come from, and how to change it." --- > Documentation Index > Fetch the complete documentation index at: https://commentware.com/llms.txt > Use this file to discover all available pages before exploring further. # Settings A setting is a named value that changes what a server does, set with the [`settings`](/docs/server/commands/#settings) command. This page lists version 0.17.0 of the server, the newest release. An entry that names no version it was added in was in version 0.13.0. [`settings list`](/docs/server/commands/#settings-list) prints every setting your version has, its value, and **where that value came from**. The command acts on the server whose database its config file names. Learn more about [how a command finds its server](/docs/concepts/config-file/). The server's name is not a setting, because it is needed before there is a database to read: it is the [`name`](/docs/server/config/#name) key in `commentware.config.json`. ## Where a value comes from **A value stored with `settings set` wins, then the environment variable, then the shipped default.** A variable set to the empty string counts as unset. **The variable `settings list` reads is the one in the shell you run it from.** A server started elsewhere runs on the variables it started with. The unit [`service install`](/docs/server/commands/#service-install) writes keeps the variables of the shell that installed it. So `list` can name the shipped default while the server runs on a variable its unit holds, or name a variable your shell has that the server never saw. A stored value is the same for both, and the server reads it each time it uses it. A changed variable reaches a server you started by hand when you start it again from a shell that has it. It reaches a service only when you run `service uninstall` and then `service install` from such a shell; `restart` keeps the unit as it is. ## How a value is changed [`settings set`](/docs/server/commands/#settings-set) stores a value and [`settings unset`](/docs/server/commands/#settings-unset) removes it, so the variable or the default applies again: ```sh commentware settings set screenshots off commentware settings unset screenshots ``` `set` validates before it writes, so a value the server cannot use is refused when you type it rather than when something reads it. ## `hub-origin` **Type:** an `http` or `https` origin · **Default:** the hub origin the server ships with · **Environment variable:** `PUBLIC_HUB_ORIGIN` Origin of the hub. Connection strings are built on it, and so are the links of a server whose own address is loopback. Any other server builds the links it hands an agent, to a comment or to a document, on its own address: its `publicOrigin`, or else the address it binds. A server bound to every interface with no `publicOrigin` has `localhost` as its own address, so its links are built on the hub. Learn more about [which site serves a comment link](/docs/concepts/comment-links/#which-site-serves-it). A server that belongs to a hub you host needs this set to that hub, or the connection strings it prints lead to the hub it ships with. A server set up by an [install command](/docs/concepts/install/#what-a-run-installs-and-updates) from a hub other than the one it ships with already uses that hub: the `commentware` command the installer writes sets `PUBLIC_HUB_ORIGIN` to it when the variable is unset, and `settings list` then names the value `environment`, unless you stored a value. Set it on any other server: ```sh commentware settings set hub-origin https://comments.example.com ``` A [service](/docs/server/#run-it-at-login) takes its hub from the `commentware` command each time it starts, when the hub came from an install command. [`service install`](/docs/server/commands/#service-install) does not write that hub into the service, which makes it the one variable a service does not keep from the shell that installed it. To move the service to another hub, run the install command from that hub, then run [`commentware restart`](/docs/server/commands/#restart). A value stored with `settings set` wins over all of this. If `PUBLIC_HUB_ORIGIN` is set in the shell that runs `service install`, `service install` writes that value into the service, and the service keeps it. A service that a version of Commentware before 0.14.0 installed has the hub from its install command written into it, and keeps it. To make that service take its hub from the `commentware` command, stop any server you started yourself with `commentware stop`, run `commentware service uninstall`, then run `commentware service install` in a shell where `PUBLIC_HUB_ORIGIN` is not set. The extension does not use this setting. ## `screenshots` **Type:** `on` or `off` · **Default:** `on` · **Environment variable:** `COMMENTWARE_SCREENSHOTS` Whether this server accepts new screenshots. Stored ones stay readable. Off also stops the page text kept with each new comment. Learn more about [what is kept about the page](/docs/concepts/threads-and-pins/#what-is-kept-about-the-page). The [`sites screenshots`](/docs/server/commands/#sites-screenshots) command turns capture off for one site and leaves the rest: ```sh commentware sites list commentware sites screenshots app.example.com off ``` `on` there clears a site's opt-out; it does not override the server. A server with screenshots off stays off everywhere. [`sites list`](/docs/server/commands/#sites-list) marks which of the two applies to a site: `off (this site)` is turned back on with `commentware sites screenshots on`, and `off (whole server)` with `commentware settings set screenshots on`. A domain can exist in more than one [project](/docs/concepts/projects-and-sites/). When it does, the command refuses rather than guessing, and prints the projects to choose between — pass `--project`. ## `resolved-purge-days` **Type:** a whole number of days, `0` or more · **Default:** `30` · **Environment variable:** `COMMENTWARE_RESOLVED_PURGE_DAYS` A resolved thread is deleted, with its screenshots, once this many days have passed since it was resolved and, for an imported thread, since it arrived. 0 never deletes. Learn more about [the retention purge](/docs/concepts/retention/#the-retention-purge). ## `bundle-idle-days` **Type:** a whole number of days, `0` or more · **Default:** `7` · **Environment variable:** `COMMENTWARE_BUNDLE_IDLE_DAYS` A document review with no revision and no comment for this many days ends, and its comments go with it. 0 never ends one. This setting governs an experimental feature: it may change or be removed in any release. Learn more about [the retention purge](/docs/concepts/retention/#the-retention-purge).