Environment & secrets

Put configuration where it is used: during the build, in a Node runtime, or in an App's backend.

Read the AI prompt before copying

Help me prepare my existing project for PhotonSpark Webhost using the guide below. Ask for the project requirements and deployment choice when missing. Inspect existing files before editing, preserve behavior and data, and do not invent supported flags or deployment options. Keep credentials out of code and prompts. Explain dashboard settings and test production behavior. Publishing, DNS changes, and destructive actions need my authorization. Report what passed and what remains unverified.

# Environment & secrets

Put configuration where it is used: during the build, in a Node runtime, or in an App's backend.

Source: https://webhost.photonspark.com/docs/environment

## Choose the right scope

- Site build: values consumed while building the artifact. Public framework variables can become part of browser JavaScript.
- Site runtime: values available to the running Node server. Static sites have no server process reading runtime variables.
- App frontend and backend: settings for the corresponding running component. Build values are separate.
- Public VITE_* or NEXT_PUBLIC_* values are not secrets. Changing a compiled public value requires a new build.

## Keep credentials out of source and prompts

Use Webhost's secret-value controls. Secret values are write-only after saving; masking is not a value to paste back into configuration. Preserve existing variables when making unrelated changes.

Never commit .env files, database URLs, API tokens, deploy private keys, or enrollment grants. Copyable documentation uses placeholders; fill them through the dashboard or a protected local input, not a shared AI transcript.

## Use the injected runtime settings

- Node Sites: respect HOST, HOSTNAME, PORT, NODE_ENV, HOME, and NPM_CONFIG_CACHE supplied by the runtime.
- Apps: use BACKEND_INTERNAL_URL for server-side frontend calls and FRONTEND_INTERNAL_URL for backend-to-frontend calls.
- Managed App PostgreSQL: use the supplied DATABASE_URL in the backend. Browser code calls your API rather than connecting directly to PostgreSQL.

- [App database and routing contract](https://webhost.photonspark.com/docs/apps#database)

Choose the right scope

Site build: values consumed while building the artifact. Public framework variables can become part of browser JavaScript.
Site runtime: values available to the running Node server. Static sites have no server process reading runtime variables.
App frontend and backend: settings for the corresponding running component. Build values are separate.
Public VITE_* or NEXT_PUBLIC_* values are not secrets. Changing a compiled public value requires a new build.

Keep credentials out of source and prompts

Use Webhost's secret-value controls. Secret values are write-only after saving; masking is not a value to paste back into configuration. Preserve existing variables when making unrelated changes.

Use the injected runtime settings

Node Sites: respect HOST, HOSTNAME, PORT, NODE_ENV, HOME, and NPM_CONFIG_CACHE supplied by the runtime.
Apps: use BACKEND_INTERNAL_URL for server-side frontend calls and FRONTEND_INTERNAL_URL for backend-to-frontend calls.
Managed App PostgreSQL: use the supplied DATABASE_URL in the backend. Browser code calls your API rather than connecting directly to PostgreSQL.

App database and routing contract