> For the complete documentation index, see [llms.txt](https://docs.carto.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.carto.com/carto-self-hosted/getting-started/glossary.md). # Glossary This page defines the terms used throughout the CARTO Self-Hosted documentation. The **Operations and lifecycle** section in particular clarifies words that are easy to confuse — such as *update*, *upgrade*, *backup*, *restore*, and *key rotation*. ## Platform and components | Term | Definition | | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CARTO Self-Hosted** | A deployment of the full CARTO platform on customer-managed infrastructure. | | **Admin Console** | The web-based management interface provided by Kots for configuring and managing CARTO Self-Hosted deployments. | | [**Analytics Toolbox**](/data-and-analysis/analytics-toolbox-overview.md) | CARTO's set of spatial analysis functions that run natively inside your data warehouse. | | [**CARTO Data Warehouse**](/carto-user-manual/connections/carto-data-warehouse.md) | An optional built-in data warehouse provided by CARTO for users who don't have their own. | | [**Data warehouse**](/carto-user-manual/connections.md) | The external analytical database (BigQuery, Snowflake, Redshift, Databricks, etc.) where your spatial data lives. It is managed by you and sits **outside** the CARTO backup scope. | | **Metadata database** | The PostgreSQL database CARTO uses to store platform metadata — maps, workflows, connections, users, and organizations. Restore-critical. | | **In-memory cache** | The Valkey (Redis-compatible) cache used by CARTO for sessions and transient data. Ephemeral — not part of a backup. | | **Object storage** | The buckets CARTO uses for file storage. A deployment has an **assets** bucket and a **temp** bucket. | | **Assets bucket** | Object storage holding persistent files that cannot be regenerated on demand — map thumbnails and custom markers. **Should be backed up.** | | **Temp bucket** | Object storage holding ephemeral, regenerable data (e.g. import staging). Does **not** need backing up. | | **Support bundle** | A diagnostic archive generated by Kots or the support-bundle CLI tool, used by CARTO Support for troubleshooting. | ## Deployment and configuration | Term | Definition | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Helm** | The Kubernetes package manager used for the Orchestrated container (Advanced) deployment method. | | **Kots** | Kubernetes Off-The-Shelf — a tool that simplifies deploying and managing CARTO Self-Hosted with a built-in Admin Console. Used by the Single VM and Standard Orchestrated deployment methods. | | **customizations.yaml** | The Helm values override file used to configure a CARTO Self-Hosted Helm deployment. | | **Configuration** | The restore-critical settings of an installation: the Kots config, or — for Helm — the `carto-values.yaml`, `carto-secrets.yaml`, and `customizations.yaml` files. See [How Configuration Works](/carto-self-hosted/concepts/configuration-management.md). | | **Release version** | A dated CARTO Self-Hosted version identifier (for example `2026.5.14`). Moving between release versions is an *update* / *upgrade*. | ## Operations and lifecycle {% hint style="warning" %} **Words that are easy to confuse.** CARTO uses *update* and *upgrade* **interchangeably** to mean "move to a newer release version." Separately, the Helm command for applying **any** change is also `helm upgrade` — so a phrase like "upgrade your installation to apply the changes" can refer to re-applying configuration **without** changing the version. The table below keeps the two ideas distinct: changing the **version** (*update / upgrade*) vs. applying a **configuration** change (*apply changes*). {% endhint %} | Term | Definition | | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Update** *(also: **upgrade**)* | Moving your installation from one release version to a newer one. This automatically runs forward-only database schema migrations. Always create a backup first. See [Update to a new version](/carto-self-hosted/operations/upgrades/updates.md). | | **Apply changes** *(reconfigure)* | Re-deploying an installation to apply a **configuration** change (new bucket keys, SSO settings, etc.) **without** changing the release version. On Helm this also uses the `helm upgrade` command, which is why the word "upgrade" sometimes appears here even though no version change is involved. See [Apply configuration changes](/carto-self-hosted/operations/upgrades/apply-configuration-changes.md). | | **Rollback / Downgrade** | Reverting to an earlier release version. **Not supported** — schema migrations are forward-only. To recover a previous state you must restore a backup taken *before* the update and reinstall the matching version. | | **Backup** | A copy of the two restore-critical elements — your configuration and the contents of the metadata database — plus the assets bucket. It lets you rebuild an identical deployment. See [Backups & Restore](/carto-self-hosted/operations/backup-and-restore/backups.md). | | **Restore** | Rebuilding an installation from a backup: reapplying the saved configuration and loading the metadata database contents back in. | | **Key rotation** | Replacing secrets and credentials — custom bucket keys, BigQuery OAuth connections, Google basemaps keys, and LDS API keys — and then re-applying the configuration. Distinct from updates and backups. See [Rotating keys](/carto-self-hosted/operations/upgrades/rotating-keys.md). | | **Support lifecycle** | CARTO support is available only for Self-Hosted versions **released within the past 12 months**, which is why regular updates are recommended. | | **Uninstall** | Removing a CARTO Self-Hosted installation. See [Uninstall](/carto-self-hosted/operations/licensing-and-admin/uninstall.md). | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.carto.com/carto-self-hosted/getting-started/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.