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


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.

# Defaults when --env is not specified
name: todo-api-prod
schema: https://todo.app/api
originUrl: https://todo.app/api

  # Use a separate service for staging that points to the 
  # staging schema and origin 
    name: todo-api-staging
    schema: https://staging.todo.app/api
    originUrl: https://staging.todo.app/api

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

Did this page help you?