Dockhand v1.0.55 schedules containers by time

Not every container needs to run around the clock

In a homelab, it is easy to leave services running simply because they were started once. A media server, a development environment, or an internal tool may have no reason to stay online overnight. Automating that decision is better than relying on somebody remembering to stop and start containers manually.

Dockhand v1.0.55 adds scheduled starts and stops for individual containers. The schedule can be managed in its interface, but the useful part for me is declaring it through Docker Compose labels. That turns a UI-only setting into configuration that lives with the project repository.

Keep the policy next to the service

The new labels are dockhand.start.at and dockhand.stop.at. Both accept either a daily HH:MM time or a five-field cron expression. Cron follows the usual field order: minute, hour, day of month, month, and day of week.

This example makes a Laravel development environment available on weekdays during working hours. It is not a universal deployment template, but it shows the right use case: the container lifecycle is defined beside the service itself. When the stack is deployed again, the schedule comes with it.

services:
  laravel:
    build: .
    labels:
      - "dockhand.start.at=0 8 * * 1-5"
      - "dockhand.stop.at=0 20 * * 1-5"

A value such as 23:30 runs the action every day at that time. Cron is there for weekly schedules and less regular patterns, without adding separate scripts on the host. In this example, the container starts at 08:00 and stops at 20:00 from Monday through Friday.

A sensible fit for Laravel and homelabs

I find this especially useful for Laravel development or test environments hosted on a home server. If a project has its own application container, queue worker, or development service, I can choose which ones should follow the schedule and which should not. A database deserves a separate decision when it is shared by more than one project.

The same idea works for homelab services that create noise, consume resources, or are simply unnecessary outside certain hours. It is not a host-wide power-saving strategy, but it does make selective shutdown practical. Since the policy lives in compose.yaml, anyone deploying the stack can see which services are expected to run and when.

The details that matter

Compose labels take precedence over schedules configured through Dockhand’s container editor. Once either label is present, the editor shows the schedule as read-only, so changes must be made in the Compose file. Removing the labels later does not restore a schedule that was previously configured in the interface.

Schedules use the timezone configured for the Dockhand environment, not a timezone inside each individual container. Dockhand also checks labels periodically, so a schedule added in a deployment may take up to five minutes to appear on the schedules page. I would verify the environment timezone before trusting a cron rule with overnight shutdowns.

This is not an orchestrator

The feature starts and stops containers; it does not handle application dependencies, migrations, pending jobs, or graceful shutdown design for a complex stack. If I stop a Laravel worker while it is processing a job, the application still needs to be configured to handle that shutdown correctly. Databases and stateful services should be tested with a normal container stop before putting them on a fixed timetable.

A scheduled start for an already running container, or a scheduled stop for one that is already stopped, is recorded as skipped. A paused container counts as running for a stop action, while a scheduled start does not unpause it. These labels are also unavailable for the Dockhand and Hawser containers themselves.

For isolated services, development labs, and applications with clear usage windows, this removes the need for small cron scripts scattered across the host. For critical infrastructure, I would not treat it as a replacement for a full operational plan. Its value is making a simple runtime policy explicit and keeping it versioned with the stack.

• Source: Dockhand
• Official documentation: Dockhand User Manual