kubiya_inline_source
resource allows you to define tools and workflows directly in your Terraform configuration. This is ideal for custom tools, quick prototypes, and workflows that don’t require a separate Git repository. For Git-based sources, use the kubiya_source
resource instead.
Inline sources are perfect for custom automation that’s tightly coupled with your infrastructure configuration, enabling rapid prototyping and deployment-specific tools.
Container-First Architecture
Kubiya uses a container-first architecture where every tool is backed by a Docker image. This ensures:- Secure, isolated execution environments - Each tool runs in its own container
- Predictable and reproducible results - Consistent execution across environments
- Language-agnostic tool implementation - Support for any programming language
- Easy integration with existing containerized workflows - Leverage existing Docker images
Prerequisites
Before using this resource, ensure you have:- A Kubiya account with API access
- An API key (generated from Kubiya dashboard under Admin → Kubiya API Keys)
- Docker images accessible from your runner environment
- Understanding of tool and workflow structure in Kubiya
Quick Start
Configuration Examples
Create automation workflows for deployment processes:
Advanced Configurations
Mixed Tools and Workflows
Mixed Tools and Workflows
Combine tools and workflows in one comprehensive source:
Security Scanning Tools
Security Scanning Tools
Create security scanning and compliance tools:
Database Management Tools
Database Management Tools
Create database management and migration tools:
Arguments Reference
Required Arguments
The name of the inline source. Must be unique within your organization.
Optional Arguments
The runner to use for executing tools and workflows from this source.
JSON-encoded array of inline tool definitions. Each tool defines a containerized executable.
JSON-encoded array of workflow definitions. Each workflow defines a multi-step automation process.
JSON-encoded configuration for dynamic parameters and source-level settings.
Tool Definition Structure
Unique identifier for the tool.
Human-readable description of what the tool does.
Execution type (usually “docker” for containerized tools).
Docker image to use for tool execution.
Command or script to execute within the container.
Optional arguments that the tool accepts:
Name of the argument (used as environment variable).
Type of the argument (e.g., “string”, “number”, “boolean”).
Description of what the argument is used for.
Whether the argument is required for tool execution.
Default value for the argument if not provided.
Workflow Definition Structure
Name identifier for the workflow.
Description of the workflow’s purpose.
Array of workflow steps defining the execution sequence:
Unique name for the step within the workflow.
Optional description of what the step does.
Executor configuration defining how the step runs:
type
: “tool”, “command”, or “agent”config
: Configuration specific to the executor type
Array of step names that must complete before this step runs.
Variable name to store the step’s output for use in subsequent steps.
Attributes Reference
In addition to all arguments above, the following attributes are exported:The unique identifier of the inline source.
The computed type of the source (always “inline”).
Import
Inline sources can be imported using their ID:Best Practices
Container Management
- Use specific image tags rather than “latest” for reproducibility
- Choose lightweight base images when possible (alpine, slim variants)
- Consider resource requirements when selecting Docker images
- Ensure images are accessible from your runner environment
Security
- Never hardcode credentials in tool definitions; use Kubiya secrets
- Use read-only file systems where possible
- Implement proper input validation in tool scripts
- Audit tool permissions and capabilities regularly
Development & Testing
- Test tools and workflows in development before production use
- Include error handling in tool scripts
- Use echo statements and output variables for debugging workflows
- Create focused, single-purpose tools that can be composed
Documentation & Maintenance
- Include clear descriptions for tools and their parameters
- Document expected inputs and outputs for each tool
- Consider moving complex tools to Git repositories as they mature
- Version control your Terraform configurations
Executor Types
Execute custom tools defined in the same source:
Compatibility
Requirements:
- Kubiya Terraform Provider version >= 1.0.0
- Terraform >= 1.0
- Docker images must be accessible from the runner environment
- Tools and workflows are defined inline, not from Git repositories
Important Considerations:
- Inline sources must be created before agents can reference them
- Large tool definitions may impact Terraform plan/apply performance
- Complex tools should consider migration to Git-based sources
- Container resource limits apply to tool execution
Troubleshooting
Tool Execution Issues
Tool Execution Issues
- Verify Docker images are accessible from the runner environment
- Check tool arguments and environment variable formatting
- Ensure file paths in with_files are absolute and valid
- Review container logs for execution errors
Workflow Step Problems
Workflow Step Problems
- Validate step dependencies for circular references
- Check output variable names match between steps
- Ensure tool_name references match defined tool names
- Verify executor configurations are properly formatted
JSON Encoding Issues
JSON Encoding Issues
- Use jsonencode() function for complex structures
- Validate JSON syntax with external tools if needed
- Check for proper escaping of special characters
- Ensure consistent indentation and formatting