Disclosure: I build Stratos. This is an updated, AI-assisted adaptation of our original Docker battery guide. It includes Docker's own resource-saving options and does not claim a guaranteed battery improvement from switching tools.

If your MacBook becomes hot or loses charge quickly while developing a Laravel application, Docker may be part of the workload—but it is not enough to see Docker running and assume it is the only cause.

An IDE indexing source files, a frontend watcher rebuilding repeatedly, a queue worker stuck in a retry loop, or a database doing background work can consume resources in either a container-based or a native setup.

The useful sequence is: measure the work, remove what you do not need, then decide whether your project requires containers.

1. Establish a useful baseline

Open Activity Monitor and inspect CPU and Energy while your stack is idle and while you perform representative development tasks. Look at the application and its associated processes, not just one menu-bar process.

Record:

  • Mac model, chip, memory, macOS, and Docker Desktop version.
  • The running containers and services.
  • Whether the laptop is charging, screen brightness, and power settings.
  • Frontend watchers, queue workers, schedulers, database activity, and IDE indexing.
  • What you did during the sample and how long you observed it.

Use repeated observations under similar conditions. An Activity Monitor Energy Impact value is a diagnostic signal, not a direct battery-runtime guarantee. A single “0% CPU” sample does not prove a tool never uses CPU.

2. Identify running containers and their work

These commands inspect your setup; they do not delete data:

docker ps docker stats --no-stream

Check for services you left running from other projects. Inspect repeated application errors, queue retries, and rebuild loops. A quiet web application may still have busy background services.

Stop only containers you recognize and do not currently need. Check running jobs before stopping a worker or database. Do not use volume deletion or aggressive cleanup as a battery troubleshooting step: that can remove development data without explaining the resource use.

3. Check Resource Saver

Docker's Resource Saver documentation describes how it stops the Linux VM after a configurable interval with no containers running. The documented default interval is five minutes, and the feature is enabled by default.

Check Docker Desktop → Settings → Resources for the relevant controls in your installed version. If your database, queue, or other container remains running, the “no running containers” condition has not been met. Resource Saver is not the same as making active container workloads free of resource costs.

If you are done with container work for the day, stopping the unneeded services and letting Resource Saver activate—or quitting Docker Desktop—may be sufficient. You may not need to migrate your project at all.

4. Review filesystem sharing and file watchers

Linux containers on a Mac access host-mounted source through a sharing boundary. The impact depends on Docker's current backend, sharing configuration, and the project's access pattern.

For a PHP project, investigate frequent source scans, dependency access, generated caches, and frontend rebuild activity. Keep watcher scope focused on files that actually need rebuilding. Compare changes one at a time and measure the same request or development task again.

Avoid copying a tuning recipe blindly. Moving files or dependencies into a volume can change how editors, tests, and package managers see them; evaluate that against your team's setup.

5. Decide whether Linux containers are a requirement

Containers remain useful when your application depends on Linux-specific behavior, image-based team environments, or a collection of services defined in Compose. Running PHP directly on macOS does not provide identical Linux behavior or container isolation.

For projects that need local PHP, a database, HTTPS, and development tools without container-specific requirements, a native environment is another option. Removing the Linux VM changes the architecture, but it does not guarantee a particular CPU percentage or battery duration. Native databases, queue workers, and build tools still do real work.

6. Evaluate Stratos with one project

If a native stack fits your requirements:

  1. Keep the project source and development database backed up. Preserve your existing container configuration so you can return to it.
  2. Install Stratos and link the project under Sites. Select the installed PHP version and required extensions.
  3. Start the local services the project actually needs. Configure database host, port, credentials, cache, queue, and mail settings for those services. A Compose service hostname usually will not resolve as a local macOS database address.
  4. Review the site's .test domain and HTTPS configuration. Check Laravel's application URL and any callback URLs.
  5. Run your application's checks: database access, authentication, assets, jobs, scheduled tasks, and tests. Migrate development data deliberately rather than assuming container volumes are automatically imported.
  6. Compare the same workload again. If Linux behavior is required or compatibility differs, retain the container setup for that project.

Stratos's Free edition includes core hosting and selected development tools. Advanced service management and integrated workflows have plan-specific limits; review current pricing before relying on a paid feature.

Stratos 1.7.1 also includes a Free MCP schema bridge for coding agents. It can help an agent inspect permitted table metadata; it does not diagnose battery use automatically. See Local AI & MCP setup.

What a credible battery comparison should publish

If you share before/after results, include hardware, OS/tool versions, the exact application and services, workload, duration, power settings, and repeated measurements. Disclose whether Docker Resource Saver was active and whether containers were still running.

Without those details, fixed claims such as “Docker always uses 15–40% idle CPU,” “native means 0% CPU,” or “switching guarantees all-day battery” are too broad. The practical goal is to reduce unnecessary work while preserving the environment your application needs.

References: Docker Resource Saver, Docker Desktop settings, Stratos installation, and the original guide.