Build log Mar 21, 2026 2 min read

Day 009 - RankWar launch hardening

Day nine of the lmachine monolith: RankWar score decay moved behind an off-by-default flag, the scheduler stopped pretending overlap was safe, and Dokploy's Swarm contract was hardened around health checks and rollback instead of hope.

What shipped today

  • moved RankWar score decay behind an off-by-default launch flag instead of letting it quietly tax early participants
  • kept the decay engine in the codebase so it can come back later if real data proves it helps
  • tightened the scheduler contract so the decay command only schedules when the flag is on and runs with onOneServer()
  • hardened the Dokploy production contract around live Swarm health checks, start-first where overlap is safe, and rollback instead of pause
  • promoted the real next infra move: build images in CI and publish to a registry so the 8 GB box stops doing live app builds

Why decay is off

Decay sounds clever on paper.

At launch it is usually weak.

If the product still needs more creators, more entrants, and more proof loops, punishing inactivity too early can suppress the exact behavior you still need to grow.

So the stronger move is:

  • keep the mechanic
  • keep the event contract
  • keep the command
  • keep the tests
  • turn it off until live data justifies the pressure

That is product discipline, not indecision.

Why zero downtime is usually fake

Most teams say they have zero downtime because the proxy stayed up.

That is not the real bar.

The real bar is:

  • the new task starts before the old one dies when overlap is safe
  • the platform has an actual health check to judge the new task
  • failure triggers rollback, not a paused broken deploy
  • migrations do not break the still-serving old code path

Anything weaker is just a prettier outage.

The actual production rule

For this monolith:

  • web uses health-based start-first rollout plus rollback
  • Horizon uses health-based start-first because temporary worker overlap is acceptable
  • scheduler stays stop-first because duplicate cadence is a loser move

That split is stronger than pretending every role wants the same update order.

What remains

The next real upgrade is not another micro-optimization inside Laravel.

It is making the same-host deploy path boring enough that product and distribution can stay dominant:

  • serialized deploys
  • aggressive image pruning
  • rollback drills that stay honest on the 8 GB box

More infrastructure is not automatically the stronger move.