appsmith
appsmith copied to clipboard
[Feature] Multiple Environments
Summary
Applications need to hit different API URLs with varying parameters when run during production and when run as staging. A way globally configure the correct parameters within the application based on the environment would be useful.
I suggest create a global environment setting section for each page. This global environment variable section can be a JSON configure or anything that allows user to put both credential for UAT and production. Another solution could be similar to that of retool, for each connection, have a tab to switch between production and UAT.
@hiphop101 I'm thinking at a Datasource level makes sense because the variables for Staging / Prod will largely be the same across an organization. We can also introduce a generic Store data source where non-database specific values and secrets can be saved.
@Nikhil-Nandagopal yes, attached a screenshot of retool. I think they also did it at data source level

Would love to have this feature soon. Cannot think of any other easy way to swap out databases in AppSmith while keeping the application.
Some ways in which it helps us devs:
- We can make dashboards while working on a feature in
dev/stagingenvironment, and those are then production-ready for content/product team automatically. - Debugging and replicating issues on dev/staging become much easier.
If possible I'd like this feature prioritised to be implemented sooner. In my use case I'd want to fetch data from multiple Shopify stores, It'd be helpful if I can save the API key & App Secret for a particular store somewhere and pass it in requests whenever we make a call to fetch data.
Retool has actually bungled this IMO. They started off right, but didn't add more than 2 environments...
Here are some other people who are not happy about being limited to two environments. Including a longer rant by me.
https://community.retool.com/t/ability-to-create-more-environments/2048
@ericwooley thanks for chiming in! We'll definitely have a more generic implementation here We're currently building a git sync feature where you'll be able to configure a separate datasource on every branch.
Just to add to this discussion, since I've brought up similar but different issues elsewhere previously... I think it would be great to have a hierarchy of special config variables that could get overridden at different levels. For example, it would be great if, like Hasura, you could define server-level environment variables which you could then use in an app in AppSmith. Then, it would be great if you could override those at the organization, and app levels.
Maybe that's overcomplicating things in some ways, but in others I think it would simplify them. If we just have "configuration variables" as a higher level system, then you wouldn't need to create a separate system specific to datasources for managing environments: servers, organizations, and apps can already be used to manage environments.
This would also help with another problem that we have, which is using weird workarounds to check the url to check if we're in staging or prod to change things in JS Objects to deal with API endpoints. If there was a special "config" object that could be modified at the server/org/app level that was usable in datasource configuration as well as elsewhere in apps, that would be so so helpful.
I was just thinking, Can we have an Environment file for each environment like env_dev.properties, env_prod.properties and load that when we deploy ?
@SidHiremath with Git Import, you will be able to have 2 organizations that have prod / staging datasources and you can easily deploy your application with those. This feature however is to let a developer quickly switch between pod and staging versions of those data sources on any branch.
@SidHiremath with Git Import, you will be able to have 2 organizations that have prod / staging datasources and you can easily deploy your application with those. This feature however is to let a developer quickly switch between pod and staging versions of those data sources on any branch.
It might be good to have the env properties defined in the apppsmith for each environment and while deployment we should override the configurations according to the environment.
Also. as a developper, we should not have access to production system, so it should be part of deployment process to change the configurations and we should have some comand to pass those properties.
@SidHiremath we will definitely support an env file that can be uploaded but It may not be from the file system because multiple organizations can be there in a single instance of Appsmith. So we will allow admins to upload an env file that can be read by developers
Hello users,
I am part of the team that is considering building this feature, and would love to hear about your expectations from multiple environments. Here's my calendly link for a short call, looking forward to hearing from you! :)
Thanks, Rohan
@rohan-arthur
I don't have time for a calendly, but retool just released multiple environments, in case you are unaware, I'd check theirs out as well.
We got a new request for this.
User wanted to have deployment stages that work against DataSources (DynamoDB) that are specific to the deployment stage (different AWS accounts) 🔗 Intercom
I have a use case for this as well.
We have a sales funnel / CRM app with an Appsmith + Supabase stack.
We decided we wanted each company we sign up to have their data segregated, so they have a different Supabase instance. Each instance has a different api url.
We could use multiple environments to create a dev, prod-company1, prod-company2 ... etc
@ZackKnopp it sounds like you want to add environments on the fly which isn't something we're planning to tackle right now, each environment will need to be configured by a developer in the application.
@ZackKnopp it sounds like you want to add environments on the fly which isn't something we're planning to tackle right now, each environment will need to be configured by a developer in the application.
I think it would work because we'd configure it manually for any companies we add.
We won't really roll it out to more than 10 companies max, since it's built for internal companies that our small investment company owns. And it's a big change from trying to manage many sales funnels in google sheets which are really easy for users to break.
I wasn't aware this topic existed already when asking on Discord. As I am not using git at this stage I like simple and obvious solutions (and am grateful that appsmith has lots of those...).
There is already a selector for datasource on each query editor page - I could imagine that a functionality that replaces the datasource on each query / page might not be overly complicated (hoping to get this feature soon).
To cover also apps that use more than one datasource, perhaps a simple array might do (with some extra coding effort):
[
{"production": "MyDB", "test":"MyDB-Test"},
{"production":"MyOtherDB", "test":"MyOtherDB-Test"}
]
@ralfwenske we're currently working on this solution. Would you be up for a quick chat to have a look at what we're building? You can block some time on my calendar below https://calendly.com/appsmith-nikhil/30min?back=1&month=2022-10
Sure Nikhil, chat via email? I am on +10 (Australia) so 8 hours different to you?
From: Nikhil Nandagopal @.> Sent: Tuesday, October 4, 2022, 20:25 To: appsmithorg/appsmith @.> Cc: ralfwenske @.>; Mention @.> Subject: Re: [appsmithorg/appsmith] [Feature] Multiple Environments (#2836)
@ralfwenske https://github.com/ralfwenske we're currently working on this solution. WOuld you be up for a quick chat to have a look at what we're building?
— Reply to this email directly, view it on GitHub https://github.com/appsmithorg/appsmith/issues/2836#issuecomment-1266733883, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOLOLXPZ6BMF7WRWTZPJCTWBQA2NANCNFSM4XAI7URQ. You are receiving this because you were mentioned.
Hi @Nikhil-Nandagopal, @rohan-arthur, Is there documentation somewhere about working around this, e.g. via the git sync?
@dgorshkov you can check this post out on how to achieve this
@Nikhil-Nandagopal which post?
@dgorshkov Oops! Forgot to add the link. Here you go https://community.appsmith.com/t/is-there-the-ability-to-switch-between-production-and-develop-datasources/702/2?u=dancia
@Nikhil-Nandagopal Unfortunately I wasn't able to make that video properly (multiple browsers and video players).
Posting an update for this feature -
What is in scope?
- Ability to configure staging and production environments for datasources
- Ability to switch between staging and production environments while editing the app
- Ability to view the deployed version of the app with staging environment configuration, without impacting the actual deployment
- Ability to define role based access controls for the staging and production environments
What is out of scope?
- Ability to add new environments (apart from staging and production)
Designs
Timeline for availability January 2023
If you have any questions regarding this feature, please feel free to reach out to me. You can find my calendar here -> https://calendly.com/balaji-gopinath/appsmith-user-interview
@sribalajig Good news, but I'm curious as to why you can't have environments other than staging and production? According to this discussion on the Retool forum, it's quite a useful feature https://community.retool.com/t/ability-to-create-more-environments/2048/39
@kshep92 thanks for sharing. We are aware that having custom environments is useful. We have this item on our roadmap, it is just that it will not be a part of our first release.
Hi guys, any update on this feature? also, panning to be part of the community edition or enterprise?