I would recommend the polar opposite, actually: use a framework that has nothing in common with anything that you already know. After all, half (or more) of the point of personal projects is to learn new things, right?
So one detail that I left off was that I actually also teach programming to complete novices in short time frames. It's kind of like a bootcamp but different in a lot of ways. We teach them node because it fits better with our tight schedule.
But if you're not too terribly rushed then sure, that does sound like a good idea.
I would argue that the tricky part is session's and middleware. When I first attempted to build a golang web app that required session cookies I got so discouraged that I just swore them off and went with JSON web tokens instead. It also took me a while to wrap my head around the concept of clean middleware.
I would say it was rewarding in the end though, because I learned about some low-level concepts typically abstracted away by the framework I was working with. It's fun to know about these things.
The https stuff is done via Caddy server that automatically serves and updates the cert via LetsEncrypt - requests are then forwarded to the go app.
Full disclaimer: I actually use golang for my personal projects because I'm attracted by its simplicity and how it really doesn't hide stuff from me using hand-wavy magic. Performance is also a factor, but not one I consider when comparing it to node.
If I'm working on something I want to roll out fairly quickly. A prototype. Then I'll probably use node and leverage npm quite a bit. Typically I'll install Express, Sequelize, and Passport. If a front-end framework is necessary then I'll use Ember.
I've used Django a long time ago, and it was nice, but I'm not sure how much its changed since then. I also worked with Ruby on Rails in the past. I think you can be really productive with it if you put in the time to learn it, but I haven't found any great internet resources to really learn it, plus it's a little too hand-wavy for me.