# Docker configuration

Run each Zato environment as one container, configured entirely from the outside.

One Zato container is one complete environment - the server, the Dashboard, the scheduler and the load balancer all start together. Everything about the container is configured from the outside, through environment variables and mounted directories, so nothing that defines the environment is stored inside it. A replacement container rebuilds the same environment from those inputs - the variables, the mounted project and the databases that run outside the container.

## Start from the blueprint {#start-from-the-blueprint}

The [blueprint repository](https://github.com/zatosource/zato-project-blueprint) is a ready-made project structure - Python services, an [enmasse](https://zato.io/docs/admin/enmasse.html) YAML file with the configuration, Python requirements and user config files, laid out in the directory structure that a container reads at startup. Its provisioning script, `myproject/impl/scripts/run-container.sh`, starts and configures a container around the project, and it is meant to be the basis of your own provisioning scripts.

The [deployment tutorial](https://zato.io/tutorials/devops/deployment.html) works through the whole blueprint - what each directory is for, what the script does step by step and how a starting container finds the project.

## Deploy your projects {#deploy-your-projects}

A container deploys the project that you mount into it. The `Zato_Project_Root` variable points at the mounted directory, and the server loads the services, the enmasse YAML and the config files from there. After the start, the server keeps watching the mounted files, so a service that you edit on the host is redeployed each time you save it - see [hot deployment](https://zato.io/docs/dev/hot-deploy.html).

## Configure the container {#configure-the-container}

Every setting - ports, passwords, databases, logging, TLS - is an environment variable that you pass to `docker run`. For example, three variables set the Dashboard password, move the Dashboard to another port and turn on DEBUG logging:

```bash
docker run \
  -e Zato_Dashboard_Password=my.secret.password \
  -e Zato_Port_Dashboard=9000 \
  -e Zato_Log_Level=DEBUG \
  ...
```

For the full list, grouped by subject, see the [environment variables reference](https://zato.io/tutorials/devops/env-variables.html).

## See also {#see-also}

- [Installation with Docker](https://zato.io/docs/admin/guide/install/docker.html) - The first docker run that creates a complete environment
- [Deployment tutorial](https://zato.io/tutorials/devops/deployment.html) - The blueprint project and the provisioning script that starts a container
- [Starting and stopping](https://zato.io/docs/admin/start-stop.html) - The container lifecycle and what a restart preserves
- [Updating environments](https://zato.io/docs/admin/guide/install/update.html) - Moving a running environment to a newer image
- [Kubernetes](https://zato.io/docs/admin/guide/kubernetes.html) - The same container under Kubernetes, with configuration from Git

## Learn more {#learn-more}

- [Production checklist](https://zato.io/docs/admin/production-checklist.html) - What to confirm before an environment takes real traffic
- [Audit log](https://zato.io/docs/admin/audit-log/) - Every request, response and error, and what you can do with them afterwards
- [Health checks](https://zato.io/docs/admin/health-checks.html) - Have Zato ping your outgoing connections instead of waiting for traffic to fail
- [Logging](https://zato.io/docs/admin/logging.html) - What is written where, and how to ship it to Splunk, Loki, Elastic or Datadog
- [GitOps with enmasse](https://zato.io/docs/admin/enmasse.html) - Keep the whole environment in git as YAML and import it anywhere