New docs: keeping long-running tasks alive and running private apps with Flycast

Here are two recently-published guides for staying in control of how your machines run and how your apps talk to each other:

Long-running tasks and machine lifecycle
Background jobs and queue workers can get killed when a machine looks idle to the proxy, because auto-stop decides based on traffic and never sees your in-process work. This guide explains how that decision actually gets made, then walks through two patterns to keep your work running: turning off autostop and draining gracefully with SIGTERM and kill_timeout, or splitting web and worker into separate process groups. It also includes a Common Problems section for the usual gotchas, like why a self-ping won’t keep a machine alive.

Run private apps with Flycast
Got an internal API, admin panel, or backend service that shouldn’t be on the public internet? Flycast lets your other apps reach it over your organization’s private network while still going through the Fly proxy. This guide deploys a private service end to end with the modern fly launch --flycast flow, using a generic public image so the steps work as written, and calls out the gotchas (internal port, force_https, VM memory) along the way.

Let us know if these guides are useful, what’s unclear, and what else you’d like to see covered.

The Guides section seems to be coming along really well… A couple quick suggestions for other topics that I think might make good additions someday:

  1. Billing your own customers
  2. Dealing with an ongoing capacity crunch
    • Recognizing this transient situation in the logs / flyctl messages.
    • Rescuing volumes when the attached Machine won't boot.
    • Downloading volume contents under the above conditions.
    • Moving builders to a different region.
    • Avoiding in the future (links to older docs).

Anyway, just a couple more ideas, :thought_balloon:…