Configuration Reference

This page is a public-safe summary of the operator-facing configuration categories Keel applies to the hosted runtime. It is for security and procurement review of how the hosted service is configured, not a guide to running Keel yourself.

Current configuration areas

• application mode and environment hardening
• database connectivity and migration prerequisites
• runtime auth and project API-key behavior
• provider-key encryption and outbound provider access
• billing and Stripe integration
• job callback secrets and freshness enforcement
• tracing, diagnostics, and observability toggles

Minimum production configuration

This section summarizes the minimum categories operators must understand for a non-dev deployment. It is intentionally not a full environment-variable dump.

Application and database baseline

• APP_ENV must be set to a non-dev value for production behavior
• DATABASE_URL must point at the runtime database, and migrations must be applied before startup

Required non-dev security settings

In non-dev environments, the settings model currently refuses to start unless the following categories are configured:

• provider key encryption: KEEL_PROVIDER_ENC_KEYS or legacy KEEL_PROVIDER_KEY_ENC_KEY
• async payload encryption: KEEL_ASYNC_PAYLOAD_ENC_KEYS
• client API-key HMAC secret: KEEL_CLIENT_KEY_HMAC_SECRET
• stream token signing key: KEEL_STREAM_TOKEN_SIGNING_KEY
• permit binding key: KEEL_PERMIT_BINDING_KEY
• job webhook signing secret: KEEL_JOB_WEBHOOK_SECRET

Request freshness is a hardened non-dev default:

• if APP_ENV is non-dev and KEEL_REQUIRE_REQUEST_FRESHNESS is unset, Keel enables request freshness automatically
• if APP_ENV is non-dev and KEEL_REQUIRE_REQUEST_FRESHNESS=false, startup fails closed
• permit-creation freshness (KEEL_REQUIRE_PERMIT_FRESHNESS) follows the same rule, so hosted Keel requires both on every permit-creation and execution request; see Request Freshness

Non-dev startup also hardens some defaults automatically or refuses unsafe settings, including disabling auth debug logging. API keys stored under the legacy hash format are always rejected; there is no setting that re-enables them.

Runtime execution and provider access

Operators should explicitly review:

• proxy-route exposure, controlled by KEEL_PROXY_ROUTES_ENABLED
• platform-wide execution disablement via KEEL_EXECUTION_DISABLED
• provider pricing JSON for any provider or model that must pass pre-dispatch pricing checks
• provider-key encryption key ring material needed to decrypt project-scoped provider credentials at runtime; new writes use the active key, older ciphertext remains decryptable while its key id stays in the ring, and rewrap is opportunistic on use or manual via CLI rather than a scheduled background rotation job

Billing and external integrations

Only configure these categories if the deployment uses the related surfaces:

• user JWT configuration for dashboard and user auth flows
• Stripe secret, webhook secret, and checkout URLs for billing and checkout flows
• CORS and dashboard CSRF allowed origins for deployed operator frontends

Policy configuration

Project policy overrides via PATCH /v1/projects/{id}/policy are a legacy configuration surface. The primary policy configuration surface is POST /v1/policies/, which accepts PolicyDocument objects with condition trees and rule-based actions. Project overrides continue to work and are compiled to equivalent policy rules at runtime.