In particular, when running on **Kubernetes** you will probably **not** want to use workers and instead run **a single Uvicorn process per container**, but I'll tell you about it later in that chapter.

///

## Multiple Workers { #multiple-workers }

You can start multiple workers with the `--workers` command line option:

//// tab | `fastapi`

If you use the `fastapi` command:

<div class="termy">

}

func newHealRoutine() *healRoutine {
	workers := runtime.GOMAXPROCS(0) / 2

	if envHealWorkers := env.Get("_MINIO_HEAL_WORKERS", ""); envHealWorkers != "" {
		if numHealers, err := strconv.Atoi(envHealWorkers); err != nil {
			bugLogIf(context.Background(), fmt.Errorf("invalid _MINIO_HEAL_WORKERS value: %w", err))
		} else {
			workers = numHealers
		}
	}

	if workers == 0 {
		workers = 4
	}

And if you need to have multiple workers, you can simply use the `--workers` command line option.

/// note | Technical Details

The Docker image was created when Uvicorn didn't support managing and restarting dead workers, so it was needed to use Gunicorn with Uvicorn, which added quite some complexity, just to have Gunicorn manage and restart the Uvicorn worker processes.

		t.Run(fmt.Sprintf("TestApplyNewerNoncurrentVersionsLimit-%d", i), func(t *testing.T) {
			workers := []chan expiryOp{make(chan expiryOp)}
			es.workers.Store(&workers)
			workerReady := make(chan struct{})
			var wg sync.WaitGroup
			wg.Add(1)
			var gotExpired []ObjectToDelete
			go expiryWorker(&wg, workerReady, workers[0], &gotExpired)
			<-workerReady

			item := scannerItem{
				Path:        obj,

		workers = workers[:len(workers)-1]
		worker <- expiryOp(nil)
		es.stats.workers.Add(-1)
	}
	// Atomically replace workers.
	es.workers.Store(&workers)
}

// Worker handles 4 types of expiration tasks.
// 1. Expiry of objects, includes regular and transitioned objects
// 2. Expiry of noncurrent versions due to NewerNoncurrentVersions

replication_max_workers         (number)    set the maximum number of replication workers (default: '500')
replication_max_lrg_workers     (number)    set the maximum number of replication workers MinIO uses to replicate large objects between sites. (default: '10')
transition_workers              (number)    set the number of transition workers (default: '100')

	if (checkOld > 0 && len(p.workers) != checkOld) || n == len(p.workers) || n < 1 {
		// Either already satisfied or worker count changed while we waited for the lock.
		return
	}
	for len(p.workers) < n {
		input := make(chan ReplicationWorkerOperation, 10000)
		p.workers = append(p.workers, input)

		go p.AddWorker(input, &p.activeWorkers)
	}
	for len(p.workers) > n {
		worker := p.workers[len(p.workers)-1]

But in many cases, you will want to run several worker processes at the same time.

### Multiple Processes - Workers { #multiple-processes-workers }

Aquí hay algunas combinaciones y estrategias posibles:

* **Uvicorn** con `--workers`
    * Un administrador de procesos de Uvicorn **escucharía** en la **IP** y **puerto**, y iniciaría **múltiples worker processes de Uvicorn**.
* **Kubernetes** y otros sistemas de **contenedor distribuidos**

Y si necesitas tener múltiples workers, puedes simplemente utilizar la opción de línea de comandos `--workers`.

/// note | Detalles Técnicos

La imagen de Docker se creó cuando Uvicorn no soportaba gestionar y reiniciar workers muertos, por lo que era necesario usar Gunicorn con Uvicorn, lo que añadía bastante complejidad, solo para que Gunicorn gestionara y reiniciara los worker processes de Uvicorn.