# What Is the Purpose of vite.config.js in Gods Eye View?

> Discover the purpose of vite.config.js in Gods Eye View. Learn how it configures server settings, manages environment variables, and sets up API proxies for the geospatial platform.

- Repository: [Bilawal Sidhu/gods-eye-view](https://github.com/bilawalsidhu/gods-eye-view)
- Tags: configuration
- Published: 2026-09-12

---

**The [`vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/vite.config.js) file serves as the central configuration hub that delegates to server-side settings, securely manages environment variables, registers API proxies, and defines tool schemas for the Gods Eye View geospatial platform.**

Gods Eye View is an open-source visualization and control system that relies on Vite for both development and production builds. The configuration file orchestrates runtime behavior by bridging server-side utilities with the client-side application, ensuring that sensitive credentials remain server-side while necessary runtime values flow securely to the browser.

## Central Configuration Delegation

The top-level [`vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/vite.config.js) acts as a thin wrapper that re-exports the full configuration from [`server/standalone/vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/server/standalone/vite.config.js). This architecture ensures that both the client bundle and the server-side development environment share a single source of truth.

According to the Gods Eye View source code, the root configuration file delegates all heavy lifting to the standalone server config while also exposing local provider modules:

```javascript
// vite.config.js
export * from './server/standalone/vite.config.js';
export * from './server/providers/local.js';

```

This pattern keeps the public API stable during refactoring and allows the main configuration to reside closer to the server implementation logic.

## Secure Environment Variable Handling

Inside [`server/standalone/vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/server/standalone/vite.config.js), the configuration loads the root `.env` file (or Pinokio store) and exposes a curated subset of variables to the browser via Vite’s `define` option. This technique keeps secrets such as API keys server-side while providing necessary runtime constants—like OpenAI model defaults and Google API keys—to client code.

As documented in [`CODE-BOUNDARIES.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/CODE-BOUNDARIES.md), this approach ensures that sensitive configuration never leaks to the client bundle, while still allowing client components to reference safe, build-time constants.

## Proxy Middleware and API Routing

The Vite configuration registers a comprehensive set of proxy endpoints that route front-end calls (`/api/...`) through the development server. These proxies unify access to external services and prevent credential exposure in browser code.

Key proxy endpoints defined in the configuration include:

- **`/api/realtime/token`** – Issues temporary authentication tokens for the OpenAI realtime API
- **`/api/setup`** – Handles key-setup flows and initial configuration
- **`/api/ais/live`** – Proxies Automatic Identification System (AIS) data for vessel tracking
- **CCTV and Overpass proxies** – Routes requests to surveillance and OpenStreetMap data layers

Client code consumes these proxies through standard fetch calls without handling authentication secrets:

```javascript
// src/data/aisLiveVessels.js
export async function getLiveVessels() {
  const r = await fetch('/api/ais/live');
  return r.json();
}

```

## Tool Schema Definitions

The configuration contains JSON schemas for 28 built-in **tools** that the UI can invoke, including `fly_to_location`, `set_layer_visibility`, and `control_cockpit`. These schemas are generated server-side and then made available to the client, allowing UI components to validate parameters and invoke functions correctly.

As noted in [`CURRENT-STATE.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/CURRENT-STATE.md), these twenty-eight tool definitions drive the interactive capabilities of the map interface:

```javascript
import { toolSchemas } from '../vite.config.js';

const flyToSchema = toolSchemas.fly_to_location;
console.log('Fly-to schema:', flyToSchema);

```

## Provider Module Exports

While the main configuration delegates to the standalone server file, the root [`vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/vite.config.js) also re-exports locally defined providers such as [`./server/providers/local.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/./server/providers/local.js). This keeps provider registrations explicit and accessible during the build process, supporting static analysis and tree-shaking.

Components like [`src/voice/voiceCost.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/voice/voiceCost.js) consume constants exported directly from the configuration:

```javascript
// src/voice/voiceCost.js
import { OPENAI_REALTIME_MODEL_DEFAULT } from '../vite.config.js';

async function fetchRealtimeToken() {
  const resp = await fetch('/api/realtime/token');
  const { token } = await resp.json();
  return token;
}

```

## Summary

- **[`vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/vite.config.js)** delegates to [`server/standalone/vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/server/standalone/vite.config.js) to maintain a single source of truth for client and server builds.
- The configuration loads root environment variables and selectively exposes them via the `define` option to keep secrets server-side.
- Proxy middleware routes `/api/*` endpoints to external services (OpenAI, AIS, CCTV) without exposing credentials to the browser.
- The file exports JSON schemas for 28 interactive tools (e.g., `fly_to_location`, `control_cockpit`) that validate client-side invocations.
- Provider modules and runtime constants are re-exported to maintain API stability during refactoring.

## Frequently Asked Questions

### Why does Gods Eye View separate the Vite config into a server-side file?

The separation allows [`server/standalone/vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/server/standalone/vite.config.js) to handle Node.js-specific logic—such as reading the filesystem for `.env` files and initializing proxy middleware—while the root [`vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/vite.config.js) simply re-exports these settings. This ensures that both `vite dev` and `vite build` operate against identical configuration logic without duplicating code.

### How does the configuration keep API keys secure?

The configuration reads sensitive keys from the root `.env` file or Pinokio store during build time and uses Vite’s `define` option to inject only necessary, non-sensitive values into the client bundle. Proxies handle all authenticated requests to external services (OpenAI, Google, AIS providers), keeping actual credentials on the server.

### What are the 28 tool schemas defined in vite.config.js?

According to [`CURRENT-STATE.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/CURRENT-STATE.md), the configuration defines JSON schemas for 28 interactive capabilities including `fly_to_location` (camera movement), `set_layer_visibility` (map layer toggling), and `control_cockpit` (device control). These schemas validate arguments before the UI invokes corresponding functions.

### How do I add a new API proxy endpoint?

Add the route definition to the proxy configuration object within [`server/standalone/vite.config.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/server/standalone/vite.config.js), specifying the target URL and rewrite rules. Client code can then fetch from the new `/api/*` path; the Vite dev server will forward the request to the appropriate upstream service while injecting necessary authentication headers server-side.