Why Does a Compose Service Use the Wrong Env File Only After a Host Reboot?

A Compose service can use different environment values after reboot when the boot-time launcher resolves another project directory, env file, or precedence source.

A manual command may run from the intended folder with one shell environment, while systemd, a NAS scheduler, or Portainer starts the same Compose file from another context after boot. The service can also restart an existing container whose environment was fixed at creation time rather than rereading the edited file. Compare the rendered Compose model and the running process environment from the manual and boot paths before editing several files at once.

Compare the Running Environment With the Intended File

Record the container ID, creation time, image, Compose labels, project name, and the actual values visible inside the main process. Compare them with the intended env file without printing secrets into shared logs.

The Linux process environment exposes the values supplied at execution, which is stronger evidence than reading an env file that the current container may never have used.

If the container contains the old values and predates the reboot-time deployment, the service may only have restarted it. If the container is new, continue with precedence and path resolution.

Apply Compose Environment Precedence in the Correct Order

List every source for one harmless variable: CLI flags, shell values, environment:, env_file:, default or explicit .env, and image ENV.

Docker defines a formal environment precedence order, so a correct env file can still lose to a higher-priority value injected by the boot service or stack manager.

Do not search only for duplicate filenames. Search for the variable name across the rendered Compose model, unit file, manager settings, shell environment, and image defaults.

Check the Project Directory and Relative Env Paths

Compare the manual command’s working directory with the boot launcher’s working directory, Compose file arguments, project directory, and relative env_file references.

The Compose Specification defines the application model used to resolve services and configuration, so the selected project definition and its paths are deployment inputs rather than properties rediscovered from the running container.

Use absolute paths for boot-critical env files when the deployment tool supports them, or set an explicit project directory and working directory so manual and automated launches resolve the same files.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Inspect the systemd Working Directory and Environment Files

Read the effective unit, all drop-ins, WorkingDirectory=, Environment=, EnvironmentFile=, and ExecStart=. Compare the unit loaded at boot with the command used manually.

Systemd’s execution settings define the service working directory and environment files, which do not automatically inherit an interactive login shell’s current directory or exported variables.

After changing a unit or drop-in, reload the systemd manager and inspect the effective unit again. Editing a template or unused file does not change the service that actually starts.

Check Stack-Manager Variables and Stored Deployment State

If Portainer or a NAS UI owns the stack, compare its saved variables, uploaded env file, Git deployment path, webhook update behavior, and displayed Compose model.

Portainer distinguishes .env and stack.env behavior, so values entered in the manager can differ from a file edited directly on the host.

Choose one source of truth. A stack managed from Git or a web editor should not also be started manually from another local copy after every reboot.

Recreate the Container Instead of Only Restarting It

Compare the container creation time with the env-file edit time. Render the intended Compose configuration, then perform a controlled recreation of only the affected service.

Red Hat’s systemd guidance recommends checking the files and overrides actually used by a service before restarting it, preventing an obsolete unit or wrapper from recreating the container with old values.

A container restart does not reconstruct its environment from Compose. Recreate it only after protecting persistent data and confirming the rendered model points to the intended volumes and secrets.

Make Manual Start, Reboot, and Redeployment Produce the Same Model

Pin the Compose files, project name, project directory, env-file path, stack owner, and boot dependency. Save a redacted rendered configuration and a harmless environment fingerprint.

The ZimaSpace article on Docker backup scope provides the adjacent rule: environment files and deployment definitions must be preserved together with persistent state.

The issue is resolved when a manual recreation, host reboot, scheduled update, and stack-manager redeploy all create the service with the same redacted environment fingerprint.

Frequently Asked Questions

What is the difference between .env and env_file?

A project .env file commonly supplies interpolation values to Compose, while a service env_file supplies variables to the container. Their interaction and precedence depend on the complete Compose model.

Does restarting a container reload a changed env file?

No. Environment values are set when the container is created. The service normally must be recreated from the corrected Compose configuration.

Why does the problem appear only after reboot?

The reboot path may use a systemd unit, scheduler, manager-stored variables, another working directory, or an older Compose copy that differs from the manual launch.