Yes that is how it should work, since these services are meant to represent each other across your environments.

ok, thank you for explaining.

I would have another question, please. Is there a way to explicitly exclude a service from showing up in the sync changes? For example, I have a service that does a cron database backup on prod, but I'm not interested in having it in the lower envs.

Hmm that's a good question, I don't think there is a straight forward way to exclude a service from the environment sync.

There is not a way to completely exclude services from Sync, but very interesting request! I suggest adding a Feedback thread to let others chime in and/or upvote it!

The only option would be to click the Discard button when syncing.

@melissa: sure, I'll do that.

@brody: indeed, that's what I'm currently doing at every sync.

Unfortunately we don't support this at this time. What's the usecase?

For example, I'm running the official postgress backup image in production only, as I'm not interested in backing up lower envs for now. Every time I sync prod from qa, I have to manually remove the option to destroy the backup service.

Something similar happens with env vars too, for example, we have some secrets which are different for each env, so I think there should be an option to mark them as specific to an env and to be skipped if modified. They could be included in the sync if deleted in a env, as that would indicate that it's intentionally to remove them in the synched env too.

I'll throw my use case in the ring too, I have a production environment with a web app that also contains Umami and the accompanying database, but the dev environment I have has no need for Umami or its database, so I just end up not syncing anything since since the config is small enough anyway.

Wouldn't this be a good case to have like, a production and then a staging environment?

Wouldn't that be the same case? I personally don't can't see myself needing umami in any environment but production.

So you could create an environment that is staging, without umami, and then have your PRs fork from that

And setup a trigger on master so that when you merge that in, it'll deploy

I also have another user case, we are using Weaviate vector database, however there's no reason for us to pay for the managed service in staging and develop environment, therefore we self host for those. So we have this service running in the lower envs only.