Skip to content
🚧 DMNO is still in beta! Use with caution!
✨ If you've tried DMNO or looked through the docs, let us know what you think!

DMNO quickstart

  1. Setup dmno in your project

    Run this command in the root of your project:

    Terminal window
    npx dmno init

    dmno init

    This will create a .dmno folder in the root of your project with a config.mts file, including config items in your schema that we automatically imported from .env files. If in a monorepo, any additional services of your choice will get their own .dmno folders, and config.mts files. It will produce a file tree that looks something like this:

    • Directory/ (root of your project)
      • Directory.dmno (your workspace config)
        • config.mts
      • Directorypackages
        • Directorymy-package
          • Directory.dmno
            • config.mts (config for my-package service)
        • Directoryanother-package
          • Directory.dmno
            • config.mts (config for another-package service)
  2. Start the development server

    This will give you instant feedback while you author your config schema.

    Terminal window
    npm exec -- dmno dev

    dmno init

  3. Write your schema

    The config schema and other settings live in the .dmno/config.mts files. dmno init does its best to scaffold out the initial version of this schema based on your existing .env files. Augmented each item with a description, required, and sensitive is a great next step. You can then improve your schema over time, adding validations, and setting values from within the schema itself.

    Check out the schema guide for full details.

  4. Configure framework specific integrations

    We provide drop-in integrations for many popular frameworks, and more are in the works. dmno init is smart enough to install the relevant integrations for each service. You can also read more about each integration on their respective pages and update them as needed.

  5. Use DMNO_CONFIG to access your config

    We recommend migrating to DMNO_CONFIG as it provides helpful improvements like TypeScript autocompletion and IntelliSense.

    For example:

    // 😿 still works, but no type-safety, and will be a string
    if (!process.env.SOME_NUMBER) {
    throw new Error('Missing SOME_NUMBER env var');
    const myConfigNum = parseFloat(process.env.SOME_NUMBER);
    // 🎉 easier, safer, full type-safety
    const myConfigNum = DMNO_CONFIG.SOME_NUMBER;
    const IS_PROD = DMNO_CONFIG.NODE_ENV === 'production';

    You could continue to use process.env/import.meta.env to access your config and still benefit from DMNO’s validation logic. But, DMNO_CONFIG gives you the full benefits of DMNO.