Architecture
Understanding Shiro's modular architecture and how it orchestrates workflows efficiently.
Integrations
Orchestration Flow
Module System
Built-in Modules
Compiled into the main binary for zero-dependency execution
- ›print - Console output with log levels
- ›slack.notify - Slack notifications
- ›git.diff - Git operations
- ›ai.generate - AI content generation
Subprocess Modules
External programs communicating via JSON over stdin/stdout
- ›Binary mode: Pre-compiled from GitHub releases
- ›Go-run mode: Executed via go run
- ›Auto-detection based on module.yaml
- ›Example: Jira Data Center integration
Subprocess Architecture
External Module Communication
How Shiro communicates with subprocess modules
State Storage Backends
GitLab Artifacts
Stores workflow state in GitLab CI artifacts. Automatically uploaded and downloaded between pipeline stages.
Filesystem
Stores state in local filesystem. Ideal for local development and testing workflows.
Memory
In-memory state storage. Fastest option but state is lost after execution completes.
Native Modules Support
Creating Custom Modules
Extend Shiro with your own integrations
Shiro supports a decentralized module architecture that enables external contributors to create custom modules for SaaS applications without modifying the core codebase.
Module Template Structure
your-module/ ├── main.go # Module implementation ├── config.yaml # Module configuration ├── module.yaml # Shiro metadata └── README.md # Documentation
Modules can be distributed via GitHub or a community registry. Add the shiro-automation-module topic to your repo to appear in the community list.