Compliance and Security

Security considerations and compliance frameworks for CARTO Self-Hosted

Overview

CARTO Self-Hosted is designed for organizations with strict security and compliance requirements. Because the entire platform runs within your own infrastructure, you retain full control over your data, network boundaries, and security posture.

Data residency

With CARTO Self-Hosted, your spatial data, metadata database, and object storage buckets remain within your own infrastructure. Data residency is determined by where you deploy your Kubernetes cluster and provision your dependent services (database, object storage).

• Choose the cloud region and provider that meets your regulatory requirements

• Your maps, datasets, and user data are stored exclusively in the services you provision and control

• CARTO services communicate with CARTO's infrastructure for operational purposes such as license validation, product telemetry, and updates. No spatial data or database contents are included in these communications

• License validation communicates with auth.carto.com, exchanging only the domain name and license key

Encryption

At rest

Encryption at rest is managed at the infrastructure level and is your responsibility to configure:

• Object storage: enable server-side encryption on your GCS/S3/Azure Blob buckets (AES-256 by default on all major providers)

• Metadata database: enable storage encryption on your Cloud SQL/RDS/Azure Database for PostgreSQL instance

• Kubernetes node disks: enable disk encryption on your cluster nodes via your cloud provider

In transit

Traffic entering CARTO from end users is encrypted using TLS, with the minimum version determined by your load balancer configuration. See End-to-End TLS for configuration details.

Audit logging

CARTO Self-Hosted provides audit logging at several layers. To answer "who did what" inside the platform, start with Activity Data — CARTO's application-level audit log. The infrastructure logs below sit underneath it and capture lower-level access and platform events.

• Activity Data (application-level audit log) — records user and organization activity within CARTO: who accessed what, and which actions were performed. This is the primary layer for answering "who did what." See Activity Data in the user manual and Tracking Activity Data from Public Maps.

• Kubernetes audit logs — capture all API server activity; configure via your cluster's audit policy

• Cloud provider logs — database query logs, storage access logs, and load balancer access logs available through your cloud provider's logging service (Cloud Logging, CloudWatch, Azure Monitor)

• Application logs — CARTO services emit logs to stdout/stderr; collect and forward them using your preferred log aggregation stack (Fluentd, Datadog, Splunk, etc.)

Network isolation

CARTO Self-Hosted is designed to run within a private network. Recommended isolation practices:

• Deploy your Kubernetes cluster in a private VPC with no public node IPs

• Expose only the ingress controller (load balancer) to the internet on port 443

• Restrict database access to the CARTO namespace CIDR only — no public database endpoints

• Use VPC peering or Private Service Connect to connect to managed database and cache services without traversing the public internet

• Apply Kubernetes NetworkPolicies to limit pod-to-pod traffic to what is required

Compliance frameworks

CARTO Self-Hosted's architecture is designed to support your compliance requirements. Since all data and infrastructure remain under your control, you can configure your deployment to align with your organization's specific framework obligations.

For guidance on compliance requirements, contact [e-mail].