M
member badge
Michael (Driverforge)
Most observability tools treat environments as something you tag explicitly — local, staging, QA, production. Control4 driver development has a simpler shape: you test on your own controller while building, then the driver goes out to dealers and end-users and stops being something you directly control. Environments in Anvil would reflect that reality with two implicit modes — Development and Production — rather than asking you to label every telemetry payload yourself.
Development is everything you already see: full event, log, and error detail from your own controller while you're iterating. Production is the opt-in side, populated only when you enable production monitoring for a release and data starts flowing back from dealer installs. The two streams share the same project but stay clearly separated: a noisy error you intentionally triggered while debugging doesn't show up in your production error counts, and a spike in the field doesn't get buried under your own test traffic.
Where development and production data coexist, an environment filter sits at the top of each data view and you can switch between "All", "Development", and "Production" as needed. Production data is visually distinct — a different badge colour, clear labelling in detail views — so you never have to guess which side of the fence you're looking at. For projects that never enable production monitoring, the filter stays hidden and nothing changes from today. Custom environment names beyond development and production are deliberately out of scope for now; most driver workflows don't have intermediate stages that need their own bucket, and we'd rather keep the mental model simple until we hear otherwise.
What we're thinking:
  • Two implicit environments: Development (default) and Production (opt-in via production monitoring)
  • Environment filter on data views when production data is present
  • Visual distinction (badge colour, labelling) so the two are easy to tell apart
  • Separate aggregations — dev errors don't pollute prod metrics and vice versa
  • Stricter privacy controls on production data (anonymised install IDs, no PII)
  • Different retention windows if needed (longer for production, for compliance)
  • Custom environment names deferred — intentionally not in v1
Help us shape this:
  • Does your workflow have anything that looks like a staging step — a QA controller, a beta dealer, a test installation — or is it really just "your machine" then "production"?
  • Would you ever need to look at dev and prod data side-by-side in the same view, or are they different enough that you'd always filter to one?
  • If we later added custom environment names, what would you use them for?