back to projects
running

Dreamer

Self-hosted PaaS with scale-to-zero and sub-30s cold starts — deploys any GitHub repo in under a minute.

LiveGitHub

<30s

Cold start

<1min

Push to live

0

State races under retry

git pushRedis SET NXdistributed mutexBullMQ workerECS FargatecloudDockerbare metalPostgres triggervalid state onlyone interface — two execution engines, zero races under concurrent retries

Try it: the race this mutex solves

5 concurrent wake-up requests hit a sleeping container. Watch what happens with and without the lock.

incoming requests

req-1waiting…
req-2waiting…
req-3waiting…
req-4waiting…
req-5waiting…

container state

asleep

event log

— press "fire 5concurrent requests" above —

DockerBullMQRedisPostgreSQLAWS ECSNext.js

built because I had an old PC which was underutilized, and wanted to know exactly what happens between git push and a live URL.

Problem
Replicating a correct Vercel-style deploy pipeline meant solving a thundering-herd race on container wake-up, and enforcing a deployment state machine under concurrent BullMQ workers without corrupting state.
Solution
Hosted on my old PC, A Redis SET NX distributed mutex coordinates container wake-up so exactly one job fires regardless of concurrent requests, and a Postgres trigger enforces valid state transitions at the database layer instead of trusting application code to get the race condition right.
Result
Dual execution engine (AWS ECS Fargate for cloud, local Docker for bare-metal) behind one interface, sub-30s cold starts, and zero state-machine races under concurrent retry attempts.
OpenTradePolyglot