Blog

Ingénierie

Comment Mythex est conçu et exploité, y compris ce qui a cassé et comment nous l’avons réparé.

Ingénierie

Comment Mythex est conçu et exploité, y compris ce qui a cassé et comment nous l’avons réparé.

  • A Failed Republish Never Deletes a Working Backend — A failed republish could delete an app's live API, or leave its broken new version running. Three fixes to how Mythex undoes a publish that goes wrong.
  • Alerts That Fire Once, Not Once per Server — A once-a-day alert reached us five times in one afternoon. Why in-memory dedupe breaks with two servers and a deploy, and how shared state fixed it.
  • Moving to Bigger Workspaces Without Making Anyone Wait — A quarter of our workspaces were stuck at 1 GB after we moved to 2 GB. Our first fix made one person wait seven minutes. What we changed, and changed again.
  • Billing Databases by What They Actually Use — We used to estimate each app's database cost, and the estimate was wrong both ways. Now every database is billed from measured usage, hour by hour.
  • Catching Apps That Crash Right After Publishing — Three publishes passed our health check while their API crashed seconds into every boot. The cause: counting crashes in a list capped at five entries.
  • Keeping Image-Heavy Agent Turns Within Memory — An agent turn that kept looking at catalogue scans ran out of memory at 952 MB. Three separate causes, each holding images too long, and how we fixed them.
  • Keeping Long Agent Turns Inside the Context Window — Our sub-agents could grow until the model refused them, stop early to save room, or miscount tokens in Russian. Three fixes that let long AI work finish.
  • Keeping the Chat Alive When a Phone Sleeps — Phones sleep, switch tabs and drop networks mid-build. Two bugs made Mythex's chat stall or show half a reply afterwards. How we found and fixed both.
  • How One Heavy Chat Could Take Our API Down — On September 28 both of our API servers ran out of memory at once. The first fix was more memory; the real one was loading chat history by size, not count.
  • Pressing Publish Twice Now Publishes Once — Three publish requests for one app arrived 84ms apart and each ran a full deploy. How we made the database decide who publishes, and told the others the truth.
  • SEO Lessons From Fixing Our Own Site — Duplicate FAQ markup, the wrong thumbnail in Google, template pages nobody clicked and a path our edge refused: what we found on mythex.ai and fixed.
  • Static Sites Now Stay Up While They Republish — Republishing a static site used to empty it before uploading the new build. Now the old site serves until the new one is in place, and changes show in seconds.
  • The Out-of-Memory Crash Hiding in a Progress Label — Our AI agent ran out of memory writing one large file. The cause wasn't the model or parallel sub-agents — it was a status label resent 41,000 times.
  • The Missing Swap File That Froze Our Servers — A production server stopped answering without crashing — no out-of-memory kill, just page-cache thrash on a box with no swap. What happened and what we changed.
  • Waking Up Databases Without Dead Connections — A published app waking from sleep held its first request 10–12 seconds on database connections that died while it slept. How we got it to 2.3 seconds.
  • We Were Rate-Limiting Our Own Services — Our API's per-address rate limit treated our own services like one busy person, and in production they started getting 429s. How we found it and fixed it.
  • Why We Moved Mythex's Servers to ARM — Once heavy work moved into per-project sandboxes, our servers used a third of their memory. Smaller ARM instances cut costs by about 30%. Here's how.
  • How We Got Deploys Down to Zero 502 Errors — A watchdog racing our deploys and a load balancer that noticed too late: how we found both, fixed them, and measured deploys from 10 502s to zero.

Mythex · Tarifs · FAQ · Guides · Blog · Cas d’usage · À propos