Credentials & environment
Organization-scoped tokens, readable environments, and a persistent encryption key.
Organization repository tokens
Credentials have separate use/create/update/delete grants. Select the organization, host and token on Credentials. Tokens are encrypted and never returned by credential APIs. A blank token when editing retains the old secret. A credential in use cannot be deleted or moved to another organization; change project bindings first. Organization defaults do not grant Git-provider permissions.
Edit application environment
env.read reveals real values; env.write permits replacement independently. A write-only member cannot fetch existing values. The editor supports whole-file and row views and uploads up to 128 KB. Uploaded keys merge into the draft; review and save. Changes apply on the next deployment. KEY= means empty; removing a key deletes it. Use unique uppercase/digit/underscore names that do not start with a digit; no export or multiline values.
Keep the encryption key
HOSTMGR_SECRET_KEY protects encrypted state. Keep it together with the state backup; replacing it makes existing encrypted values unreadable. Never paste secrets into issues, screenshots or public logs. Provider tokens should be scoped to the repositories and read permissions the team needs.
Empty Worker environment
A Worker may have no user environment variables. Portal creates a restricted empty environment file for its service. It does not inject PORT/HOST for a Worker; you can still supply those names if your own application needs them. Web projects retain their environment and HTTP configuration requirements.