The dashboard used to allow you to set a local development value for each environment var for nhost env pull to work for nhost-cli development. I no longer see the ability to set those local values so how is it supposed to work now? our workflow used to be using nhost env pull to get new vars for development so everyone on the team could stay in sync so we need help understanding what the replacement workflow is (or if this is a bug, can it be added back?)

can anyone help with this? the lack of being able to set the local value is impeding our team workflow

unfortunately this feature won't be supported anymore. Not like this anyway. We could've done a better job at communicating and removing the functionality from the CLI but we kinda lost track of it as we revamped some internal systems in preparation to release the new config functionality that will ensure cloud and cli look exactly the same

for now what you can do is to commit the .env.development to the github repo (excluding secrets, ofc). When we have the config out, there will be a mechanism to ensure same env vars across all environments

(same env vars, not necessarily same values)

i see -- that's really unfortunate, esp the communication around it since we rely on it 😦

we can't commit .env.developemnt as it does include secrets

will the new config setup then include a way to pull the env including secrets? this was honestly one of our favorite features when switching to nhost since it's otherwise quite difficult for teams to keep these types of args in sync

> will the new config setup then include a way to pull the env including secrets?
not initially but we can discuss ways of supporting it. For instance, one of the new features we are adding is the ability to store arbitrary secrets (which don't map automatically to env vars) so even we won't support this initially with the cli we should be able to workaround the problem

We are planning to open a beta so interested users can test the new config and overall workflow, if you are interested we can let you know. This sort of feedback is precisely what we are looking for.

yes, we'd be interested in testing, thanks. also in general what's the best way to stay updated so we're not affected by sudden deprecations of features or breaking changes (e.g. nhost cli didn't mark anything as deprecated like nhost env pull etc. so we had no idea of the change). i understand nhost is still considered to be in beta but johan had mentioned it's still stable enough at this point to be used in a production app so we'd like to be able to know when we need to take action to prevent issues with our dev workflow or more importantly our production app (like the metadata change that brought down our production app entirely last week). i know there are upcoming changes that will hopefully reduce this sort of problem but in the meantime it'd be helpful to know how we can stay up to date on alerts esp about our production app. we try to keep up to date on the discord etc but while e.g. there was an announcement about the metadata change there wasn't a high priority announcement that users needed to do something specific to prevent outages so not sure if there is somewhere else we can be notified

> by sudden deprecations of features or breaking changes
to be honest, this was a bit of an oversight (as most things than don't go as smooth as we'd like). This has been part of a work where we had to remodel of our internal data models, adapt all of our internal backend systems, the dashboard and migrate data. I am actually quite proud of the team that the only thing that happened was that we lost this feature and forgot to communicate it properly. I know this isn't really an excuse, mostly trying to give some context on how this happened.

Usually, when there is a big change in the product we inform all affected parties involves by email, giving ample time to adapt and repeating ourselves over and over. Examples of this are when we migrated from nhost v1 to v2 and when we deprecated RDS.

> like the metadata change that brought down our production app entirely last week
you shouldn't need to worry about this anymore soon. The work I mentioned above was precisely to enable you to have full control over the platform, its configuration, versions, etc. We also don't plan any changes to existing applications between now and then so hopefully that will be the last time it happens.

nhost env pull and nhost env list have been fixed in the latest v0.9.1 release

Though those commands are deprecated and will disappear in the nearest future once we release the new CLI with new configuration format