Legend

Configuration

After Legend is running, a few configuration areas let you tailor the instance to your organization. Most low-level settings are provided as environment variables to the container, while instance-level preferences live in the admin settings once you are signed in. The variable names below are examples that follow common conventions; use the exact names from your release documentation.

Core environment variables

These are the settings you almost always provide at deploy time:

  • DATABASE_URL # connection string for your database
  • APP_URL # the public URL, e.g. https://legend.example.com
  • SECRET_KEY # a long random string used to sign sessions
  • LICENSE_KEY # paid plans only; omit on the Community tier
  • Set APP_URL to the exact external URL, including https, so links and redirects are correct behind your proxy.
  • Generate SECRET_KEY once from a secure random source and keep it stable; changing it invalidates existing sessions.
  • Store all of these as secrets in your deployment platform rather than committing them to a repository.

Instance settings

Instance settings control how your deployment presents itself and behaves. Review these once during setup and revisit them when something about your environment changes.

  1. Sign in as an administrator and open the settings area.
  2. Set the instance name and any display preferences so it reads as part of your organization.
  3. Review access defaults so new users get the right level of access.

Email

Configure outbound email if your instance sends invitations, password resets, or notifications. Email is delivered through an SMTP server you provide.

  • SMTP_HOST # your mail server hostname
  • SMTP_PORT # commonly 587 for STARTTLS
  • SMTP_USER # the sending account
  • SMTP_PASSWORD # the sending account password or token
  • SMTP_FROM # the From address, e.g. legend@example.com
  1. Provide the SMTP settings as environment variables or in the admin settings, matching your release.
  2. Use a dedicated sending account rather than a personal mailbox.
  3. Send a test message, for example a user invitation, and confirm it arrives.

Storage for uploads

If your instance stores uploaded files, decide where those files live. On a single server, a persistent volume mounted into the container is the simplest choice. On a container platform, use a persistent volume or an object store that survives restarts and redeploys.

  • Mount storage on a volume that is included in your backups, not on the container’s ephemeral filesystem.
  • If you use object storage, keep its credentials in your secret store alongside the database credentials.
  • Verify after a redeploy that previously uploaded files are still present.

Screenshot: the admin settings area showing instance name, email, and storage configuration sections.

Branding

Branding options let the instance look like part of your organization rather than a generic tool. The options available depend on your plan; see the Licensing page for what is included at each tier. Where custom logos or theming are supported, set them in the admin settings after signing in.