ivan006
commented
1 year ago Am I mean to use my local Supabase CLI driven project to make my migrations using "supabase db diff " and then put those files into the deployment projects "packer/supabase/volumes/db" folder or what?
In my setup, I have two different local Supabase environments, both cloned from the Supabase GitHub repository (https://github.com/supabase/supabase). The key difference between these two local environments is the tooling I am using: the first local environment relies on Docker-Compose to orchestrate containers, while the second uses the Supabase CLI for local development. Despite these different setups, both of my local environments are connected to distinct databases. In addition to these, I have a third, remote environment, which is based on a clone of the Supabase-on-DO repository (https://github.com/digitalocean/supabase-on-do), and this is deployed on Digital Ocean's infrastructure. Currently, I am unsure why I have two divergent local setups, and I am struggling to establish a migration workflow. I hope to be able to consistently transfer database changes from my local environments to my remote production setup, but as of now, this is more of a hope than a reality.
^ Note: My primary goal is to establish a smooth migration workflow that allows me to apply database changes from my local Supabase environments to my remote production environment hosted on DigitalOcean. I am seeking a nudge in the right direction to understand how this should be ideally set up, considering my existing local setups (Docker-Compose and Supabase CLI environments). Currently, migrating changes to the remote environment is more of an aspiration than a practical reality for me.