Plugins and Environment Variables
All of Mailchimp Open Commerce's features are provided by plugins, either first-party or third-party. This structure gives you complete control over what plugins and features are active in your installation. First-party Open Commerce services are distributed as Docker images, or can be customized and then built into your own Docker image.
Much of the platform-wide configuration of Open Commerce is set via environment variables—either to pass information from one service to another or simply to customize the platform to meet your needs. Some environment variable values are required, while others are optional. Each plugin should supply sensible defaults for required values, and the development platform's
make scripts automatically set up required
.env files for you.
This documentation outlines the plugins included in the development platform, as well as common environment variables and their functions. For more information about making data available throughout your Open Commerce installation, see the Sharing Code Between Plugins doc.
A wide range of first-party plugins covers all the basic platform features, including the API core, handling backend services, shop configuration, and the shopper experience. You can view a list of the plugins active in your instance in the admin dashboard under Settings > System Information.
The plugins included with the development platform are:
Manages internal accounts for shop operators and shoppers.
Validates shopper addresses during checkout.
A template for creating a new address validation plugin.
Connects the Identity service to the Open Commerce API.
Checks account permissions to allow or deny actions.
Handles shopping cart objects.
Handles product catalogs.
Handles discounting products.
Enables discount codes that shoppers can enter at checkout.
Sends transactional emails.
Manages the SMTP connection for outgoing transactional emails.
Provides transactional email templates that shop operators can customize.
Manages file uploads for a shop.
Handles internationalization options for a shop.
Tracks inventory counts for product variants.
Determines product availability status based on inventory counts.
Manages job queuing and execution.
Allows for the creation of hierarchical navigation in a shop.
Sends messages about order statuses.
Handles orders, including fulfillment groups.
Manages all payment methods for a shop.
A template for creating a new payment handler.
Processes payments with Stripe.
Enables setting prices on product variants.
Creates products and manages their information.
Manages shop settings like those available in the admin dashboard.
Handles shipment types, including allowing or denying shipment methods for products or orders that meet certain criteria.
Handles shipment types that always cost the same amount.
Allows creation and management of shops within an Open Commerce instance.
Implements SimpleSchema to validate data for MongoDB documents.
Creates sitemap files for search engines at a specified time interval.
Allows applying surcharges to a cart.
Provides information about the running instance of Open Commerce, including registered plugins.
Handles tag creation and organization.
Manages tax rates based on location, product type, and more.
Allows for setting a single tax rate.
Supplies translations of terms used in the API in over 20 languages.
You can set variables in each service's
.env file, which is used by Docker Compose when starting the system and loading plugins. Each Open Commerce repo contains a
.env.example file that lists the environment variables and default values for that project. You can run the
bin/setup script within the project to automatically copy the contents of
.env (although it will not overwrite existing values). Your
.env files will contain personalized and potentially sensitive information, so you should never commit them to a public GitHub repo.
In some cases, projects may look for additional environment variables that are not listed in
.env.example because they are optional and have default values set in the code. You can find these optional variables by searching for
cleanEnv within a Node project.
The following tables detail the environment variables used by the API core, storefront, and admin services.
Allow introspection of the GraphQL API.
Serve the GraphQL Playground at
The MongoDB connection string URL, including the name of the database you want to use.
Port to serve the API on.
Control how much is printed in the logs. Possible values, from most to least verbose:
Enable Apollo Federation support.
The registration URL to be used in new account invitation emails.
Enable GraphQL subscriptions over WebSockets.
Automatically initialize a MongoDB replica set on startup if one isn’t found.
Enable background job workers. If set to
Enable logging of jobs to the console.
The root URL (including protocol) for the API.
The secret key from your Stripe account dashboard. Required for using Stripe payments.
An SMTP URL (e.g.
Enable email plugin logging.
Transform internal IDs to opaque IDs using the
The URL for the storefront.
The canonical root public URL for your storefront.
A URL for creating a build outside of CI/CD.
The public GraphQL API URL used by Next.js.
The URL used by the frontend server to reach GraphQL for the build process.
Node environment designation, usually
Port to run the storefront server on.
The maximum age in milliseconds for the storefront session cookie, which is used for authentication.
A unique key for cookie session verification.
The public/client key from your Stripe dashboard.
An API URL that is accessible from browsers and accepts GraphQL POST requests over HTTP.
An API URL that is accessible from browsers and accepts GraphQL WebSocket connections. Enables GraphQL subscriptions on the client. The location is usually the same as
A full public URL that has
Required. A full public URL that has
Required. The URL for the storefront home page. This is only used as fallback if a storefront URL isn’t set within the admin dashboard.
The canonical root public URL for the admin server.
The port to run the Node server on. We recommend using
Allow MongoDB to use temporary files on disk.