You can self-host Kuudo so Amazon business data does not pass through Kuudo infrastructure. Kuudo's Amazon Ads, Selling Partner and Vendor Central MCP servers run in your own AWS, Google Cloud, Azure or Cloudflare account; requests go from there directly to Amazon, as described in the data processing addendum, and Agent Flow lands the data in a lake you own. Kuudo's authorization service holds the Amazon refresh token, encrypted.
Your chosen AI client receives the Amazon data and outputs it requests. If you connect a hosted client such as ChatGPT or Claude, its provider processes that data under your agreement with it. Self-hosting Kuudo does not keep that data inside your cloud account.
Use these guides to prepare one or more cloud accounts before creating a deployment environment in the app. Each guide focuses on the provider-side setup: credentials, project or subscription selection, required APIs or resource providers, and a verification step that separates cloud-account problems from product provisioning problems.
Pick a destination
| Provider | Best fit | What you prepare |
|---|---|---|
| AWS ECS Express | AWS accounts that standardize on ECS, ECR, CloudFormation, and IAM roles. | IAM access key, region, CloudFormation permissions, ECR, ECS, logs, and ECS load balancer role permissions. |
| Google Cloud | Teams that want Cloud Run with Artifact Registry. | Project ID, Cloud Run region, enabled APIs, service account roles, and a service account JSON key. |
| Azure | Azure subscriptions using service principals and resource provider registration. | Subscription ID, Tenant ID, Client ID, Client Secret, region, RBAC, and required resource providers. |
| Cloudflare | Cloudflare Workers, Containers, and R2-backed deployments. | Scoped API token, target account access, Workers permissions, Containers permission, and optional Account ID for troubleshooting. |
What to have ready
Before you open the environment wizard, decide:
- Which cloud account, project, or subscription should own the deployment.
- Which region or global runtime should host the deployment.
- Whether your organization allows long-lived keys, service account keys, API tokens, or client secrets.
- Who can create IAM/RBAC bindings and provider registrations.
- Where generated credentials will be stored after you paste them into the wizard.
Security baseline
Use dedicated credentials for the deployment workflow. Avoid root keys, personal admin credentials, broad tenant-wide grants, and credentials shared between unrelated systems.
Rotate credentials periodically, and rotate immediately when someone leaves the team or a token may have been exposed. Prefer cloud-native temporary credential or managed identity flows when the product supports them; use the documented key, token, or service principal flows when the wizard requires those values directly.
Verify before provisioning
Each provider guide includes a CLI or API verification step. Run it before opening the wizard:
- AWS:
sts get-caller-identity, CloudFormation, ECR, and ECS read checks. - Google Cloud: project metadata, Cloud Run, and Artifact Registry read checks.
- Azure: service-principal login and subscription read check.
- Cloudflare: accounts API and account read checks.
If verification fails locally, fix the cloud setup first. The wizard cannot provision resources with credentials that fail the provider's own read checks.
Continue
Start with the provider you plan to deploy first: