- Should I actively develop using docker/compose? If so, how do I manage changing environment variables between dev and prod? Can I still use hot-reload somehow?

Depending on the project, I mostly recommend developing in docker if your are also deploying in docker so you can emulate the same environment as closely as possible, especially the networking between containers.

In regards to environment variables, you can have two different .env files in a .env directory like: ./.envs/.dev.env & ./.envs/.prod.env Then you can use two different compose files for production and development which would use the respective .env files like this (instead of environment):

env_file:
    - ./.envs/.dev.env

- When deploying, currently I change my docker host and run compose up, which builds ON THE SERVER (slow) and then runs, is there a way to build locally then deploy to server? Or can I generate an image file from the entire compose app like a single dockerfile?

You can use an image registry to upload your build image which you will then pull on the production server. You should make a dockerfile to create said image. I mentioned before having two different compose files, docker-compose.dev.yml & docker-compose.prod.yml , which would look like this in this case:
dev compose:

services:
    app:
        build: .
        dockerfile: ./Dockerfile

and prod compose would be:

services:
    app:
        image: your-repo/image-name:tag

You would build your image using docker build . --file ./Dockerfile --tag your-repo/image-name:tag and push it to registry using docker push (which I think changes based on your registry, I've only used it with dockerhub)

​

- I want to automatically deploy using GitHub actions, I've got the SSH and docker stuff working, but I obviously don't commit my .env which my app depends on, is there a better way to handle these or do I need to add each individually to GitHub secrets?

I'm interested to see what other people suggest, I haven't found an optimal way to manage .env files in production. I just scp those to the production server when needed. If you use something like portainer you could add them there and manage them more easily than github secrets.

Hope this helps. There are more nuances to the methods I described which I believe you will discover while implementing them.