Quickstart guide

Current requirements

DMNO Config requires either of the following:

• node (>22.x) + either pnpm, npm, or yarn
• bun

Tip

While TypeScript is not required in your applications, you will get the full feature set (e.g., IntelliSense and inline docs) of DMNO by using it in a TypeScript project. Note that our config.mts files themselves are written in TypeScript, so you’ll want to use an editor that at least supports it.

1. Setup dmno in your project

   Run this command in the root of your project:

   npm

   npx dmno init

   pnpm

   pnpm dlx dmno init

   Yarn

   yarn dlx dmno init

   Bun

   bunx 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 scaffold using config items we find in .env files and in your source code. If in a monorepo, any additional services of your choice will get their own .dmno folders and associated files. Each .dmno folder looks something like this:

   • Directory/your-project

     • Directory.dmno

       • Directory.typegen/ (generated types)

         • …
       • .env.local (optional local overrides file, gitignored)
       • config.mts (your config schema)
       • tsconfig.json (dmno specific tsconfig)
     • … the rest of your files and folders

2. Run dmno resolve in watch mode

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

   npm

   npm exec -- dmno resolve -w

   pnpm

   pnpm exec dmno resolve -w

   Yarn

   yarn exec -- dmno resolve -w

   Bun

   bun run dmno resolve -w

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 but it should be reviewed. Updating 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.

   Your initial schema should look something like this:

   .dmno/config.mts

   import { DmnoBaseTypes, defineDmnoService } from 'dmno';
   
   export default defineDmnoService({
     schema: {
       PUBLIC_API_BASE_URL: {
         extends: DmnoBaseTypes.url,
         description: 'Base URL for the public API',
       },
       PUBLIC_GOOGLE_ANALYTICS_ID: {
         description: 'Google Analytics ID',
       },
       DATABASE_URL: {
         sensitive: true,
         extends: DmnoBaseTypes.url,
         description: 'Database connection string',
       },
       SECRET_API_KEY: {
         sensitive: true,
       },
       JWT_SECRET: {
         sensitive: true,
       },
     },
   });

   Check out the schema guide for full details.

   And if you would like more information on how we use .env files check out `.env’ file guide

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.

   In this case of Astro or Vite, the integrations should work out of the box. In other cases, like Node.js or Next.js, you will need to update your package.json scripts to use dmno run so that your resolved config is passed to the script in question.

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.

   Secrets & DMNO_PUBLIC_CONFIG

   While building code for the browser or another less-secure context, you can use the DMNO_PUBLIC_CONFIG object - it does not contain any items that are marked as sensitive: true in your schema