Tasker Core
Workflow orchestration in Rust with PostgreSQL-native messaging. Tasker Core provides DAG-based task execution, event-driven coordination, and multi-language worker support for complex workflows.
Status: Early Development — the core engine is functional, published, and under active development. APIs may evolve between minor versions.
What Is Tasker?
Tasker is an orchestration framework for workflows that need more than a job queue but less than a full BPM platform. You define tasks as directed acyclic graphs of steps, and Tasker handles dependency resolution, state management, retry logic, and worker coordination.
- DAG-Based Workflows — Define steps with dependencies; Tasker resolves execution order and parallelism automatically
- PostgreSQL as Source of Truth — All state lives in PostgreSQL. Messaging via PGMQ (zero extra dependencies) or RabbitMQ (high-throughput)
- Event-Driven Coordination — Real-time step discovery with LISTEN/NOTIFY push and polling fallback, and RabbitMQ for high-throughput messaging
- Multi-Language Workers — Write step handlers in Rust, Ruby, Python, or TypeScript. All languages share the same orchestration engine
-
Operational Tooling — CLI (
tasker-ctl) for task management, health monitoring, DLQ investigation, configuration validation, and project scaffolding
Good Fit
- Order fulfillment workflows with inventory, payment, and shipping coordination
- Data processing pipelines with complex step dependencies and parallel execution
- Payment processing with retry logic and idempotency guarantees
- Microservices orchestration where steps span multiple services
Not The Right Tool
- Simple cron jobs — use native cron or a job scheduler
- Single-step operations — the orchestration overhead isn't justified
- Sub-millisecond latency requirements — Tasker adds ~10-20ms architectural overhead per step
Getting Started
Prerequisites
- Rust 1.75+ | PostgreSQL 17+ (uuidv7 support) | Docker (recommended)
- Optional: RabbitMQ (for high-throughput messaging)
Quick Start
# Start PostgreSQL (includes PGMQ extension)
docker-compose up -d postgres
# Run migrations
export DATABASE_URL="postgresql://tasker:tasker@localhost/tasker_rust_test"
cargo sqlx migrate run
# Start orchestration server
docker-compose --profile server up -d
# Create a task
curl -X POST http://localhost:8080/v1/tasks \
-H "Content-Type: application/json" \
-d '{"template_name": "linear_workflow", "namespace": "example"}'
# Check health
curl http://localhost:8080/healthFull Guide: docs/guides/quick-start.md
Architecture
┌─────────────────────────────────────────────────────────────┐
│ Client Applications │
│ (REST API / gRPC / tasker-ctl) │
└──────────────────────────┬──────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Tasker Orchestration Server │
│ Task Init → Step Discovery → Enqueueing → Finalization │
└──────────┬──────────────────────────────────┬───────────────┘
│ │
▼ ▼
┌──────────────────────┐ ┌──────────────────────────┐
│ PostgreSQL + Broker │◄────────►│ Namespace Worker Pools │
│ (PGMQ or RabbitMQ) │ │ (Horizontal Scaling) │
└──────────────────────┘ └──────────────────────────┘
Key Patterns: Dual state machines (12 task + 9 step states), event-driven with polling fallback, autonomous workers, PostgreSQL as source of truth.
Deep Dive: Architecture Documentation
Workspace Structure
| Crate | Purpose |
|---|---|
tasker-pgmq |
PGMQ wrapper with atomic notify (PostgreSQL messaging backend) |
tasker-shared |
Core types, state machines, messaging abstraction |
tasker-orchestration |
Task coordination, REST/gRPC API |
tasker-worker |
Step execution, FFI layer |
tasker-client |
REST/gRPC client library |
tasker-sdk |
Shared SDK — codegen, template parsing, schema inspection, operational tooling |
tasker-ctl |
CLI binary — operations, config management, plugin system |
tasker-mcp |
MCP server exposing Tasker tooling to LLM agents |
crates/tasker-example-rs |
Rust example worker implementation |
crates/tasker-rb |
Ruby FFI bindings (tasker-rb gem) |
crates/tasker-py |
Python FFI bindings (tasker-py package) |
crates/tasker-ts |
TypeScript FFI bindings (@tasker-systems/tasker) |
Documentation
All documentation is organized in the Documentation Hub:
| Section | Description |
|---|---|
| Quick Start | Get running in 5 minutes |
| Architecture | System design, state machines, event systems, CLI architecture |
| Guides | Workflows, batch processing, configuration |
| Workers | Ruby, Python, TypeScript, Rust handler development |
| Operations | Deployment, monitoring, tuning |
| Principles | Design philosophy and tenets |
| Decisions | Architecture Decision Records (ADRs) |
Development Guide: docs/development/ | AI Assistant Context: CLAUDE.md
Development
# Build (always use --all-features)
cargo build --all-features
# Test (requires PostgreSQL running)
cargo test --all-features
# Lint
cargo fmt && cargo clippy --all-targets --all-features
# Run server
cargo run --bin tasker-serverThe project uses cargo-make as its task runner. See CLAUDE.md for complete development context including test levels, database operations, and container setup.
Published Packages
Tasker is published across multiple registries:
| Package | Registry | Language |
|---|---|---|
tasker-shared, tasker-pgmq, tasker-client, tasker-ctl, tasker-orchestration, tasker-worker
|
crates.io | Rust |
tasker-rb |
RubyGems | Ruby |
tasker-py |
PyPI | Python |
@tasker-systems/tasker |
npm | TypeScript |
Contributing
- Review CLAUDE.md for project context and conventions
- Run tests:
cargo test --all-features - Format and lint before PR:
cargo fmt && cargo clippy --all-targets --all-features - See the Documentation Hub for documentation structure
License
MIT License — see LICENSE for details.
Workflow orchestration for teams that need reliability without ceremony.