Skip to Content
Genfeed Core (OSS)Configuration

Configuration

Genfeed has separate configuration entry points for source development and the Community container. Do not copy keys blindly between them.

Source development

The repository root .env.example is the canonical source-development template. Copy it, edit the root file, and then generate app/service environment files:

cp .env.example .env.local

At minimum, align the database and Redis values with the local Compose stack:

DATABASE_URL=postgresql://genfeed:genfeed_local@localhost:5432/genfeed
REDIS_URL=redis://localhost:6379

Add only the provider credentials needed for your work, then sync:

bun run env:sync local --prune-legacy

Root .env.local is the source of truth. Generated app/service .env files must not be edited by hand or committed.

The root template documents the current canonical key names, including service-specific ports, URL fields, storage settings, authentication, provider credentials, and optional integrations. It intentionally contains placeholders; replace only the values needed for your environment.

Community container

The checksummed release bundle reads .env next to its compose.yml; create it from the bundled .env.example:

cp .env.example .env

A repository source checkout uses the same template at docker/.env.example and reads docker/.env next to docker-compose.selfhosted.yml. The source Compose file still runs a published image; it does not build checked-out code.

The default boots one local workspace without a login wall. Provider keys are optional until you execute a generation path. Host port overrides use:

SELFHOSTED_APP_PORT=3000
SELFHOSTED_API_PORT=3010
SELFHOSTED_MCP_PORT=3014

Setting a license-key environment variable does not add hosted, Cloud-only product features to the Community image; it only unlocks the runtime billing gate for a licensed self-host (see Billing: one build, a runtime gate ).

Secret handling

  • Never commit .env, .env.local, provider keys, auth secrets, webhook secrets, or customer data.
  • Keep backend credentials out of NEXT_PUBLIC_* variables.
  • Use environment-specific secret management in hosted deployments.
  • Rotate a credential immediately if it appears in a commit, log, screenshot, issue, or pull request.

Optional Logo.dev fallback

Set LOGO_DEV_PUBLISHABLE_KEY to a Logo.dev publishable key (pk_…) to add a company-logo fallback when the website crawler cannot discover a logo:

LOGO_DEV_PUBLISHABLE_KEY=pk_your_publishable_key

Scraped and imported brand logos keep precedence. The fallback sends only the normalized public hostname to Logo.dev and requests a 128px PNG with Logo.dev’s monogram fallback. It does not add a provider request to brand creation. Missing credentials, private or malformed domains, and image-provider failures leave the existing Genfeed placeholder behavior intact.

Publishable keys may appear in Logo.dev image URLs by design; never configure a Logo.dev secret (sk_) key. Before enabling the fallback in production, review Logo.dev’s attribution requirements : commercial use on its free plan requires visible attribution, while paid plans remove that requirement. Self-hosted operators are responsible for the plan and attribution that apply to their deployment.

See also

Last updated on
Backlog GovernanceContributing