The BasicsSettings

In order to store settings and configuration for the application (e.g., API keys for third-party services), Pup relies on Meteor's settings.json convention. Stored at the root of the project, any file ending in .json and following a specific structure can be loaded on startup of the Meteor server as the settings file.

Update your product's name in the settings

By default, Pup ships with a set of placeholder values for your product name, the year your copyright should begin (i.e., the year you start work on your product), Twitter username, Facebook username, and mailing address (required for sending transactional and marketing emails). An example of this structure can be found below on this page.

It's recommended that you generate separate settings files for each environment that your application will run in. Further, unless prohibited by the third-party, its wise to generate separate API keys or tokens for each environment.

In Pup, by default the only settings file included is settings-development.json. In the project's .gitignore file (the file that Git uses to check which files it shouldn't commit to version control), two other presumed files are ignored: settings-staging.json (settings for your staging environment) and settings-production.json (settings for your production—or customer-facing—environment).

These latter files are in .gitignore because they contain potentially harmful data. Even if you're checking your code into a private repository, there's always the off-chance that an attacker could gain access to it, and subsequently, your keys. This is tolerable for your development keys, but not for staging or production as they could give unwanted access to user data.

The settings-<environment>.json naming convention is helpful for recognizing the settings that apply to each environment. You don't have to follow this, but it's best to do so as it's easy to get confused which file should be used where later.

Using the npm start command built into Pup
meteor npm start
Manually starting the server with a settings file
meteor --settings settings-taco-tuesday.json

Using settings in the app

Once loaded on startup, you can access the contents of your settings file via the Meteor.settings method.

Example Meteor.settings usage
import { Meteor } from 'meteor/meteor';

// Returns the entire settings object:
// { public: { /* ... */ }, private: { /* ... */ } }

// Returns only the public block.

// Returns only the private block.

// Example: retrieving the clientId value for GitHub

Settings template

The settings template presented here is identical to the one found inside of Pup. A few conventions to remain aware of:

  • Any values stored in the public block will be made accessible to both the client and the server.
  • Any values stored in the private block will be made accessible to the server only.
  • Any values stored in the root object (at the same level as the public and private properties) will be made accessible to the server only (a safety precaution on Meteor's part).

Under the public block, Pup includes a handful of configuration variables that globally set branding information for the app. These values are used throughout the UI of the app itself as well as in the email template located in /private/email-templates/base.html.

settings-<environment>.json template
  "public": {
    "productName": "Product Name",
    "copyrightStartYear": "2018",
    "twitterUsername": "product",
    "facebookUsername": "product",
    "productAddress": "1658 N. Milwaukee Ave., #393, Chicago, IL 60647"
  "private": {
    "MAIL_URL": "",
    "OAuth": {
      "facebook": {
        "enabled": true,
        "appId": "",
        "secret": "",
        "loginStyle": "popup"
      "google": {
        "enabled": true,
        "clientId": "",
        "secret": "",
        "loginStyle": "popup"
      "github": {
        "enabled": true,
        "clientId": "",
        "secret": "",
        "loginStyle": "popup"
    "supportEmail": "Customer Support <support@product.com>"