File-based environments and scoped structured variables.
ServerChirp manages application environment settings in one of two ways: PHP applications use a server-side .env file, while every non-PHP runtime uses encrypted structured variables with separate build and runtime scopes.
PHP applications edit the .env file in the application's project root. ServerChirp reads and writes that file through the outbound agent, preserves its complete text, and saves it with mode 0600 as the application user.
Authorized team members can read the file in the dashboard. Treat access to this screen like access to the server itself: the file can contain plaintext secrets.
Saving replaces the complete file, so review changes before applying them. Restart or redeploy processes that need to reload its values.
Application types with structured environment variables store each value encrypted in ServerChirp. Read responses contain the key, scope, and metadata but not the plaintext value. Leaving an existing value unchanged preserves the saved secret; replacing it requires submitting the complete new value.
Use the narrowest scope. A registry token needed only for dependency installation should not remain in the runtime process environment.
Enter structured variables individually or paste a dotenv-style block:
APP_ENV=production
APP_DEBUG=false
DATABASE_URL="postgresql://app:password@127.0.0.1/app"
REDIS_URL=redis://127.0.0.1:6379/0The bulk editor accepts dotenv-style keys and values. Review the parsed variables and their scopes before saving them.
Structured environment changes affect future builds or runtime starts according to their scope. Restart or redeploy the application when a running process must read the new value. A build-only change requires a new deployment.
Avoid putting secrets directly in deployment hooks, repository files, or command output. Use the environment system appropriate for the application type or the dedicated private-package credentials.