ut.Let's talk
All projects
Distributed systems / Locally validated

CloudCrew.

Give agents a reliable place to work.

Explore the repository
Actual CloudCrew console showing task and worker state
ACTUAL REPOSITORY SCREENSHOT
WHAT IT DOES

A distributed task platform where independent workers claim durable jobs, run agents, and persist results.

WORK IN THIS REPOSITORY

Durable task orchestration, worker recovery, observability, and deployment tooling.

THE INTERESTING DECISION

PostgreSQL stores jobs and results and also acts as the queue. SKIP LOCKED supports independent workers without introducing a separate broker for this small deployment.

START WITH THE EVIDENCEAt least once

The documented reliability model, not an exactly-once claim.

Inspect the source ↗
BUILT WITH
FastAPIPostgreSQLDockerLangGraph
PROJECT TYPE

Locally validated

START HEREREADME & setup
01 / THE IDEA

Give agents a reliable place to work.

The problem

Agent execution needs more than an API call. Jobs must survive restarts, retries need boundaries, and a worker that loses ownership must not overwrite a newer result.

The approach

A stateless supervisor accepts authenticated submissions. PostgreSQL serves as a durable queue while worker processes lease jobs, route them to plugins, record lifecycle events, and persist results.

02 / THE SYSTEM AT A GLANCE

Follow the flow.

  1. 01API client
  2. 02Supervisor
  3. 03Durable queue
  4. 04Worker agents
  5. 05Saved result

A simplified architecture overview. The repository documents the implementation details.

CloudCrew task console showing queued work, workers, and persisted task history
Actual console screenshot from the CloudCrew repository.
03 / THE ENGINEERING DECISIONS

Why it's built this way.

01

One database, two responsibilities

PostgreSQL stores jobs and results and also acts as the queue. SKIP LOCKED supports independent workers without introducing a separate broker for this small deployment.

02

Recover with leases and fencing

Expired leases can be reclaimed. A fencing token prevents an old attempt from replacing a newer persisted result. Retries are bounded and eventually reach a terminal dead state.

03

Be honest about execution

Execution is at least once. Result fencing cannot undo an external provider call. Mock responses are labeled; cloud-provider errors enter the retry policy rather than becoming mock successes.

04 / WHAT TO LOOK AT

Evidence over adjectives.

ExecutionAt least once

The documented reliability model, not an exactly-once claim.

QueueDurable

Tasks, results, and events survive API restarts.

Demo modeNo paid API

Deterministic mock mode is explicit; Gemini is optional.

Capabilities and result snapshots follow the project's current README, reviewed October 10, 2026. Read the source

Reliability modelValidation recordRecruiter walkthrough
05 / THE HONEST PART

What I'd improve next.

Current boundaries

  • The README states that this project has not been deployed to a public cloud account.
  • SQLite is for single-host development; PostgreSQL supports replica deployments.
  • Stored history is not automatically sent to external models.

The next iteration

Measure a real cloud deployment and compare worker scaling under a representative workload.

Open my Cloud & DevOps CV
KEEP EXPLORING

CipherRelay

Private content. Visible engineering.