This message was deleted.

I've had to do exactly that. In my situation, I want to run database provisioning (setting up user accounts for example), but also do database schema migrations. I've 'solved' it by having a separate container app job. This container app runs once before the rest of the deployment. Challenge is, now I have to much more orchestration of my deployment. (first deploy / run the container with the new initialization scripts, then deploy the actual app once it's completed successfully). I've been told you could do something similar with container initialization jobs, but haven't had a chance to look into that too much.

Solutions I've done in the past revolved around having CD "deployment" agents running connected to the VNET. e.g. a self-hosted GitHub Action agent. These deployment agents would be authorized to do deployment only activities (which would include database/data migration tasks). Never CI build jobs. They'd be locked down with very limited internet access (perhaps just back to GitHub actions), not directly addressable over internet etc. I also typically design my VNETs / VPCs such that there is an "ops VNET" upon which such hosts live and have peering to the various environment VNETs/VPCs.