Best Practices for multiple environments and deployment?

What are the best practices for dealing with multiple environments (i.e., Development, Staging and Production)? For example, I’m developing locally with Docker Compose and using Postgres as the backing store. What’s the recommended way for deploying/promoting to another environment? I need to be able to move the workflow configurations into another environment with it’s specific ENV variables.

How should I handle the workflow configurations - in frameworks like Rails or Hasura there is the idea of migrations. In Hasura for example, whenever you make changes to configuration, Hasura updates a yaml metadata configuration file. Is there a way to do something similar with the n8n json files so that when starting up a n8n instance it ingests the json config files and sets up all the workflows?

Thank you

Hey, @ChaseP!
You can find out how to deploy to production using docker here.
You can also find the information on configurations here.
While you’re in the development, I would suggest you download your workflow after you build it. You can then use this workflow in production by pasting the JSON in the editor. This will add the workflow to your production instance of n8n with all your configurations. I would also suggest you make sure that you have the right credentials for your nodes.

I hope this helps.
Please let me know if you have any questions.

1 Like

Is there a way to do this programmatically (via API)? For example, read in the JSON configuration from the file system at application start (or based on a migration CLI command). Something like this is a necessity for multi-environment setups and CI.

Hey @ChaseP,

We currently don’t have a way to do this programmatically. You can start the workflow with the CLI (docs) but migration is not possible for now.

But this is a great idea, and I would appreciate it if you could put in a feature request for this.

Thanks!

1 Like

Sure, I added a request here:

1 Like