Eight.ly Agent
More hosts. One place to operate them.
One dashboard should not mean one machine. We built Eight.ly Agent to extend container management to remote Docker hosts, so adding another box does not mean adding another daily management routine.
Explore the Eight.ly system- Linux · macOS · Windowsplatform support
The management agent handles platform-specific Docker access and native Windows service management.
- 30 secondsregistration heartbeat interval
The documented protocol interval for a connected agent.
- One-time enrollmentexplicit host registration
Eight.ly OS generates the enrollment command; ongoing management uses authenticated TLS.
- Enroll a hostRegister the agent with a one-time token.
- Choose an environmentSelect the local machine or a remote Docker host.
- AuthenticateCarry operations over TLS to the registered agent.
- Operate DockerReturn container state, logs, console and volume access.
The problem
A local container dashboard becomes a bottleneck as soon as the next host arrives. Logs, consoles, volume files and host details live elsewhere. Copying a dashboard onto each machine moves the problem into a collection of browser tabs.
Remote access also changes the trust boundary. A tool that can control Docker can control the host. The connection needs an explicit enrollment and authentication model, not an open socket with a friendly interface.
Who it’s for
For operators whose applications are spread across Linux servers, a Mac or Windows Docker host. This is the Docker management agent; the separately trained Eight.ly Agent AI model is a different part of our work.
What we built
We built a cross-platform management daemon that exposes authenticated container operations to Eight.ly OS. It includes an interactive container console, file browsing within Docker volumes, host information and registration with ongoing heartbeat reporting.
The dashboard's environment selector lets an operator move between local and remote hosts. The agent keeps the operating-system differences at the edge, including a native Windows service, rather than asking the person using the dashboard to learn another workflow.
How it works
A host enrolls with a one-time token and persists its registration state. Subsequent requests travel over authenticated TLS. The agent forwards the permitted management request to the local Docker interface and returns the result to the dashboard.
Heartbeats let the dashboard distinguish a registered host from a host it can currently reach. Certificate pinning preserves the trust established at enrollment, while separate liveness and readiness probes distinguish an agent process that is running from one that can actually reach Docker.
What was hard
Keeping a small remote service trustworthy means handling its less visible details: protecting the token on disk, renewing it, refusing unsafe saved state and making an expired registration recoverable. The documentation names the Docker access boundary explicitly because a management credential is powerful.
Long-running credentials need a recovery path too. The agent renews its bearer token before expiry. A host that has been offline past expiry is marked as needing re-enrollment, giving the operator a visible next action instead of an unexplained connection failure.