Fix Jitsi Meet Docker Container Infinite Restart Loop

A Jitsi Meet deployment may run briefly and then show one or more services as “Restarting” in Docker Desktop or in docker compose ps. Docker is usually applying the configured restart policy after a process exits. The lasting fix is to identify the service that exits, read its last logs, and correct the startup error. Restarting the whole stack repeatedly or deleting its volumes can hide evidence or remove persistent data.

1. Find the service that is restarting

Run Compose from the directory containing the same Compose file and .env used to launch this installation. If you normally use extra Compose files, profiles, or --env-file, include those same options.

docker compose ps -a

Check each service separately. The core services are web, prosody, jicofo, and jvb; optional services such as jibri or jigasi may also appear. Note the exact service whose state is Restarting or Exited. One failing service does not mean every container has the same fault.

Read the log tail for that service, using timestamps:

docker compose logs --tail=150 --timestamps jicofo

Replace jicofo with the affected service. Add -f to watch another startup attempt. The Jitsi Docker guide documents Compose logs for its services. If Docker cannot return logs, check whether that container's configured logging driver supports reading them.

2. Look for the first fatal message

Scroll to the first clear error in each startup cycle. Later lines may only report that the process stopped and Docker is restarting it. Common root causes include:

• Missing required passwords: Jitsi removed default passwords for internal service accounts, and services that need them will not start until they are set. From the standard deployment directory, run the supplied ./gen-passwords.sh script to populate the required values in .env. Protect that file and never post its secrets in a support request.
• Invalid or unreadable configuration: check the file path and syntax named in the error. A custom Prosody, Jicofo, or JVB configuration may prevent just that service from starting.
• A missing or unwritable mounted directory: check the exact host path in the error and compare it with the service's volume mapping. Avoid changing permissions across the entire configuration tree.
• An image or entrypoint failure: check whether the deployment directory, Compose file, and image tags belong to compatible releases, especially if the loop started after an update.
• Memory pressure: inspect the container state and host memory. An out-of-memory kill calls for a different fix than a malformed configuration.

A Docker restart policy explains why a process comes back after exit; it does not explain why the process exited. Treat Restarting as the symptom and the service log as the evidence.

3. Validate the environment and Compose files

Make sure you are editing the file Compose actually loads. A common mistake is changing one .env while Compose reads another from a different directory or from an explicitly supplied --env-file. Validate the configuration before recreating containers:

docker compose config --quiet

If Compose reports an error, fix the YAML, variable substitution, missing referenced file, or option it names. Running docker compose config without --quiet can help inspect the resolved model, but it may print interpolated passwords. Do not share the unredacted output.

For a standard Jitsi install, compare .env with the env.example from the same release and confirm that required internal passwords are present. If you use a custom Compose file, check that the needed variables reach the right service. Use the included password script rather than blank placeholders. If you change a password, keep the matching component configuration consistent.

The Jitsi project distinguishes normal release files from development code and unstable images. Avoid combining an old Compose directory, arbitrary image tags, and files from a different release during troubleshooting.

4. Check configuration mounts and permissions

Compare the service's volume entries with the actual host paths. A typo, unexpected CONFIG value, or different Compose working directory can make the deployment use another configuration directory.

Permissions depend on the Jitsi version. The handbook says that starting with stable-11146, containers run as an unprivileged user with a read-only container filesystem. Configuration directories are inputs; writable data is separated into storage and tmp directories, which must be writable by UID/GID 1000. Older releases use another layout. Follow the handbook for the version you run rather than reusing a permission recipe for a different release.

If the log identifies a missing or unwritable directory, repair that exact path. Do not apply broad commands such as chmod -R 777 to the entire Jitsi configuration directory; that can weaken security without fixing the mounted path.

5. Inspect the exit state and recent changes

Docker can report a container's exit code, out-of-memory status, restart count, and daemon error. First get the container ID for the failing service:

docker compose ps -q jicofo

Then substitute the returned ID:

docker inspect --format '{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}} error={{.State.Error}}' CONTAINER_ID

An increasing restart count confirms repeated attempts. If oom=true, check host or container memory limits and system logs. A nonzero exit code alone is not a diagnosis; compare it with the service log.

If the loop began after an update, note what changed: release files, image tags, a password, a bind mount, or custom configuration. Back up configuration and persistent data before changing versions. Restore a compatible set of Compose files and images or follow Jitsi's upgrade instructions. Network and firewall problems can stop participants from connecting, but do not usually explain why a service process repeatedly exits; distinguish a boot failure from a media-connectivity issue.

6. Recreate the service after fixing the cause

After changing an environment value or Compose definition, recreate the affected service to apply the new configuration:

docker compose up -d --force-recreate jicofo

Substitute the service name. If a shared configuration change affects several components, recreate the relevant services together. Then review status and logs again. A plain restart does not apply every Compose or environment change, while recreating the entire stack may interrupt active meetings.

Do not use docker compose down -v as a generic restart-loop fix. The -v option removes Compose-managed volumes and may delete data you intended to keep. Save logs and check mounts before removing containers or data.

Verify the fix

Check status, wait through several normal startup intervals, and check again:

docker compose ps
docker compose logs --tail=100 --timestamps jicofo

The affected service should remain up, its restart count should stop increasing, and its log should no longer repeat the same fatal message. Confirm the web page loads and test a meeting with two clients. If services stay running but participants cannot exchange audio or video, investigate networking, firewall rules, and the advertised JVB address in the Jitsi handbook.

For reference, use the Jitsi Meet Docker self-hosting guide, the project's environment variable example, Docker's restart policy documentation, its Compose logs reference, and the container inspect reference.