Skip to main content
A Resource represents a deployment target - the actual infrastructure where your code runs. Resources can be Kubernetes clusters, VMs, cloud functions, or any other compute environment.

What is a Resource?

Resources are the “where” in your deployment pipeline. They represent:
  • Kubernetes clusters (e.g., prod-us-east-1-cluster)
  • Virtual machines (e.g., web-server-01)
  • Cloud functions (e.g., lambda-handler-prod)
  • Containers (e.g., ECS service)
  • Custom infrastructure (anything you can deploy to)

Resource Properties

Core Fields

name

Human-readable display name for the resource. Examples:
  • “Production US East Cluster”
  • “Web Server 01”
  • “Lambda Production Handler”

kind

Classification of the resource type. Used for filtering and grouping. Common Values:
  • kubernetes-cluster
  • vm
  • lambda-function
  • ecs-service
  • cloud-run-service
  • server (generic)

identifier

Unique identifier for this resource. This is how external systems reference the resource. Examples:
  • k8s-prod-use1
  • i-0abc123def456789 (EC2 instance ID)
  • arn:aws:lambda:us-east-1:123456789:function:my-function
Requirements:
  • Must be unique within the workspace
  • Should be stable (don’t change frequently)
  • Often matches the infrastructure’s native identifier

metadata

Key-value pairs used for classification and selector matching. This is crucial for resource targeting. Common Metadata Keys:
Best Practices:
  • Use consistent key names across resources
  • Use lowercase with hyphens: cost-center not CostCenter
  • Include classification useful for targeting
  • Don’t put sensitive data in metadata

config

Resource-specific configuration. Unlike metadata (which is for selection), config contains operational details. Examples: Kubernetes Cluster:
VM:
Lambda:

version

The current version or state of the resource itself (not the deployed application). Examples:
  • 1.28.0 (Kubernetes version)
  • 20.04 (Ubuntu version)
  • nodejs20.x (Lambda runtime)

providerId

Reference to the Resource Provider that created/manages this resource. Optional for manually created resources.

Creating Resources

Via CLI

Via Web UI

  1. Navigate to your system
  2. Go to “Resources” tab
  3. Click “Create Resource”
  4. Fill in the form:
    • Name, Kind, Identifier
    • Add metadata key-value pairs
    • Add config (JSON)
  5. Click “Create”

Automated Creation (Resource Providers)

Recommended approach for production: Use Resource Providers to automatically sync resources from your infrastructure. Resource Providers continuously sync resources from external sources:
  • Kubernetes Provider: Discovers clusters from kubeconfig
  • AWS Provider: Syncs EC2 instances, ECS services, Lambda functions
  • GCP Provider: Syncs GCE instances, Cloud Run services
  • Azure Provider: Syncs VMs, container instances
  • Custom Provider: Your own integration
Example using Node SDK:
The provider automatically:
  • Creates new resources
  • Updates existing resources
  • Removes resources no longer in the source

Resource Metadata for Targeting

Metadata is how resources get matched to environments and deployments. Design your metadata schema carefully.

Example Metadata Schema

Selector Matching Example

Environment Configuration:
Matched Resources:
  • ✅ Resource A: {environment: "production", region: "us-east-1"}
  • ✅ Resource B: {environment: "production", region: "us-east-1", team: "platform"}
  • ❌ Resource C: {environment: "production", region: "us-west-2"}
  • ❌ Resource D: {environment: "staging", region: "us-east-1"}

Resource Variables

Resources can have variables attached to them, which are available during job execution.

Creating Resource Variables

Variables are typically configured via the Web UI. You can also use the API:

Using in Job Execution

When a job executes on a resource, it receives all resource variables:

Common Resource Variables

Kubernetes Resources:
  • KUBERNETES_NAMESPACE - Target namespace
  • KUBERNETES_CONTEXT - Kubectl context
  • HELM_RELEASE_NAME - Helm release name
VM Resources:
  • SSH_HOST - Host to SSH into
  • SSH_USER - SSH username
  • DEPLOY_PATH - Where to deploy files
Lambda Resources:
  • FUNCTION_NAME - Lambda function name
  • AWS_REGION - AWS region
  • AWS_ACCOUNT_ID - AWS account

Resource Lifecycle

States

Resources don’t have explicit states in Ctrlplane, but they can be:
  1. Active - deletedAt is null, available for deployments
  2. Deleted - deletedAt is set, excluded from deployments

Updating Resources

Update resource metadata with a YAML file:

Deleting Resources

Soft delete (recommended):
This sets deletedAt timestamp. The resource is excluded from new deployments but historical data is preserved.

Querying Resources

List All Resources

Filter by Selector

Get Resource Details

Resource Providers

Creating a Resource Provider

Syncing Resources

The provider:
  • Creates resources that don’t exist
  • Updates resources that changed
  • Removes resources not in the provided list (careful!)

Provider Sync Strategy

Full Sync (default):
This removes resources not in the list. Good for keeping Ctrlplane in sync with source of truth. Incremental Updates: If you want to preserve manually created resources, filter by provider:

Best Practices

Metadata Design

Do:
  • ✅ Use consistent key names across all resources
  • ✅ Include classification useful for targeting
  • ✅ Use hierarchical values when appropriate (region/zone)
  • ✅ Include ownership information (team, cost-center)
Don’t:
  • ❌ Put sensitive data in metadata (use config or variables)
  • ❌ Use inconsistent naming (env vs environment)
  • ❌ Include data that changes frequently
  • ❌ Duplicate information already in other fields

Resource Identifiers

Good Identifiers:
  • k8s-prod-us-east-1 - Descriptive and stable
  • i-0abc123def456789 - Native AWS instance ID
  • arn:aws:... - Full ARN for AWS resources
Poor Identifiers:
  • cluster-1 - Not descriptive
  • 10.0.1.50 - IP addresses can change
  • temp-cluster - Suggests instability

Resource Variables

  • Use for environment-specific configuration
  • Mark sensitive variables as sensitive: true
  • Prefer resource variables over hardcoding in deployment config
  • Use consistent variable naming across similar resources

Provider Usage

  • Use providers for production (keeps resources in sync)
  • Run provider sync on a schedule (cron job, CI pipeline)
  • Test provider sync in staging first
  • Monitor provider sync failures

Common Patterns

Multi-Region Kubernetes

Tiered Resources

Team-Based Resources

Troubleshooting

Resource not appearing in environment

  • Check the environment’s resource selector
  • Verify resource metadata matches the selector
  • Confirm resource is not deleted (deletedAt is null)

Provider sync not working

  • Verify API key has correct permissions
  • Check provider name matches
  • Review provider sync logs for errors

Duplicate resources created

  • Ensure identifier is truly unique
  • Check if provider is creating duplicates
  • Review provider logic for identifier generation

Next Steps