Publish the method.
Make definitions, assumptions, source selection, and update dates visible so readers can evaluate how a conclusion was reached.
Open-source infrastructure. Built at the edge.
The architecture, methods, and contribution paths behind Good Neighbor Data’s public-interest guidance.
The public work should be inspectable.
This edition makes the technical and editorial operating model visible. The current site uses Astro and an edge deployment model. Data services such as D1, Turso, or Supabase are options for future features—not claims about infrastructure that is not yet in use.
“Edge-Native Serverless Stack” is the clearest description: globally distributed compute, server-rendered public content, and persistence introduced only where the product actually needs it.
Architecture, layer by layer.
The stack is described by responsibility, not acronym. Every layer should be replaceable, documented, and proportionate to the public feature it supports.
InterfaceAstroIn productionServer-rendered pages and selective React hydration keep public guidance readable, fast, and inspectable.ToolchainBunBuild toolingA modern JavaScript runtime and package tool for local development, verification, and repeatable builds.ComputeEdge runtimeIn productionThe application is deployed to a distributed serverless runtime rather than one long-lived application server.DataD1, Turso, or SupabaseFeature-dependentPersistence should be added only when a public feature needs it, then selected for locality, portability, and operational fit.
Distributed by design, not tied to one server.
Traditional monolith
A Linux server can be open and dependable, but a single application host concentrates runtime, scaling, patching, and regional latency in one operating boundary.
Edge-native application
Serverless edge deployment distributes request handling across a provider network. It reduces origin dependence, while still requiring deliberate choices about state, portability, observability, and vendor boundaries.
Open by practice.
Keep the public layer portable.
Prefer standards-based HTML, documented data shapes, and replaceable services over a tightly coupled application stack.
Add infrastructure only when evidence requires it.
A database is not a badge. Static and server-rendered pages remain the default until collaboration, submissions, or live datasets justify persistence.
Treat privacy as architecture.
Collect the minimum information needed, avoid sending personal information to analytics, and document where submitted data goes.
Contribute to the public layer.
Review the methodology
Challenge definitions, evidence thresholds, source quality, and the limits stated in public guidance.
Propose primary sources
Share utility filings, environmental reports, technical standards, public meeting records, or operating disclosures that improve the evidence base.
Improve the public interface
Identify accessibility, performance, mobile, content-structure, or data-presentation improvements that make the work easier to use.