Handling SQL Login/Passwords when deploying a VS Database Project (DACPAC)

After an initial publish to a SQL Server(2019) and after the initial create of my DB project (data tier app) when publishing again it is failing with a drift report. No changes done to the database externally or within the VS project.

Drift report:

<Modifications>
    <Object Name="[DummySqlLogin]" Parent="" Type="SqlUser" />
</Modifications>

To try and circumvent this by following a suggestion in answer on a question/answer from 2016.

"From your publish config file, use the following"

<ExcludeUsers>True</ExcludeUsers>
<ExcludeLogins>True</ExcludeLogins>

Unlike the OP this does allow me to publish to my database which now leaves me to the question of how to deal with logins/passwords especially in a scenario where we are going to be publishing to different environments.

I was planning on using SQLCMDVARIABLES to maintain separate Publish profiles for different types of environments and within there could specify passwords for each and then within the VS Database Project place a PreDeployment script which would setup Logins/Passwords for SQL accounts and make use of the SQLCMD variables.

Is there no better way of doing this? This probably works great for when you only have 5-10 environments but what if you have a 100?

Note* I want to avoid using commercial tools such as Redgate.

Here is one of common approaches: environments, deploy targets are no project sources.

Same for specific logins, users, passwords. Those are security/administrations items server-specific. They depend on the environment, not product features. Why would the product, project sources depend on them? Imagine you have to change password due to security reasons on one of the servers. Can you logically connect it to recompiling all the sources?

I'd suggest to consider removing all the security items from SSDT project except maybe Roles (and configure publish.xml to ignore all the removed kinds of objects). Maintaining 100+ servers surely requires different tools and approaches, SSDT, dacpacs has nothing to do with it. The solution could be based on Octopus deploy, Ansible or something else.