Your Published App Now Stays Up While You Republish It
Republishing used to take a live Mythex app offline during the build. Now the previous version keeps serving until the new one is ready, plus two more fixes.
Mythex Team · · 2 min read
When you republish an app on Mythex, your live site now keeps serving the previous version until the new build is ready, then switches over. Before this change, a republish took the site offline for the whole build — visitors saw "This published app is offline or the link was not found" for a minute or so, and then the same page worked again on a reload. We also fixed two other ways a live app could wrongly look offline.
1. Republishing no longer takes your site down
Behind the scenes, each published app has a record that says which build to serve. A republish reused that record and marked it "building" for the duration — and the part of our edge that routes visitors only served records marked "live". So every republish made the site disappear until the build finished. We reproduced it on a small test app: about 50 seconds offline per republish.
Now, when a republish starts on an app that's already live, the record remembers that a previous build exists and keeps pointing at it. The edge serves that previous build while the new one builds, and the pointer only moves to the new build when it succeeds. If the new build fails, your visitors never notice — the old version simply stays up.
A first publish, or republishing an app that was paused or unpublished, still goes live only when the build finishes — there's no previous version to show.
2. A brief hiccup no longer looks like "not found"
The service in front of your published app asks our API where each site lives. It used to treat any unsuccessful answer — a momentary server error, a dropped connection — as "this site doesn't exist", and showed the offline page. A reload a second later worked, which made it confusing.
Now only a real "not found" answer counts as not found:
- Any other failure is retried once.
- If it still fails, the edge serves the site from the last known good answer for up to an hour.
- Only if it has never had an answer does it show a "temporarily unavailable" page — never "not found".
Custom domains also ask our production and staging systems in parallel, so a slow staging server can never hold up a production domain.
3. A paused app says it's paused
Published apps run on your credit balance. If it runs out, the app is paused until you top up — and it comes back on its own when you do. But a paused app used to look exactly like a deleted one.
Now a visitor to a paused app sees "This app is paused", with a way back for the owner, and the response is never cached, so the app is reachable again the moment it's resumed. If an app is unavailable for another reason, visitors see "This app isn't available" — without being told why.
Why this matters
A published app is something you've shared: in a bio link, on a business card, with your first customers. It should behave like a real website — stay up while you improve it, survive a hiccup, and be honest when it's paused.
More on publishing in the docs: how to publish and hosting limits. And the infrastructure side of the same idea: how we got our own deploys to zero 502s.