God’s Eye View: a globe, AI interaction and honest data boundaries
Run God’s Eye View locally: locked dependencies, optional keys and a clear hosting boundary
Follow the local-first setup without mistaking a Vite preview server or a successful build for a public multi-user deployment.
What you will learn
- Use the supported local setup as the baseline
- Add optional capabilities only when needed
- Public hosting is a separate engineering task
Before you start
- Basic JavaScript and JSON
- Understanding of coordinates and source timestamps
Explain how source records, validation, layer presentation and optional AI interaction differ, using synthetic examples.
Key takeaways
- Use the pinned setup requirements and actual startup URL.
- Optional map and voice providers have different terms and credentials.
- The local dev server is not a hardened public service.
Use the supported local setup as the baseline
At this source revision, the README specifies Node 24.x from 24.14.0 or Node 26.x, then npm ci, npm run doctor and npm run dev. These are the project’s documented requirements at the pinned date, not a permanent statement about every future Node release.
The standard local URL is localhost:4173; launchers may choose an available local port. Read the actual startup output. The alternative Pinokio route is documented separately, and its installer status must not be conflated with the older native credential-form issue described in the security guide.
Add optional capabilities only when needed
Keyless imagery and terrain have fallback behavior. Photorealistic tiles, place search and voice require different provider choices; availability, eligibility and quotas are provider-specific. Check current provider terms before spending or sharing, rather than treating the README’s marketing tier labels as a universal price guarantee.
The in-app settings panel stores terminal-clone keys in an ignored local environment file, or uses the launcher’s app environment file. These are plaintext files with restricted permissions, not encrypted vaults. Externally configured values remain distinct; never commit real credentials or put them in an article example.
Public hosting is a separate engineering task
The security guide says the local server brokers spendable provider capabilities. Exposing it beyond loopback requires a separately reviewed authentication proxy and network controls. Do not interpret npm run dev or a static build as a complete public, authenticated multi-user product.
Validate setup, keyless rendering and a benign layer before adding credentials. For this series we performed source and isolated-function checks only; no installation, container, public endpoint or provider account was created. A future hosted deployment needs its own acceptance, secrets and cost controls.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Check the documented Node environment.
- 2
Install locked dependencies and run the doctor.
- 3
Verify the local keyless path first.
- 4
Review authentication and budgets before any remote access.
Copy-ready example
npm ci
npm run doctor
npm run devFrequently asked questions
Is a successful build enough to host this publicly?
No. Server-side provider routes, authentication and cost exposure need separate review.
Are ignored local key files encrypted?
No. The security guide describes local plaintext with restricted permissions.
Sources
- God’s Eye View / README.mdSource checked 2026-09-14
- God’s Eye View / SECURITY.mdSource checked 2026-09-14