Marmot Cloud
Marmot Cloud is the hosted version of Marmot. You get the same catalog described in the rest of these docs, on a hostname of your own, with the Postgres cluster, upgrades, backups and TLS managed for you. The data model, the query language, the plugins and the MCP server are unchanged, so everything else in this documentation applies as written.
Marmot Cloud adds three things that only make sense when someone else runs the server: access control per resource, secret stores that read from the vault you already run, and a workload identity issuer that lets pipelines authenticate to your cloud with no stored credential. Everything in this section applies to Marmot Cloud and Marmot Enterprise. Where a page covers something open source Marmot also has, such as pipelines, it says so.
Launch your first instance
Sign in, pick a region and a size, and have a Marmot instance answering requests in about a minute.
Features
- A managed instance
- Fine-grained access control
- Federated secret stores
- Keyless pipelines
- Single sign-on
- A private plugin registry
The console and your instance
Marmot Cloud has two addresses.
The console at cloud.marmotdata.io is the control plane for your account: your plan, your billing, and the instances you own. You launch, stop and delete instances there, and pick up the initial administrator password. It knows nothing about the contents of your catalog and has no API.
Your instance is the Marmot server itself, at an address like https://acme.marmotdata.cloud. Every asset, pipeline, service account and access grant lives there, along with the REST API, the MCP endpoint and the OIDC documents behind keyless authentication.
You touch the console to create an instance and to change plan. Everything else happens against the instance.
Manage it with Terraform
Every change to an instance in these docs is Terraform, and that is how we recommend running one. Pipelines, secret stores, service accounts and access grants are resources in the Marmot provider. The cloud-side half of each, the IAM role or the federated credential, is a resource in your cloud provider. Declaring both in one configuration keeps a pipeline's identity and the trust that admits it from drifting apart.
terraform {
required_version = ">= 1.11"
required_providers {
marmot = {
source = "marmotdata/marmot"
}
}
}
provider "marmot" {
host = "https://acme.marmotdata.cloud"
}
On your own machine the provider uses your marmot login session. In CI it runs as a service account. The UI is for reading: run history, the access panel on an asset, validating a secret store.
Differences from self-hosting
The catalog, the query language, the plugins, the MCP server and the SDKs are identical, and a Cloud instance can be swapped for a self-hosted one without rewriting ingestion. Three subsystems exist only on Marmot Cloud and Marmot Enterprise.
| What it adds | |
|---|---|
| Access control | Roles granted on one asset, data product, glossary term or secret store, not only across the instance. This is what lets an agent hold a credential scoped to the assets it should see. |
| Secret stores | Marmot stores the address of a credential in your secret manager and resolves it before each run. Nothing is copied into Marmot or Terraform state. |
| Workload identity | Your instance mints a short-lived token per pipeline and per store. Your cloud exchanges it for access. There is no key to store, rotate or leak. |