If you deploy Coze and see 'coze-server' keeps restarting, don't throw the blame on the model first. In public issues, the common root cause of this type of problem is actually MinIO, bucket, account password, or object storage initialization. The official open source repository is still coze-dev/coze-studio, and it can also be seen from its 'docker-compose.yml' that MinIO is a key link in the entire service chain.
In other words, the restart of 'coze-server' is often not "it wants to restart itself", but rather that the underlying services it depends on are not ready when it starts. When it connects to MinIO, checks bucket, or reads the configuration, once it fails, it will get stuck or exit, looking like it is pulled up repeatedly.
Let's look at the most critical sentence in the error report first
If something like 'init minio client failed' or 'check bucket opencoze exist failed' appears in the logs, the priority is not to check the workflow or model management, but MinIO itself. Some people in the community have encountered similar situations, and finally found that MinIO is not working properly, or that the configured 'MINIO_ROOT_USER' and 'MINIO_ROOT_PASSWORD' are inconsistent with the actual container.
Back to the official compose file
In the official 'docker-compose.yml', you can see that 'coze-server' relies on MySQL, Redis, Elasticsearch, MinIO, Milvus and other services. This structure itself reminds you that server restarts are often only superficial, and the real problem is in the front-end dependency. Especially for object storage and bucket initialization, as long as one step is not aligned, the subsequent chain failure will follow.
- First, check if the MinIO container is healthy.
- Then check that the bucket is created as expected, such as the default 'opencoze'.
- Check whether the account password in .env is the same as the container environment.
- Finally, look at the boot log of 'coze-server' instead of just staring at the reboot phenomenon.
The most practical processing order in the community
Many people's first reaction is to restart the entire Docker set, but a more effective approach is to go up from the dependency chain: object storage, database, cache, and search engine are all normal, and then look at 'coze-server'. If you restart the server as soon as it comes up, you're essentially triggering the same failure repeatedly.
In addition, './.env' is also hung in the container in 'docker-compose.yml', indicating that some problems are not "just change in the container", but the configuration file itself needs to be unified. This detail is especially easy to overlook when deployed on-premises.
One sentence conclusion
'coze-server' keeps restarting, most likely to check MinIO, bucket and environment variables first. After fixing the basic service, looking at the server logs is usually faster than blindly restarting.
