Sadly, this goes against what a service is designed to be. Replicas in a service are meant to be identical things that are load balanced to do the same the same thing as their other replicas. The number of replicas is designed to be increased or decreased at any time, not just at creation.
There are two possibilities here:
One. You really want three separate services to run with the same image, but with some unique property, and you don’t simply want to manually create three separate services…
In that case you should write a shell script with a loop that runs three times and substitutes the unique values in each iteration.
Two: You really want a unified service (load balanced), but somehow still want each replica to do something different.
The main choice here would be to write your start up code, inside the container, to inspect its ID or something and configure the unique configuration at run time (when it is deployed).
Of course this gets more involved around the issue of how each running container decides it is 1, 2 or 3…; so it can select the unique thing is is supposed to configure. Maybe, when the first three containers are started, it would be easy.
Containers can come and go due to later commands to scale up or down, and failed containers automatically removed and replaced. Their unique ID will change and make deciding if they are now the new 1, 2 or 3 challenging. Whether you strictly care about being 1, 2 or 3, or just different makes a difference in the complication level.
It is solvable; just possibility a little more work than might seem likely on first glance.