Running composer update only updates packages to the highest versions allowed by the composer.json file, which defines your project's packages and their version constraints. Here's how the syntax works: https://getcomposer.org/doc/articles/versions.md#writing-version-constraints
Example: your laravel/framework has the version constraint ^11.0. That means it'll update to the highest available 11.x.x version, but not to any 12.x.x version. You'd have to manually edit the constraint to ^12.0 before updating to get Laravel 12. However, the first number in semantic versioning denotes a major version, which means it includes breaking changes, and you can't simply run an automatic update without reading the docs. Laravel has separate guides for upgrading between major versions: https://laravel.com/docs/12.x/upgrade
When you run composer update, a file called composer.lock is created or updated. That holds data on the currently installed versions. When you run composer install, those versions are installed. This way you can keep the same versions running on all environments.
You of course have to update every instance of the app. Most developers use a version control platform, such as GitHub, to host the code and to deploy it onto servers. You'd update and test the app locally, then push the changes to GitHub. When the code is deployed to a production server, the composer install command is run to install the exact versions from composer.lock.