I'm the person on your team who does not fear deploying half an hour before the end of the workday. Not because I'm reckless, but because I'm confident in the process of recovering from errors. I work in short iterations, developing and deploying small changes one at a time. I have automated tests, code review, production monitoring and error alerts. If the deployment breaks something, it's easy to revert the last commit and deploy again.
In my experience, a lot of web-based business software can benefit from more confidence in the release cycle. The more you give into fear of failure, the more you postpone releases. Eventually you are too afraid to break things so you change nothing in production. You test extensively on pre-production environments, which never quite match the real production environment. That takes a long time so your development cadence slows down. Releasing becomes a big event. The team is on edge, because the accumulated changeset is large and many things can go wrong.
The remedy to this downward spiral is accepting that things will eventually go wrong, no matter how hard you try to prevent that. Learning from incidents will teach you how to react to future incidents and you will become better at recovery.
Investing in prevention still plays as a big role. Type systems, automated tests, manual tests, feature flags... all of these tools are worth it. Just don't forget to plan for failure: improve observability, run incident recovery drills, write documentation. Having these conversations in your team and getting everyone involved will help with confidence, release speed and stress levels.