.env.sample

##########################################################################################
# Manifold Service Configuration
##########################################################################################

# The default configuration in this file is appropriate for running Manifold on ports in a
# development environment. See below for recommended configuration for running Manifold in
# a production environment.

# The default domain that users access Manifold at. The client and the API will both use
# this variable when full URLs are generated, for example in emails sent by the API.
# The Cable Websocket service will accept connections from this domain.
DOMAIN=localhost

# If SSL is enabled, the client SSR application will make secure requests to the API. When
# URLS are generated, Manifold will prefer HTTPS over HTTP. If you would like to force all
# requests to occur over SSL, enforce the redirect in the webserver (Nginx).
# ENABLE_SSL=1

# In development environemnts, you may be working with self-signed certificates. Setting
# this value to 0 will allow the SSR service to accept a self-signed certificate when it
# requests data from the API. This should only be enabled in development environments. In
# production environments, do not use self-signed certificates.
# NODE_TLS_REJECT_UNAUTHORIZED=0

# All three Manifold services can be configured to run on ports. In production, run the
# services on ports or sockets and proxy traffic using Nginx. If you change these ports,
# be sure to adjust the various URLs below.

# During development, with `yarn watch`, Manifold will also listen on the port that is one
# port higher than CLIENT_SERVER_PORT. In development, we move the SSR to that second port
# and run a persistent service on CLIENT_SERVER_PORT that proxies to the SSR. This allows
# us to restart the SSR service in the background when code changes, without having to
# completely shut down the application.
API_PORT=3020
API_CABLE_PORT=3021
CLIENT_SERVER_PORT=3010

# All three Manifold services can also be configured to listen on unix sockets. The paths
# can be absolute paths, or relative to the /api and /client directories in the Manifold
# source, depending on the service. Each service can listen on a socket _and_ a port,
# which can be useful for hte API service, because it received requests from the browser
# and from the SSR service (a node service running on the server). It may make sense to
# use a port for requests from the same server rather than passing the request through a
# reverse proxy.

# API_SOCKET=tmp/sockets/manifold-api
# API_CABLE_SOCKET=tmp/sockets/manifold-cable
# CLIENT_SERVER_SOCKET=tmp/sockets/manifold-client

# The API services can be instructed to bind to a specific IP address. By default, these
# services will listen on all addresses on the local machine.

# API_BIND_IP=0.0.0.0
# API_CABLE_BIND_IP=0.0.0.0

# The URL that the client should be accessed at by default. If this is not set, Manifold
# will use the domain env var to location the client. However, if Manifold is being
# accessed on a port, generally during development, then the API needs to know to use the
# client + port in certain cases (eg, OAuth callbacks, email links, etc). In production,
# Manifold should be access through a single domain with nginx acting as a reverse proxy.
# In that case, this env var is not necessary.
CLIENT_URL=http://localhost:3010

# The URL that the browser will use for the Manifold API. If unset, CLIENT_BROWSER_API_URL
# defaults to the DOMAIN variable above. When the browser javascript bundle is created,
# this variable is written to dist/manifold/www/browser.config.js. The browser application
# consumes this value from browser.config.js, because it does not have access to the
# server-side environment.
CLIENT_BROWSER_API_URL=http://localhost:3020

# The URL that the browser will use for the Manifold API Cable Service. If unset,
# CLIENT_BROWSER_API_CABLE_URL. As with CLIENT_BROWSER_API_URL, this variable is copied
# into dist/manifold/www/browser.config.js during the build process to be served to the
# browser application.
CLIENT_BROWSER_API_CABLE_URL=http://localhost:3021

# The URL that the SSR node service will use to access the API for the server-side render.
# In many cases, this can be the same as the CLIENT_BROWSER_API_URL. However, in some
# cases, the API and the SSR service may be on different servers on the same network, and
# use a different address for communication than the user's browser.
CLIENT_SERVER_API_URL=http://localhost:3020

# The API needs to know where to reach ElasticSearch. If you're in development, you're
# probably running our quick and dirty ElasticSearch service through the `manifold start
# elasticsearch` command. If that's the case, it's listening on port 29200. On a stock
# ElasticSearch installation, it will be listening on port 9200.
ELASTICSEARCH_URL=http://127.0.0.1:29200

# If we are not running a reverse proxy, some client routes need to be proxied to the API.
# If CLIENT_SERVER_PROXIES is set to true, the server-side node application will proxy
# some paths to the API and to the browser build folder. Generally speaking, this should
# not be used in production.
CLIENT_SERVER_PROXIES=true

# In a production environment where you're running Manifold on a single host, you should
# put a reverse proxy in front of it and run each service on sockets. We enthusiastically
# recommend Nginx for this, and there is sample nginx server configuration in our
# documentation. Assuming nginx is proxying paths to the correct services, which are
# running on sockets, your production services configuration would look like this:

#DOMAIN=manifold.lvh
#SSL_ENABLED=true
#API_SOCKET=tmp/sockets/manifold-api
#API_CABLE_SOCKET=tmp/sockets/manifold-cable
#CLIENT_SERVER_SOCKET=tmp/sockets/manifold-client

##########################################################################################
# Manifold API Configuration
##########################################################################################

# The API service and the API_CABLE service both serve the Rails application that is the
# Manifold backend. Almost all requests from the client are to the API service. The
# API_CABLE service is a Rails ActionCable server (websocket), which is primarily used for
# Text Ingestion.

# In production, set this to "production". During development, set it to "development"
RAILS_ENV=development

# You should set a unique secret key for every Manifold instance. You can generate this
# key from the command line by running `./bin/rails secret` from the api directory in the
# Manifold source.
RAILS_SECRET_KEY=

# Generally speaking, Manifold's configuration is stored in the database and can be
# adjusted through the backend interfaces. In some cases, however, it's desirable to
# manage settings through the environment. If the following variable is set to true, you
# can update settings from environment variables when Manifold starts up.
# MANAGE_SETTINGS_FROM_ENV=

# The format for thse variables is the full path to the setting in the setting object,
# prepended by "manifold_setting," and upper cased. If you're not sure about the structure
# of the settings object, fire up a rails consle (`rails console` in the API directory)
# and take a look at the settings object by running `Settings.instance`. For example:

# MANIFOLD_SETTING_INTEGRATIONS_GOOGLE_PROJECT_ID=
# MANIFOLD_SETTING_THEME_TYPEKIT_ID=
# MANIFOLD_SETTING_CONFIG_GOOGLE_SERVICE=

##########################################################################################
# Manifold Client Configuration
##########################################################################################

# In production, set this to "production". During development, set it to "development"
NODE_ENV=development