It's the same Configuration as for ASP.NET core. You basically have an appsettings.environment.json file per environment and use the build in IConfiguration interface to bind your settings to classes. As such settings are stored in the json format:
{
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
"Serilog": {
"LevelSwitches": { "$controlSwitch": "Debug" },
"MinimumLevel": { "ControlledBy": "$controlSwitch" },
"WriteTo": [
...
How many environments and how you call them, is up to you.
Here is an example:

At runtime the environment is deducted from the OS environment variable ASPNETCORE_ENVIRONMENT's value. For development purpose you can create profiles and set the ASPNETCORE_ENVIRONMENT wihtin your launchSettings.json like this:
"profiles": {
"Development": {
"commandName": "IISExpress",
"launchBrowser": true,
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
}
After you deployed or started executing the Blazor app, the hosts ASPNETCORE_ENVIRONMENT for both server-side and client-side applications will be used. Remember even if it's a client-side / SPA application, it is still hosted on a server.
Also for client-side Blazorapp, the appsettings won't be delivered to the client, you wouldn't want to expose your connectionstrings and other sensitive settings to your clients, right?
As a sidenote, if you host your Blazorapp within IIS (as a reverse proxy) a web.config file will be created, for the purpose of instructing IIS how to start the app, what arguments to pass and some other things.