# Starting and stopping servers

Restart a Zato container and get the same environment back.

A Zato server runs inside a container, so starting and stopping a server means starting and stopping its container.

## Stop, start and restart the container {#stop-start-and-restart-the-container}

Use the standard Docker commands with the container's name:

```bash
docker stop zato-4.1
docker start zato-4.1
docker restart zato-4.1
```

To follow the startup, watch the log until the environment reports that it is ready:

```bash
docker logs -f zato-4.1
```

## The three inputs of a start {#the-three-inputs-of-a-start}

Every start builds the environment from scratch, from three inputs:

- **The environment variables** that the container was created with - ports, passwords, database addresses, all of the [environment variables reference](https://zato.io/tutorials/devops/env-variables.html)
- **The mounted project directory** - your project with its services, [enmasse](https://zato.io/docs/admin/enmasse.html) YAML and configuration - see the [deployment tutorial](https://zato.io/tutorials/devops/deployment.html)
- **The external databases** - the [ODB](https://zato.io/docs/admin/odb.html) and the [audit log database](https://zato.io/docs/admin/audit-log/index.html), when they are MySQL, PostgreSQL or Oracle DB rather than the SQLite defaults

A container built from these three inputs comes back complete - it deploys the services from the mount and imports the enmasse YAML on startup.

Anything that existed only inside the container does not come back:

- **The SQLite ODB and SQLite audit log**, if you left them at their defaults - configuration created only in the Dashboard and never exported, and audit events stored in SQLite, are not retained. Exporting the configuration to [enmasse](https://zato.io/docs/admin/enmasse.html) retains it, and an [external audit log database](https://zato.io/docs/admin/audit-log/index.html) retains the events.
- **Passwords that you did not set** - a password that was auto-generated is generated again, so set your own through the [environment variables](https://zato.io/tutorials/devops/env-variables.html) if anything outside the container depends on them.
- **Log files**, unless the logs directory is mounted - see [logging](https://zato.io/docs/admin/logging.html)
- **Log levels changed from the Dashboard**, which revert to the `Zato_Log_Level*` variables

> **Keep the environment's definition outside the container.** Keep the project in Git, the databases outside the container and the secrets in environment variables. Any container, restarted or recreated on any host, then comes back as the same environment. Configuration that exists only inside a running container does not survive a restart - to export and commit it, see the [DevOps tutorial](https://zato.io/tutorials/devops/deployment.html).

## What to check afterwards {#what-to-check-afterwards}

1. The server answers - see [ping endpoints](https://zato.io/docs/admin/ping.html):

```bash
curl http://localhost:11223/zato/ping
```

1. The Dashboard loads and shows the environment you expect.
2. Your services are deployed, under `Services` in the Dashboard.
3. The scheduler is running, if this container is meant to run it - see [multi-server environments](https://zato.io/docs/arch/guide/production/multi-server/index.html).
4. The log shows no errors from the last few minutes - see [logging](https://zato.io/docs/admin/logging.html).

## See also {#see-also}

- [Deployment tutorial](https://zato.io/tutorials/devops/deployment.html) - The project mount and the enmasse YAML that a starting container reads
- [Backup](https://zato.io/docs/admin/backup.html) - What to back up so any container can be recreated anywhere
- [Logging](https://zato.io/docs/admin/logging.html) - Following server logs and shipping them off the box

## 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