Moped Documentation
  • Welcome 👋
  • User Guides
    • Getting started
    • Map a project
  • Product Management
    • User communication
    • User management
    • User analytics
    • Local testing
    • Release process
    • Patch release process
    • MUI X Pro License
    • Integrations
      • Dataset documentation
      • ArcGIS Online
      • eCapris
      • Power BI
    • Features
  • Dev Guides
    • DB Docs & Data dictionary
    • Database backup policy
    • Moped Read Replica
    • How-to's
      • How do I start the Hasura cluster locally?
      • How do I launch the Hasura Console?
      • How do I get a JWT token?
      • How to ping the GraphQL API
      • How to ping the REST API
      • How do I connect a database with Postgres GUIs?
      • How do I connect to the RDS instance?
      • How to load production data into a local instance
      • How do I update seed data?
    • Hasura
      • Hasura Roles
      • Hasura Migrations
        • Getting Started
        • Installing the Hasura CLI
        • Configuration Files
        • Hasura Migration Principles
        • The Migration file format
        • Development
        • Hasura Seed Data
        • Running the Hasura Cluster Locally (video)
        • Create a migration: Exercise 1 (video)
        • Create a migration: Exercise 2 (video)
        • Latest hasura-cluster features
    • User Management
    • Authentication
      • Authentication Architecture
      • DynamoDB & Cognito
      • Secrets Manager & Cognito
      • Hasura & Cognito
      • React & Cognito
      • Flask API & Cognito
      • Single Sign-On with CTM
    • Code organization
    • API
      • Configuration Files
      • Testing
      • User Management API
    • Maps and geospatial data
      • Access tokens and API keys
      • Map libraries
      • Map data
      • Map styles
      • Map layers and basemaps
      • React patterns
      • V1 Archive
        • Map libraries
        • Map data
        • Map custom hooks
        • Map styles
        • Map layers and basemaps
    • UI access control
    • Design system
      • Branding
      • Component styles
      • Text content
    • Activity Log
      • Architecture
      • GitHub Actions and Deployment of Updates
      • Hasura Event Logs and Truncate Cron Job
      • Authentication
  • See also
  • Get Moped support, report a bug, or request an enhancement
  • Data & Technology Services
  • Github repository
Powered by GitBook
On this page
  • What is a configuration file?
  • The local configuration file
  • Production & Staging configuration files

Was this helpful?

  1. Dev Guides
  2. Hasura
  3. Hasura Migrations

Configuration Files

After you have installed the CLI, you will need to configure the different environments.

PreviousInstalling the Hasura CLINextHasura Migration Principles

Last updated 4 years ago

Was this helpful?

What is a configuration file?

Think of the Hasura CLI as a command-line database client. Normally, with database clients you need to provide the URL of the database, the name of the database you want to use, the user you want to authenticate as, etc.

In this sense, Hasura is no different. It also needs to know where the Hasura servers are and it needs to be able to authenticate (among other things). To accomplish this, Hasura provides different mechanisms .

Context: The configuration files are generated by running the hasura init command, this is not necessary for you, since we already have created them for this project.

The local configuration file

There can be one configuration file for each environment, but we only need to have one file called config.yaml which is in the moped-database root directory. It follows the following format:

version: 2
endpoint: http://localhost:8080
metadata_directory: metadata
actions:
  kind: synchronous
  handler_webhook_baseurl: http://localhost:3000

Production & Staging configuration files

The name would stay the same (config.yaml) but there would be some differences in the contents of that file, in staging for example:

version: 2
endpoint: https://moped-graphql-staging.austinmobility.io
metadata_directory: metadata
admin_secret: <secret_here>
actions:
  kind: synchronous
  handler_webhook_baseurl: https://moped-graphql-staging.austinmobility.io

Please note that this is for documentation purposes only, you may take a look to staging or production, but under no circumstances you need to make changes directly to staging and production, this can cause the environments to be out of sync and break the migrations system, you would be in the hook for a serious headache and the users would be unable to use moped.

including env files and CLI flags, but our choice is to use YAML files