SaaS, self-hosted, or native app? Choosing the right CARTO deployment
Once a team confirms that CARTO runs inside their data warehouse, the next question in almost every evaluation is the same: “How do we deploy it?”
There are three CARTO deployment options, and the right one depends on your security posture, your infrastructure standards, and sometimes your procurement path. This post walks through all three, with the real decision criteria we discuss with enterprises every week.
The three CARTO deployment options at a glance
| CARTO SaaS | CARTO Self-hosted | Native App in Snowflake | |
|---|---|---|---|
| Where the application runs | CARTO’s cloud, operated by us | Your own cloud tenant or data center, on a VM or Kubernetes | Inside your Snowflake account, on Snowflake Container Services |
| Where your data stays | Your own data warehouse | Your own data warehouse | Your own Snowflake account |
| Works with | BigQuery, Snowflake, Databricks, Redshift, Oracle | BigQuery, Snowflake, Databricks, Redshift, Oracle | Snowflake only |
| What you operate | Nothing. Upgrades are automatic | The application layer, with active help from our team | The Snowflake Container Services resources it runs on |
| Best for | Fastest time to first result, no infrastructure to run | Strict network boundaries: private endpoints, static IP allowlisting, in-tenant deployment | Teams whose data, security review, and cloud commitment already sit in Snowflake |
| The trade-off | The application layer is vendor-operated | More operational responsibility on your side | Tied to a single platform by design |
Option 1: CARTO SaaS
CARTO hosts and operates the platform; you connect it to your warehouse and start working the same day.
Even in SaaS, remember the architecture: your data stays in your warehouse (we covered the full data residency picture in our post on where your data lives). The SaaS component is the application layer (Builder, Workflows, the APIs), not a copy of your data. For most organizations, including many in regulated industries, SaaS plus a well-configured warehouse connection meets security review requirements.
SaaS is also warehouse-agnostic. The same hosted platform connects to Google BigQuery, Snowflake, Databricks, Amazon Redshift, and Oracle, and to more than one of them at the same time.
Choose SaaS when you want zero infrastructure to operate, automatic upgrades, and the shortest time to first result.
Option 2: CARTO Self-hosted
CARTO Self-hosted moves the application layer inside your own environment, behind your firewall, on infrastructure you control. CARTO supports deployment on a single virtual machine or on Kubernetes, including running fully inside your own cloud tenant. Like SaaS, it works with every supported data warehouse.
This is the model regulated and risk-sensitive organizations gravitate toward, for a consistent set of reasons:
- The application runs inside their network boundary.
- Connectivity requirements like static IP allowlisting and private endpoints are under their control.
- Certain advanced analytics configurations are only available in this model.
Some enterprises go a step further and ask whether contract language could cover a move to self-managed infrastructure if circumstances ever required it. That conversation is possible precisely because the deployment model is not fixed forever: you can start with SaaS and revisit later.
Self-hosted carries more operational responsibility on your side. Our team helps actively with setup; this is a supported path, not a “here is the container, good luck” path.
Option 3: The CARTO Native App inside Snowflake
For Snowflake customers there is a third route: deploying CARTO through Snowflake Container Services, inside your Snowflake account. The application itself executes in the same platform that already holds your data and already passed your security review.
This is the one option that is platform-specific. SaaS and self-hosted are available whichever warehouse you run on; the Native App exists because Snowflake provides the container layer to make it possible.
Teams choose this model when they want the tightest possible alignment with an existing Snowflake footprint, both technically and commercially. It also pairs naturally with buying through the Snowflake Marketplace, where the subscription can draw down committed Snowflake spend. The same route exists on the other clouds: CARTO is also listed on the Google Cloud Marketplace, the AWS Marketplace, and the Databricks Marketplace, so committed spend can fund the deployment model you choose whichever platform you have standardized on.
How to choose a CARTO deployment model: three questions that settle it
When we walk evaluators through this choice, three questions usually settle it quickly:
- Does your security policy allow a vendor-operated application layer? If yes, start with SaaS. If the application must live inside your boundary, go self-hosted.
- Do you have specific network requirements? Private endpoints, static IP allowlisting, and in-tenant deployment all point to self-hosted.
- Is your center of gravity Snowflake? If your data, security review, and cloud commitment all live there, the Native App deserves a serious look.
One more thing evaluators consistently appreciate: single sign-on, role-based access, and group inheritance work across all three models, and in every model CARTO inherits the permissions already defined in your warehouse. The deployment choice changes where the application runs. It does not change who can see what.
Compare CARTO deployment options against your own requirements
Deployment conversations go faster with your architecture diagram on the table. Bring it, and we will map the three options against your actual requirements. Request a demo.
Frequently Asked Questions
What are the CARTO deployment options?
There are three. CARTO SaaS is hosted and operated by CARTO and is the fastest to set up. CARTO Self-hosted runs the application layer inside your own environment, on a single virtual machine or on Kubernetes. The CARTO Native App runs inside your Snowflake account through Snowflake Container Services. In all three, your data stays in your own data warehouse.
Does my data leave my data warehouse if I use CARTO SaaS?
No. The SaaS component is the application layer, meaning Builder, Workflows and the APIs, not a copy of your data. Queries are pushed down and executed inside your own warehouse, so your data never moves to CARTO servers. For most organizations, including many in regulated industries, SaaS plus a well-configured warehouse connection meets security review requirements.
When should we choose CARTO Self-hosted instead of SaaS?
Choose self-hosted when the application itself has to run inside your network boundary, or when you have specific connectivity requirements such as private endpoints, static IP allowlisting, or deployment inside your own cloud tenant. It carries more operational responsibility on your side, and CARTO supports the setup actively.
Is the CARTO Native App available for data warehouses other than Snowflake?
No. The Native App is specific to Snowflake because Snowflake Container Services provides the container layer that makes it possible. CARTO SaaS and CARTO Self-hosted are warehouse-agnostic and connect to BigQuery, Snowflake, Databricks, Amazon Redshift and Oracle, including more than one at the same time.
Can we start with CARTO SaaS and move to self-hosted later?
Yes. The deployment model is not fixed forever, and some enterprises ask for contract language covering a move to self-managed infrastructure if circumstances ever require it. Single sign-on, role-based access and group inheritance work across all three models, and CARTO always inherits the permissions defined in your warehouse, so changing deployment does not change who can see what.
