I like living slightly ahead of the stability curve when I want to try a feature that hasn’t landed in a stable release yet, and Docker has always had a channel for exactly that: experimental binaries and experimental feature flags. This guide covers how I get access to experimental Docker builds, how I enable experimental CLI and daemon features on a stable install, and what the trade-offs are for using them.
What “Experimental” Means in Docker
Docker ships along multiple channels:
- Stable: fully supported, production-ready releases.
- Test: release candidates undergoing validation before promotion to stable.
- Nightly/Experimental: built from the latest development branches, containing features still under active development that may change or be removed without notice.
Separately, even stable Docker releases include an experimental flag that unlocks certain features (like docker manifest in older versions, checkpoint/restore, or specific BuildKit capabilities) that are considered not yet ready for default-on status.
Step 1: Check Your Current Docker Channel and Experimental Status
docker version
Client: Docker Engine - Community
Version: 27.3.1
API version: 1.47
Go version: go1.22.7
...
Server: Docker Engine - Community
Engine:
Version: 27.3.1
Experimental: false
Experimental: false tells me the currently running daemon has experimental features disabled.
Step 2: Enable Experimental Features on a Stable Daemon
I edit (or create) the daemon configuration file:
sudo nano /etc/docker/daemon.json
{
"experimental": true
}
Then restart Docker for the change to take effect:
sudo systemctl restart docker
Verify:
docker version --format '{{.Server.Experimental}}'
true
On Docker Desktop (Mac/Windows), the same toggle exists under Settings → Docker Engine, where I edit the same JSON block directly in the GUI, then click Apply & Restart.
Step 3: Enable Experimental CLI Features Independently
The Docker CLI has its own, separate experimental flag, controlled in ~/.docker/config.json:
{
"experimental": "enabled"
}
This unlocks CLI-only experimental subcommands regardless of whether the daemon itself has experimental mode on.
Step 4: Installing Nightly/Experimental Binaries Directly
For trying genuinely bleeding-edge builds rather than just flipping a flag on a stable release, Docker publishes nightly builds separately from its stable APT/YUM repositories. On a test machine (never production), I’d point the package manager at the test or nightly channel:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) test" | sudo tee /etc/apt/sources.list.d/docker-test.list
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
Note the test channel name in the repository line (replacing the usual stable) — this is what pulls candidate builds ahead of general availability.
Step 5: Try an Experimental Feature
A well-known experimental feature historically has been checkpoint/restore support via CRIU, which lets me freeze a running container’s full process state to disk and restore it later, even on a different host.
docker checkpoint create my-container checkpoint1
checkpoint1
docker checkpoint ls my-container
CHECKPOINT NAME
checkpoint1
Restoring:
docker start --checkpoint checkpoint1 my-container
This entire feature only exists when experimental mode is enabled and CRIU is installed on the host — a good illustration of how experimental features often depend on additional system packages beyond Docker itself.
Internal Working: How the Experimental Flag Actually Gates Code
Inside the Docker Engine source, experimental-only code paths are compiled into every binary but guarded behind runtime checks against the daemon’s configuration (Experimental boolean in the daemon’s config struct). When a client calls an experimental API endpoint or CLI subcommand, the daemon checks this flag before executing the corresponding logic; if it’s off, the daemon returns an explicit error rather than silently ignoring the request. This is why simply installing a newer binary isn’t always enough — the flag must be explicitly set for daemon-side experimental behavior to activate, whereas CLI-only experimental commands only depend on the client-side flag in ~/.docker/config.json.
Networking and Storage Considerations
Some experimental networking features (historically things like specific IPv6 improvements or new network driver capabilities) only become available once the daemon flag is set, and can behave differently across Docker versions since they’re actively evolving. I avoid depending on experimental networking behavior for anything beyond a lab environment, since the underlying implementation can change between nightly builds without a deprecation notice.
Similarly, experimental storage drivers or checkpoint/restore features write additional state to /var/lib/docker/ that stable tooling may not know how to interpret, so I keep experimental hosts isolated from backup or monitoring tooling tuned for stable Docker installs.
Security Considerations
- Experimental features are explicitly unsupported for production and may contain unpatched security issues that haven’t gone through the same review as stable features.
- Nightly builds pull from development branches that may include debugging code, verbose logging of sensitive data, or incomplete input validation.
- I only run experimental Docker installs in disposable VMs or containers-within-VMs that I can destroy easily, never on a host with production workloads or sensitive credentials.
- If experimenting with checkpoint/restore, be aware that process memory checkpoints can contain sensitive in-memory data (session tokens, decrypted secrets) written to disk in plaintext by default.
Troubleshooting
“Error response from daemon: this feature is disabled and needs to be enabled by daemon.json” Almost always means experimental: true is missing or wasn’t picked up because the daemon wasn’t restarted after editing daemon.json. Validate the JSON is syntactically correct:
sudo dockerd --validate
Experimental feature works from the CLI directly but not via docker compose or scripts Check that any automation invoking Docker also reads the intended ~/.docker/config.json, especially in CI systems where the home directory or user context may differ from your interactive shell.
Nightly build breaks an unrelated command This is expected occasionally — nightly builds are, by definition, less tested. Roll back to the stable channel:
sudo apt-get install docker-ce=<stable-version-string>
Monitoring
Because experimental features change quickly, I keep closer tabs on the changelog and release notes than I would with stable Docker:
docker version
docker info --format '{{json .}}' | jq '.ExperimentalBuild'
I also tag any host running experimental Docker distinctly in whatever inventory/monitoring system I use, so alerts and dashboards don’t quietly conflate its behavior with stable production hosts.
Best Practices
- Only enable experimental mode on dedicated test/lab machines.
- Track which specific experimental features you’re relying on and check each Docker release’s notes for promotion to stable or removal.
- Never use nightly binaries for anything customer-facing.
- Keep experimental and stable Docker hosts in clearly separate environments (different VMs, different CI runners) to avoid cross-contamination of behavior.
- Revisit experimental flags periodically — many features graduate to stable and no longer need the flag at all.
Summary
Docker’s experimental channel — both the nightly/test binaries and the experimental daemon/CLI flags — gives me an early look at features still under development, from checkpoint/restore to newer CLI subcommands. The trade-off is real: less stability, less security review, and behavior that can shift between builds. I treat it strictly as a sandbox for learning what’s coming next, not as infrastructure I’d trust with anything important.
References
- Docker Engine release notes: https://docs.docker.com/engine/release-notes/
- Docker daemon configuration reference: https://docs.docker.com/reference/cli/dockerd/
- Docker experimental features overview: https://github.com/moby/moby/blob/master/docs/experimental/README.md
- CRIU project (checkpoint/restore): https://criu.org/