If you’ve been following along with the previous posts on managing multiple Git identities and multiple SSH keys, this next step adds a nice layer of polish — verified commits.
You’ve probably noticed some commits on GitHub have a little “Verified” badge next to them.
That badge tells others (and your future self) that GitHub has confirmed the commit really came from you — not someone impersonating your name and email.
Let’s walk through how to set up commit signing for your personal and work In the last post, we configured Git to automatically use different user names and emails depending on the project directory.
That solved one half of the problem.
But if you use multiple Git accounts — say, one for work, one for personal projects — you’ll also need to make sure Git connects using the right SSH key for each.
Let’s fix that next.
The Problem
By default, Git uses your system-wide SSH key (typically ~/.ssh/id_rsa or ~/.ssh/id_ed25519).
If both your personal and work GitHub accouIf you contribute to both personal and work repositories, you’ve probably run into this:
You commit to a personal project — and realise your work email is all over it.
Or worse, you commit to a company repo using your personal identity.
Git only tracks one author configuration per system by default, but with a little setup, you can make Git automatically choose the right name and email based on the directory you’re working in.
Let’s walk through how to do it cleanly.
🧩 The Problem
By defIf you haven't read Part 1 of this series it can be found here Setting Up Ghost with S3 Storage Using ghost-storage-adapter-s3: Part 1
Amazon CloudFront is a powerful CDN for speeding up content delivery. By default, when you create a distribution, AWS gives you a long, autogenerated domain like:
d1234abcdef.cloudfront.net
That works fine, but it’s not user-friendly. For production, you’ll usually want to use your own domain — for example, content.yoursite.com — so your assets are delivered uBy default, Ghost stores uploaded images and media locally on the same server that runs Ghost. That works fine for small blogs, but if you want to run Ghost in a scalable environment (like Docker, Kubernetes, or multiple servers behind a load balancer), you’ll quickly run into problems.
To make Ghost more flexible, you can use Amazon S3 (or an S3-compatible service like MinIO, DigitalOcean Spaces, or Backblaze B2) for media storage. This decouples your storage from the Ghost instance, ensuring 
