I've had tremendous success using a custom modeling language inspired by and older version of the Archimate approach and some simple diagramming tools (I typically use yEd, but you can use pretty much anything that supports the ability to layer sub-diagrams like you might in horizontal swim-lanes).
The approach is to use different stacked layers to represent different levels of abstraction or specificity and how they all align to a business goal at the top layer. The layers can change depending on the environment but typically are as follows:
Top - Business Goals
(Top - 1) - Specific Software Implementation
(Top - 2) - Application and run-time environment
(Top - 3) - Containerization Layer
(Top - 4) - Virtualization Layer
(Top - 5) - Hardware Layer
I like to use boxes that have two sections a top section for a title and a lower section for some descriptive detail.
The basic idea is to describe, as a stack, all the components that go into servicing a given business goal. Start with the hardware, and add boxes going up the stack until you've described all the components of the system. Connect them with arrows pointing up to the next layer. If you need to group things together at a layer, use a box to group them.
Some components might live in one lane or another (or both), depending on how you think about them.
Use colored arrows to show dataflow between components at the logical layer (you can infer the flow between all other lower layers from the stacks). I like to use red, blue and green to model the dataflow at different system states like red for deployment, green for operational and blue for configuration.
Add or remove layers as you deem fit. Urls, usernames/passwords, IP addresses, specific config options and so on fit in the descriptive components. For some smaller ER diagrams you can even fit them right in the lane or have a call-out to another diagram with the larger diagram.
Some people like to use different colors for the different layers (e.g. Archimate-style).
Print off the diagram on a plotter every so often so you can stick it on a wall and write on it as things develop. Adjust the diagram in a sync every week or two to keep it up to date.
The goal is to have a flexible framework and not to get locked into a modelling approach with such a high specificity that you're sweating over which kind of arrow represents exactly what thing, but if you need that for certain cases you can. The layered approach helps to decouple/deconvoluted some of the density of meaning in other languages that often has people having to look symbology up just to read the diagram. You can adjust/tweak as necessary and most projects have some different "dialect" of this language. Fill it out with just as much specificity as you need to answer any question you have. Often entire boxes just have a ??? for the description because it's not entirely necessary to know the details.
I've used this to describe fairly complex systems that serve millions of requests per day and after 3 or 4 iterations the diagrams were sufficient to answer any non-code-specific question we had. Multiple systems can be displayed next to each other and the dataflow arrows show interactions so you can even show very complex inter-service interactions as well.
I think the most important factor here is to use it as a mix of both documenting work that's been done (the existing system) and use different looking boxes to show aspiration or forward looking work to do (maybe dashed lines or a different color or whatever). Don't try to design the entire system at the start or you'll fall into disharmony with your agile developer teams.
I put a really trivial example here (made in yED) https://imgur.com/a/H8dCwoD
I made this in just a couple minutes using mostly default yED pallet options if that helps you understand the level of effort (probably spent more time tweaking the colors to white and the font tbh).