Environments

Your stellate.yml can define multiple environments, which allows you to configure different Stellate services for e.g. your staging and production environments.

Basics

Use the environments key in your configuration file to define the different environments of your API.

If you do not specify the --env flag for a call to the stellate CLI, we will only work with the default environment configured via the top-level name, schema, and originUrl keys.

stellate.ts →

import { Config } from 'stellate'

const config: Config = {
  config: {
    // defaults when --env is not specified
    name: 'my-app',
    schema: 'https://end.point',
    originUrl: 'https://end.point',
    environments: {
      // Use a separate service for staging, that points to your staging
      // GraphQL API. To push configuration to that environment, use
      // stellate push --env staging
      staging: {
        name: 'my-app-staging',
        schema: 'https://staging.end.point',
        originUrl: 'https://staging.end.point',
      },
    },
  },
}
export default config

You can then push your configuration to the different environments by specifying the --env CLI flag:

# Push your local configuration to the staging service
stellate push --env staging

Configuration for environments is combined via a shallow merge with the default environment. We recommend only overriding the name, schema, and original values.

If you override additional keys, keep in mind that only the information from that specific environment will be kept and you can not extend the configuration of the default environment this way.

CI workflow

Assuming you have a "staging" branch (of some sort) in your version control system, we recommend automatically pushing to your staging environment from that CI and to the default (i.e. production) environment on your main / master / trunk branch.

In pseudo-code, your CI configuration should do something like:

if ($BRANCH === "staging")
  stellate push --env staging
else if ($BRANCH === "main")
  stellate push