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!

Incremental adoption

Because of the way DMNO is designed you can adopt it incrementally, both in terms of the services you use it with and the features you use within those services.

A few different options

There are a few different ways you can adopt DMNO incrementally:

Service by service:

  • You can start by adding DMNO to a single service, and then gradually add it to more services as needed. If you’re in a monorepo, it’s best to start with some root config and then incrementally add a service at a time.

Feature by feature:

In your code:

  • We will support your existing methods of using env vars (e.g., process.env in Node.js, import.meta.env in Vite, etc) while you migrate to DMNO, by reinjecting your resolved config items as strings. You won’t get type completion, full IntelliSense, and you won’t get an error if you try to access a variable that doesn’t exist, unfortunately.
  • Once you’ve added DMNO to your project, you can start using the DMNO_CONFIG/DMNO_PUBLIC_CONFIG object in your code to access your config items. This will give you full type completion and IntelliSense, and actionable error messages if you try to access a variable that doesn’t exist or fails validation.
  • You can use dmno run to run your services with DMNO, and use dmno dev while you’re actively working on your schema and your apps/services will autorefresh when you make changes to your schema.