erxes/.env.sample at main · erxes/erxes

Repository navigation

History

# REACT_APP_API_URL=http://localhost:4000

# NODE_ENV=development

# MONGO_URL=mongodb://localhost:27017/erxes

# NODE_OPTIONS=--max-old-space-size=1536

# ENABLED_PLUGINS=operation

# DISABLE_CHANGE_STREAM=true

# --- Sentry: backend API services (environment e.g. production-api / amaraa-test-local) ---

# SENTRY_DSN=api_sentry_dsn

# SENTRY_ENVIRONMENT=api_sentry_environment_name

# SENTRY_TRACES_SAMPLE_RATE=0.1

# --- Sentry: frontend (core-ui host + MF remotes). In prod, docker-entrypoint.sh

# injects any REACT_APP_* var into window.env at container start. ---

# REACT_APP_SENTRY_DSN=ui_sentry_dsn

# REACT_APP_SENTRY_ENVIRONMENT=ui_sentry_environment_name

# RELEASE_VERSION=erxes-<git-sha-or-version>

# --- SaaS welcome screen support messenger ---

# On SaaS deployments (organization.type=saas) the welcome screen embeds the

# public messenger widget (window.erxesSettings.messenger.integrationId) so a

# visitor can reach the support team from inside the app.

# REACT_APP_SUPPORT_MESSENGER_INTEGRATION_ID=<integration _id>

# Origin serving messengerBundle.js. Left unset it falls back to the gateway.

# Point SaaS tenants at the operator's widgets host so the widget connects to

# the deployment owning that integration.

# REACT_APP_WIDGETS_URL=http://localhost:4000

# --- Point-in-time revert (undo) — auto-capture journal ---

# Every update/delete made through any model is journaled to {subdomain}_logs

# so it can be reverted later (System Logs → Undo). Creates are NOT captured —

# reverting a new record is just deleting it. Capture is ALWAYS ON: there is no

# enable flag — it runs from boot on every service that writes through erxes-api-shared

# (core-api, plugins, ...). The logs-service must also be running for the journal

# entries to actually be persisted. The only tunable is the per-write snapshot cap:

# REVERT_AUTO_JOURNAL_MAX=1000 # max docs snapshotted per bulk delete/update;

# # beyond this the ids are still audited but

# # the overflow is not auto-revertable.

# --- Gateway address used inside emails (unsubscribe links, webhooks) ---

# In production ingress serves the gateway under `/gateway` on DOMAIN, so this

# stays unset. Set it when the gateway is reached directly — locally, or through

# a tunnel — because that prefix does not exist there.

# GATEWAY_URL=http://localhost:4000

# --- Frontline mail integration (Cloudflare Email Routing -> Worker -> /mail/receive) ---

# Catch-all domain the generated inbox addresses live under. It must match the

# Email Routing zone the mail worker is deployed on, and that zone's MX has to be

# Cloudflare's alone — a domain already carrying another provider's mail (erxes.io

# on Google Workspace, say) cannot be onboarded, and a subdomain of it cannot

# either, because Cloudflare only serves subdomains once the apex is onboarded.

# MAIL_DOMAIN=erx.es

# Public origin of the mail worker. Only the Settings → integration "check

# connection" action calls it; inbound mail never depends on it. Left unset, that

# action reports that it is not configured instead of probing a wrong host.

# MAIL_WORKER_URL=https://<the-deployed-mail-worker-origin>

# Master HMAC secret for the inbound webhook. Neither side signs with it directly:

# both derive HMAC-SHA256(MAIL_WEBHOOK_SECRET, tenant), so a payload signed for one

# tenant is rejected by another. On a deployment the worker reaches through its

# endpoint template this is the worker's own WEBHOOK_SECRET; an install registered

# in the worker's MAIL_ROUTES namespace uses the secret stored in its entry instead.

# MAIL_WEBHOOK_SECRET=<shared-with-the-mail-worker>

# The tenant this deployment answers as. Generated addresses carry it as a prefix

# (`<tenant>--support-a7f3k2@...`) and the signature is derived from it. When

# VERSION=saas it is ignored — the organization subdomain of the request is always

# used, so one static value can never collapse every tenant. On a single-tenant

# install set it to the tenant its MAIL_ROUTES entry is keyed by (or, on a worker

# dedicated to this install, to the same value as that worker's DEFAULT_TENANT), or

# the two sides derive different keys and every delivery is rejected with 401.

# MAIL_TENANT=<single-tenant-installs-only>

# --- How replies leave ---

# Mail leaves through Cloudflare Email Sending, never through SES or SendGrid. A

# workspace that has connected its own Cloudflare account replies from its own

# zone; every other workspace replies from its inbox address on MAIL_DOMAIN,

# through the deployment's Cloudflare account below.

# Onboard MAIL_DOMAIN under Compute & AI → Email Service → Email Sending on that

# account once — it needs a Workers Paid plan — and give the token Account ·

# Email Sending · Edit. Left unset, only workspaces with their own Cloudflare

# account can reply, and the add-inbox wizard says so at its sending step.

# MAIL_SENDING_ACCOUNT_ID=<cloudflare-account-id>

# MAIL_SENDING_API_TOKEN=<cloudflare-api-token>

# Replies a single workspace may send per day through that shared account. Set to

# 0 to disable the cap — on a shared deployment that lets one workspace spend the

# sending reputation, the daily quota and the suppression list of every other one.

# MAIL_SENDING_DAILY_LIMIT=500

# Inbound messages accepted per inbox per minute; beyond it the webhook answers

# 429 and the worker retries. Set to 0 to disable the limit.

# MAIL_INBOUND_RATE_LIMIT=120

# Public url the mail worker posts inbound mail to. Left unset it is derived from

# DOMAIN, which is right for a normal deployment. Set it when the plugin is reached

# on a different host than DOMAIN names — locally that is a tunnel pointed straight

# at frontline_api, for example

# MAIL_RECEIVE_URL=https://<your-tunnel>.trycloudflare.com/mail/receive

FilesExpand file tree

.env.sample

Latest commit

History

.env.sample

File metadata and controls