The answer depends on whether the variable is supposed to be constant (that is, not supposed to be modified by user getting the unit) or variable (supposed to be set by the user).
Since it's your local unit, the boundary is quite blurry and either way would work. However, if you started to distribute it and it would end up in
/usr/lib/systemd/system, this would become important.
If the value doesn't need to change per instance, the preferred way would be to place it as
Environment=, directly in the unit file:
The advantage of that is that the variable is kept in a single file with the unit. Therefore, the unit file is easier to move between systems.
However, the above solution doesn't work well when sysadmin is supposed to change the value of the environment variable locally. More specifically, the new value would need to be set every time the unit file is updated.
For this case, an extra file is to be used. How — usually depends on the distribution policy.
One particularly interesting solution is to use
/etc/systemd/system/myservice.service.d directory. Unlike other solutions, this directory is supported by systemd itself and therefore comes with no distribution-specific paths.
In this case, you place a file like
/etc/systemd/system/myservice.service.d/local.conf that adds the missing parts of unit file:
Afterwards, systemd merges the two files when starting the service (remember to
systemctl daemon-reload after changing either of them). And since this path is used directly by systemd, you don't use
EnvironmentFile= for this.
If the value is supposed to be changed only on some of the affected systems, you may combine both solutions, providing a default directly in the unit and a local override in the other file.