If a monolith has routes /a and /b, you can deploy the whole service to 2 servers with a proxy where all of the requests for /a goes to server 1 and all the requests for /b go to server 2. Server 1 has all the code to respond to /b but will never see that request.
The 'monolith' (which I find a silly term but I'll use it here) can expose different parts of itself as services. As long as those services can be versioned and are backwards compatible, you can deploy the monolith using any schedule or notification mechanism you like.
If the monolith is composed of modules with a DAG-like dependency structure (e.g. maven projects), then pieces of the monolith can be deployed alongside the dependencies they need.
Depends on the eco system, I've found this straightforward with maven / sbt + GRPC / Akka / Thrift, and then more difficult in environments that don't have baked in concepts of packages and module deployables, but from experience the mention of any of those technologies can start a flamewar of good and bad experiences therein :).