HTTP Service editor via dashboard

Fresh Produce
1

Tweaking your app settings as needed is a important app of post-deployment and day-to-day maintenance of your app health.

fly.ioappsenv-leaker-v-q-igconfiguration
fly.ioappsenv-leaker-v-q-igconfiguration1186×1321 169 KB

Knowing that we just shipped a simple UI to let you tweak your HTTP Service configuration in our dashboard.

Currently it only contains the most important things that you’d need to tweak during/after launch such as auto stop/start behavior and minimum running machines.

Later on we will be adding more to these until everything* from the fly.toml can be directly edited from our UI. We’ve been sneaking in those updated under a feature flag so you might just see something in your UI before we fresh produce the full update here too :wink:

*Probably experimental things wont be added.

Small additions

image
image429×323 20.7 KB

  • Under machines list one can update the command for each process group.
  • Improved how we show Scaling operations in App dashboard
  • New scale operations now show a different activity item under activity page and widget
  • Machines have their release version metadata properly updated even when they’re not affected by the scale changes

All changes

In no particular order.

  • Warning when Min machines running is set too high — the form alerts you per process group when the minimum exceeds the number of machines you currently have in your primary region
  • Warning when Auto start machines is turned off — a notice explains that machines that exit will stay offline until you restart them manually or via the API
  • Configuration page is blocked during active scale operations — a clear message appears when the HTTP service form can’t be used because a scale is already running or machines are still loading
  • Scale plan and HTTP service releases are visually distinct in Activity — they show the type of change (Scale Plan or HTTP Service), the primary thing that changed, and a count of additional changes, rather than looking like a regular deploy
  • Release detail page shows what the scale plan changed — the full list of changes (VM sizes, startup commands, HTTP service settings) appears on the release page
  • Every release created from the UI now records why it was created — the source and human-readable reasons are stored in the release metadata, visible in the release detail and activity feed
  • All machines now reflect the correct release version after a scale — machines not directly part of a scale plan (bystanders) also get their fly_release_version metadata updated, so the API no longer shows them stuck on a stale version
  • HTTP service updates now stamp the release version on machines — previously changing settings like min_machines_running from the UI did not update machine metadata; now it does
  • Fixed: resetting a process group startup command now correctly updates the fly.toml PR — previously the PR diff showed only a timestamp change; now the command appears as group = '' (image default) in the [processes] section as fly.io requires
  • Fixed: force_https is now applied correctly when updating machines — it was being set at the wrong level in the Machines API call, so toggling it from the UI had no effect on running machines (the fly.toml PR was already correct)
  • Fixed: scaling one group away from a shared VM config correctly splits into separate sections — previously the global [[vm]] block was silently updated for all groups, changing sizes that weren’t part of the scale
  • Fixed: multiple [[vm]] sections in a fly.toml no longer produce duplicated lines in the PR diff — a key-ordering bug caused each field to repeat once per [[vm]] block
  • Fixed: resetting a startup command to image default no longer corrupts the machine config — the Machines API was receiving {} instead of the correct empty state
1 Like