Capability

Docker, without memorising the flags

Inspect containers, read logs, check stats, restart services and run Compose stacks, just by describing what you want.

Docker Engine Docker Compose Compose v2 Linux hosts Windows hosts Multi-container stacks Bind mounts and volumes Container networks Health checks
In your words

Ask it like this

No syntax to learn. These are real requests, phrased the way people actually phrase them.

›why does this container keep restarting ›show me the logs for the api container, last 200 lines ›which container is eating all the memory ›restart the worker but tell me what it was doing first ›is anything on this server not running that should be ›bring the compose stack up in /opt/myapp ›what changed about this container since the last deploy
Capability

What it does here

Everything below is what the agent does today, not a roadmap.

  • List and inspect containers across every server you have registered
  • Read logs and resource stats to find the container that is actually failing
  • Restart, start and stop containers, each one confirmed before it happens
  • Read and run Docker Compose stacks, with the project name handled correctly
  • Run read-only diagnostics inside a container, or an arbitrary command with approval
What it looks like

One question, one answer, one fix

The checks on the left of each reply are the reads it did before committing to an answer. That is the difference between a diagnosis and a guess.

Every exchange ends in a verified outcome. It goes back and confirms the result rather than assuming the fix worked.

brynko devOps Agent

the checkout container keeps restarting

read container state checked health check listed ports

It restarts every 40 seconds, and it is the health check failing rather than the app. The check calls /healthz on port 8080, but the app is listening on 3000, so it never passes and Docker keeps killing it.

fix it

one line in compose restarted watched 5 minutes

Done. I corrected the health check port and restarted the service. It has stayed up since, and the check is passing.

Fixed · container healthy
Common cases

The ones that cost you an afternoon

Each of these is a specific failure with a specific set of checks behind it, not a general promise to help.

Container keeps restarting

It comes up, dies a few seconds later, and comes back. The restart count climbs and the logs scroll past before you can read them.

What it does. It reads the container state, the restart policy, the health check and the port map, then tells you which of those is actually failing rather than listing all four as possibilities.

Container exited with code 137

The service dies under load and nothing in the application log explains it, because the application never got to write one.

What it does. Exit 137 means the kernel killed it, almost always the memory limit. It checks the configured limit against usage history and tells you what the ceiling is and what the job needs.

docker compose up fails

It works on one machine and not another, and the error mentions a file or a port rather than your code.

What it does. It reads the compose file, resolves the project name the way Compose does, and checks whether the port is taken, the bind-mount path exists, and the image is present.

Port is already allocated

A container will not start because something else is holding the port, and it is not obvious what.

What it does. It lists what is bound to that port, whether the holder is another container or a host process, then shows you the options before changing anything.

The app cannot reach the database

One container cannot talk to another, and every guide online tells you to check five different things.

What it does. It checks the network both containers are on, whether the target is actually up, and whether the hostname resolves inside the container. It reads the log line rather than any credential value.

The server is out of space

Deploys start failing and the disk is full, but the offender is not obvious.

What it does. It finds what is consuming the space, which is usually unrotated container logs or old images, and offers to clear it with a retention limit so it does not recur.

Start to finish

What happens between the question and the fix

  1. You ask in plain language

    No flags to remember and no need to know whether it is docker inspect, docker stats or the compose file that holds the answer.

  2. It runs read-only checks

    Container state, logs, resource use, port maps, compose config. Reads need no approval because reading cannot break anything.

  3. It commits to one cause

    Not a list of five possibilities. It quotes the log line or config value the conclusion rests on, so you can check its work.

  4. You approve the change

    It tells you what it is about to change and shows it, as the command it will run or a diff of the file. Nothing happens until you say so.

  5. It verifies

    Then it goes back and confirms the container is actually healthy, rather than assuming the restart worked.

The part that matters

Reading is free. Changing asks first.

Reads run instantly and need no permission, because reading cannot break anything. Anything that changes a system, whether that is a restart, an edit, an install or a delete, stops and tells you what it is about to change, on which server, and why. You see it written out, as the command it will run or a red and green diff of the file, so you are approving the actual thing rather than a description of it. Changes are backed up first, so undoing one is a click.

Read the security model
Questions

Docker, specifically

Do I need to install anything on the server?
No. It uses the Docker CLI already on the machine, reached over the SSH access your team already has. There is no daemon to expose, no socket to publish, and no agent to roll out.
Can it restart containers on its own?
No. Reading container state, logs and stats happens freely because it is harmless. Anything that starts, stops, restarts or recreates a container stops first and tells you what it is about to do to which container, showing you the command, and waits for you to approve it.
Does it work with Docker Compose?
Yes, including reading the compose file to understand how the stack fits together. It handles the project name the way Compose does, which is a common source of confusion when a stack is started from a different directory than usual.
Can it read my environment variables?
It can see which variables exist, and by default it can also see their values, because that is what makes it useful when you are editing or deploying. Private key material is never sent under any setting, and your account can be switched to a strict mode that masks config and environment values as well. See the security page for exactly where the line sits.
Does it work on Windows hosts?
Yes. It detects the operating system when it connects and uses the right commands and quoting for that machine, so a Windows container host is not a special case.
Can it run a command inside a container?
Yes. Read-only diagnostics inside a container run freely, and any other command is shown to you and gated behind approval like every other change.
Also covered

The rest of the stack

Your reverse proxy, explained and fixed

Test configs before they go live, read the right log, and reload safely, on nginx, IIS or Tomcat.

Read more →

Ship it, and know what shipped

Run your existing deploy scripts, watch the output live, and get a straight answer about whether it worked.

Read more →

Ask your database what is wrong

Read-only checks and queries over your existing SSH connection, with credentials encrypted at rest.

Read more →

Wildcard HTTPS, sorted in one step

Issue trusted, auto-renewing certificates, wildcards included, and get the paths handed straight back.

Read more →

Your AWS account, in plain English

Read EC2, S3, Elastic IPs and EBS, spot what is quietly costing you money, and make changes only after you approve them.

Read more →

Ask Jenkins what went wrong

Read jobs, builds, the queue and console logs, find out why a build failed, and trigger or stop builds with your approval.

Read more →

Try it on something that already annoys you

Point it at one server. You will know within an hour whether it earns its place.