Connect

Connect is where you bring your existing cloud accounts, source control, registries, and third-party services into Planton. Every deployment Planton runs on your behalf — whether it is creating an AWS VPC, building a container image, or storing Terraform state — requires credentials to authenticate with external providers. Connect manages those credentials so they are stored securely, scoped to the right environments, and never exposed in logs or CI/CD pipelines.

The Problem Connect Solves

In a typical DevOps setup, credentials are scattered. AWS keys live in CI/CD environment variables. GitHub tokens are duplicated across repositories. Container registry passwords are hardcoded in build scripts. When an engineer rotates a credential, they have to track down every place it was used.

Connect eliminates this by giving credentials a single home at the organization level. You create a credential once, authorize it for specific environments, and Planton handles injection at runtime. Engineers deploying infrastructure or services never see the underlying secrets — they select which connection to use, and the platform takes care of the rest.

What You Can Connect

The Connections page in the web console organizes integrations into four categories:

Infrastructure

Cloud providers where Planton deploys and manages resources on your behalf.

For details on connecting each provider, see Cloud Providers and Kubernetes Clusters.

DevOps Pipeline

Source control providers and artifact registries that power your build and deployment pipelines.

For details, see Git Providers and Container Registries.

Infrastructure as Code

State backends that store the state files for Pulumi and Terraform deployments.

For details, see State Backends.

Managed Services

Third-party platforms that Planton can provision resources on.

Managed service credentials follow the same create-authorize-default workflow as cloud provider credentials. To connect a managed service, navigate to the Managed Services section of the Connections page and follow the setup wizard for your provider.

How Authentication Works

When you create a connection, you choose how Planton authenticates with the provider. There are three authentication modes, and the right choice depends on your security requirements.

Inline Credentials

You provide the credentials directly — an API key, a service account key, a client secret. Planton encrypts and stores them. This is the most straightforward option and works well for development environments or organizations getting started.

Best for: Quick setup, development environments, small teams.

Runner-Delegated Authentication

Instead of storing credentials in Planton, you deploy a Runner in your own infrastructure and let it authenticate using the environment's native identity — AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity, or Azure Managed Identity. The credentials never leave your infrastructure.

Best for: Production environments, compliance-sensitive workloads, organizations that require credentials to stay within their network.

Cross-Account Trust (AWS)

Specific to AWS. You create an IAM role in your AWS account that trusts Planton's Runner. The Runner assumes that role using AWS STS when it needs to act in your account. No long-lived access keys are exchanged.

Best for: AWS organizations with strict credential policies, multi-account setups, cross-account deployments.

Not every provider supports all three modes. Cloud infrastructure providers (AWS, GCP, Azure, DigitalOcean, Civo, Cloudflare) and Kubernetes clusters support inline and runner-delegated authentication. Cross-account trust is currently AWS-only. Git providers, registries, state backends, and managed services use inline credentials.

Authorization and Defaults

Creating a credential is only the first step. Two additional concepts control how credentials are used across your organization:

Environment Authorization

A credential exists at the organization level, but it must be explicitly authorized for each environment where it can be used. This prevents a production AWS account from being accidentally used in development, or a staging database credential from being used in production.

You can authorize a credential for all environments at once (organization-wide scope) or for a specific list of environments. See Environment Mappings for details.

Default Connections

When a Cloud Resource or Service deployment doesn't explicitly specify which credential to use, Planton looks for a default connection for that provider. Defaults can be set at the organization level (applies to all environments) or per-environment (overrides the organization default for that specific environment).

The resolution is straightforward: if an environment-level default exists, it wins. Otherwise, the organization-level default is used. If neither exists, the deployment fails with a clear error message telling you to configure a default.

See Default Connections for the full resolution logic and CLI commands.

Getting Started

The typical setup flow for a new organization:

1. Connect your cloud provider — Start with your primary cloud account (AWS, GCP, or Azure). See Cloud Providers.
2. Connect your source control — Link your GitHub or GitLab organization so Service Hub can access your repositories. See Git Providers.
3. Connect a container registry — Set up a registry for your build artifacts. See Container Registries.
4. Configure a state backend — Choose where infrastructure state files are stored. See State Backends.
5. Authorize for environments — Decide which credentials can be used in which environments. See Environment Mappings.
6. Set defaults — Configure default credentials so deployments work without explicit credential selection. See Default Connections.

Managing Connections

Using the Web Console

Navigate to Connections in the sidebar to see the Mission Control layout. Click any provider card to start the connection wizard. Existing connections are listed in the "Connected Providers" tab on the right side of the page.

Using the CLI

The CLI provides commands for managing connection authorization and defaults:

# Connect an AWS account via browser-based CloudFormation flow
planton connect aws

# List all connection authorizations
planton connection authorization list

# Set a default connection for a provider
planton connection default set --provider aws --connection my-aws-account

# Test which connection would be resolved for a deployment
planton connection default resolve --provider aws --env production

Related Documentation

• Cloud Providers — Connect AWS, GCP, Azure, and other cloud accounts
• Git Providers — Connect GitHub and GitLab for source code access
• Container Registries — Connect image and package registries
• State Backends — Configure Pulumi and Terraform state storage
• Kubernetes Clusters — Connect external Kubernetes clusters
• Environment Mappings — Control which credentials can be used where
• Default Connections — Configure automatic credential selection
• Runner — Deploy the secure execution agent for runner-delegated authentication
• Security Overview — Platform-wide security architecture and credential isolation model