A lot of good answers here to the actual question in the OP, of "how do you do devops". And while it's good to look at other stacks for inspiration, particularly as a solo/small-team founder, the "correct choice" such as there is one, is in my opinion to do what you can do quickly/efficiently with your current skillset.
I'd say the meta-level answer here should be to timebox your investment based on the tools you know, and an honest assessment of your uptime requirements. Also, know that what feels like a janky solution will usually get you much further than you think it will.
For an initial PoC you should probably not be spending more than an hour or two setting up your infra, so Heroku or a single VM is probably the way to go. But you still _might_ want to start with k8s if it's the tool you know best; you can set up a k8s cluster in GKE with about as many clicks as it takes to set up a single node, and if you have a full "django k8s yaml" or equivalent in your toolkit then you could be up and running in an hour or two from scratch. I wouldn't recommend this to most folks though.
Once you have some traction, beyond PoC stage, then you should be thinking about failure modes, their impact to your business, and how much time it's worth to spend to avoid them. If your users won't notice a few hours a week of downtime, then you don't need a multi-node setup like k8s or nodes behind a LB; a single node should suffice. If you have simple user data (like say comments) where in the worst-case losing everything since last night's backup would not sink your business, then running your DB with no standby replica and nightly backups might suffice. If you're storing financial transactions that's obviously not an option and your first DB with customer data needs replication (or however you want to get to RP0).
Given all that, here are my suggestions for your specific questions:
For CI/CD I'd say don't bother with CD, just set up Github/Gitlab to run your UTs on your PRs and on merges to master. Honestly you can just run UTs manually while building at PoC stage, but when you have paying customers I'd say you should take the 15 mins to wire up simple UTs. Getting a full Continuous Delivery pipeline set up won't save you much time vs. just manually deploying your artifacts, and at the beginning your tests are unlikely to be good enough to continuously deploy safely. At the point where you start having quality issues that your customers are complaining about, you might want to push for CD as a discipline thing; it forces you to write good-enough tests that you're happy to deploy if the tests are green. But it's not mandatory to deploy everything if your tests are good enough to do so.
For rollback on your stateless instances, I like the pattern of having your single-node running your apps in a Docker container (I had one for Django and one for Nginx), that way the upgrade/downgrade is simply `docker pull <newimage>; docker stop <old image>; docker run <new image>`, and rollback is the inverse. But as long as you're just upgrading code and not OS dependencies, then you can do an equivalent operation by swapping out your code artifacts, e.g. checking out the new version of your python app & restarting your WSGI workers.
For running your DB, I see a few folks suggesting running your DB locally on your node -- if you are an experienced DB operator that might be a good option, but if you're not, I would personally recommend using whatever managed SQL offering your cloud provider has; RDS or Cloud SQL will give you a durable instance with backups & easy restore with a few clicks in the UI, which is hard to beat in terms of ROI.
Possibly-controversial recommendation: in general unless you've spent a lot of time working with Terraform/Ansible/etc. I would recommend against using infrastructure-as-code in the early days. It's hard to beat the ROI of a couple clicks in your cloud provider's UI to get your infrastructure set up, you might spend 10-100x more time getting your repeatable build implemented, even if it's just a couple mins vs. a couple hours. Clicking in the UI is not reproducible, but it will get you further than you think. As above though, if you're fluent in these tools and the difference in time-to-provision is very small, then absolutely do this now instead of later. But don't feel like you MUST do it "the right way" from the beginning.
I'd say the meta-level answer here should be to timebox your investment based on the tools you know, and an honest assessment of your uptime requirements. Also, know that what feels like a janky solution will usually get you much further than you think it will.
For an initial PoC you should probably not be spending more than an hour or two setting up your infra, so Heroku or a single VM is probably the way to go. But you still _might_ want to start with k8s if it's the tool you know best; you can set up a k8s cluster in GKE with about as many clicks as it takes to set up a single node, and if you have a full "django k8s yaml" or equivalent in your toolkit then you could be up and running in an hour or two from scratch. I wouldn't recommend this to most folks though.
Once you have some traction, beyond PoC stage, then you should be thinking about failure modes, their impact to your business, and how much time it's worth to spend to avoid them. If your users won't notice a few hours a week of downtime, then you don't need a multi-node setup like k8s or nodes behind a LB; a single node should suffice. If you have simple user data (like say comments) where in the worst-case losing everything since last night's backup would not sink your business, then running your DB with no standby replica and nightly backups might suffice. If you're storing financial transactions that's obviously not an option and your first DB with customer data needs replication (or however you want to get to RP0).
Given all that, here are my suggestions for your specific questions:
For CI/CD I'd say don't bother with CD, just set up Github/Gitlab to run your UTs on your PRs and on merges to master. Honestly you can just run UTs manually while building at PoC stage, but when you have paying customers I'd say you should take the 15 mins to wire up simple UTs. Getting a full Continuous Delivery pipeline set up won't save you much time vs. just manually deploying your artifacts, and at the beginning your tests are unlikely to be good enough to continuously deploy safely. At the point where you start having quality issues that your customers are complaining about, you might want to push for CD as a discipline thing; it forces you to write good-enough tests that you're happy to deploy if the tests are green. But it's not mandatory to deploy everything if your tests are good enough to do so.
For rollback on your stateless instances, I like the pattern of having your single-node running your apps in a Docker container (I had one for Django and one for Nginx), that way the upgrade/downgrade is simply `docker pull <newimage>; docker stop <old image>; docker run <new image>`, and rollback is the inverse. But as long as you're just upgrading code and not OS dependencies, then you can do an equivalent operation by swapping out your code artifacts, e.g. checking out the new version of your python app & restarting your WSGI workers.
For running your DB, I see a few folks suggesting running your DB locally on your node -- if you are an experienced DB operator that might be a good option, but if you're not, I would personally recommend using whatever managed SQL offering your cloud provider has; RDS or Cloud SQL will give you a durable instance with backups & easy restore with a few clicks in the UI, which is hard to beat in terms of ROI.
Possibly-controversial recommendation: in general unless you've spent a lot of time working with Terraform/Ansible/etc. I would recommend against using infrastructure-as-code in the early days. It's hard to beat the ROI of a couple clicks in your cloud provider's UI to get your infrastructure set up, you might spend 10-100x more time getting your repeatable build implemented, even if it's just a couple mins vs. a couple hours. Clicking in the UI is not reproducible, but it will get you further than you think. As above though, if you're fluent in these tools and the difference in time-to-provision is very small, then absolutely do this now instead of later. But don't feel like you MUST do it "the right way" from the beginning.