Use cases

Find your week in here

The work looks different depending on who you are. A solo developer wants their Sunday back. An ops lead wants their queue back. Below are the situations people actually bring to it, and what happens next.

Solo developer Product team Agency and consultancy Ops and platform All 32 situations
In short

Who this is for

Solo developer

A freelance or indie developer running their own VPS, side project or client site, with no dedicated operations support.

Product team

An in-house engineering team of roughly three to thirty people, shipping a product they also operate, usually without a dedicated platform team.

Agency and consultancy

A web agency, consultancy or managed-service provider maintaining infrastructure for multiple clients, often inherited and rarely documented.

Ops and platform

An operations, platform or SRE function supporting developers who need answers about infrastructure faster than a ticket queue can provide them.

Common to all four: the software runs on your own machine, reaches servers over the SSH access you already have, and never changes anything without a person approving it first.

The same incident

Nine steps, or three

A 502 on a Tuesday afternoon. Below is the path by hand, and the path when you can just ask. The difference is not cleverness, it is how many times you have to context switch.

By hand 9 steps With the agent 3 steps
By hand
  1. Notice the site is down
  2. SSH into the server
  3. Work out which log is the right one
  4. Grep it for something useful
  5. Check whether the app is running
  6. Check which port it is on
  7. Open the vhost and compare the two
  8. Edit it, test it, reload
  9. Check the site actually came back

Your part: all nine, across three or four tools, in whatever order you happen to remember them.

With the agent
  1. Ask why the site is down it reads the error log, the vhost and the listening ports together, in one pass, in seconds
  2. Read the cause, with the evidence attached nginx is fine and the app is fine: the app moved to a different port at the last deploy and the vhost still points at the old one
  3. Approve the one-line change it validates the config before applying it, reloads, then confirms the site is answering again

Your part: one question and one decision. Every check in the left column still happens. You are just not the one running them.

Solo developer

You wrote it, so you also run it

There is no ops team to hand it to. Every hour on the server is an hour not on the product, and the parts you touch twice a year are the parts you relearn every time.

My site is down and I do not know why

It checks the web server, the app, the ports and the logs in one pass and tells you which layer actually failed, so Sunday is not spent bisecting your own stack.

I only set this server up once and cannot remember how

It reads the server and describes how it is actually wired right now, rather than making you reconstruct it from memory or old notes.

The certificate expired again

A wildcard certificate that renews itself, covering every subdomain, so the yearly surprise stops being an annual event.

brynko devOps Agent

my site is down and I have no idea why

checked the web server read the error log listed ports

nginx is running and returning 502. The upstream your site points at has nothing listening on it, because the app container exited 11 minutes ago and did not come back. So the proxy is fine, the app is the problem.

start it and tell me why it stopped

started the container read the exit reason checked memory

Back up, and the site is responding. It exited on code 137, which means it hit its memory limit during the nightly job. That will happen again next week unless the limit goes up.

Site back up · cause known
What changes
  • Deploy onto a bare server without five tabs of documentation open
  • Ask what broke instead of grepping four log files to find out
  • Certificates that renew themselves
  • A record of what you changed, for the version of you that comes back in six months
Product team

Everyone can ship, not just the person who set it up

The bottleneck is rarely the code. One person understands the deploy, so every release and every incident routes through them, and onboarding a developer costs the team two days.

A new developer cannot build the project

It reads the project, finds the runtime version it actually targets, installs it alongside what they have, and gets the build green on day one instead of day three.

Only one engineer knows how to deploy

The steps stop living in one head. Anyone asks in plain language, the plan is shown before it runs, and every step is visible as it happens.

Nobody wants to touch the server config

Changes are shown as a diff before they are written and snapshotted before they are applied, so trying something stops being a gamble.

brynko devOps Agent

this build works for everyone but me

read the project checked your runtimes compared versions

Your project targets Java 8. You have 17 installed and nothing else, which is why it fails on this machine and passes on everyone else's. I can install 8 alongside your 17 without touching it.

go ahead

installed Java 8 left 17 in place re-ran the build

Java 8 is installed, your 17 is untouched, and both are on the machine. I re-ran the build and it compiled.

BUILD SUCCESS in 41s
What changes
  • A new joiner is productive on day one, not day three
  • Any developer can deploy, because every step is shown first
  • Changes are reversible, so nobody is afraid of the server
  • A shared audit log answers "what changed this afternoon"
Agency and consultancy

Twelve clients, twelve different stacks

Every client server was built by someone else, at some other time, to some other standard. Context switching between them is the job, and the cost is paid in hours nobody can bill.

What is even running on this client server

It reads the machine and reports what is actually there: operating system, web server, containers, databases, certificates and when things were last touched.

The person who set this up has left

The server itself becomes the documentation, because everything reported comes from reading the live system rather than a wiki nobody updated.

One client is on Windows and IIS

It detects the operating system on connect and uses the right commands for that machine, so a Windows client stops being the one nobody wants to pick up.

brynko devOps Agent

what is even running on this server

read the OS listed services checked certificates

Ubuntu 22.04, nginx in front of three containers, PostgreSQL on the host rather than in Docker, and a certificate that expires in 9 days. The deploy script in the project folder was last modified in March.

write that up so I can put it in the handover

collected the facts wrote the summary saved it

Written up, with where each fact came from so it can be checked rather than trusted. It reflects the server as it is right now, not as it was documented.

Handover ready
What changes
  • Understand an inherited server before touching it
  • Windows and Linux clients handled the same way
  • Billable hours spent on work, not on relearning environments
  • An audit log that makes the client conversation easier
Ops and platform

Stop being a lookup service

Most questions reaching you are not hard, they are just questions only you can answer today. That queue is why the actual platform work keeps slipping.

The same five questions every week

Developers self-serve the read-only answers, and you keep approval on anything that changes. The queue shortens without the access widening.

Giving a developer shell access feels risky

Restricted paths and elevated access are set per server, by you, and every change still stops for a person.

Which servers need attention right now

One pass across every registered server for disk, memory, services and certificates, instead of checking them one at a time.

brynko devOps Agent

which of our servers need attention

checked 6 servers disk, memory, services certificates

Two. web-03 is at 94 percent disk, almost all of it unrotated container logs going back to January. db-01 is climbing about a gigabyte a week on memory. The other four are fine, and no certificate expires within 60 days.

clear web-03, keep something recent

kept the last day cleared the rest added rotation

web-03 is at 58 percent. I kept the last day of logs and added a size limit so it does not come back. The looping error that produced them is still there if you want me to look.

web-03 · 58% disk
What changes
  • Fewer interruptions, without handing out more access
  • Scope set per server by you, elevated rights off by default
  • One pass across the fleet instead of one server at a time
  • A shared log of who did what, and who approved it
Situation index

Twenty-four things people actually ask

Grouped by where the problem lives. If yours is not here, it is probably close to one that is, because the method is the same: read the real state, then act with your approval.

Docker

A container keeps restarting
Reads the container state, health check and port map, then names which one is failing.
Container exited with code 137
That is the kernel killing it on the memory limit. It compares the limit against usage history.
docker compose up fails
Reads the compose file, resolves the project name the way Compose does, and checks ports, paths and images.
Port is already allocated
Finds what is holding the port, container or host process, and shows the options before changing anything.

Web server

502 Bad Gateway after a deploy
Reads the error log and the vhost, then checks what is actually listening on the upstream port.
Config changes do nothing
Works out which file genuinely serves that domain and finds the duplicate block or missing symlink winning instead.
nginx shows the default page
Checks server_name matching, whether the site is enabled, and whether the default server catches it first.
Uploads fail over a certain size
Finds which layer sets client_max_body_size, since http, server and location can each cap it.

Deploys

The deploy failed and the output is gone
Output is streamed and kept, so the real error is still there to read afterwards.
It said success but the site is unchanged
Confirms afterwards rather than trusting the exit code: what is running, and whether the site responds.
The server is brand new
Installs what the project needs, sets up the web server, ships the app and issues the certificate, plan shown first.
We need a second environment
Copies the configuration on the server and changes only the keys that should differ, each shown as a diff.

Databases

Too many connections
Compares open connections against the limit and checks whether queries are actually slow, which usually points at the app.
The app cannot reach the database
Checks whether it is accepting connections, whether the port is reachable, and what the log says it is rejecting.
Queries suddenly got slow
Looks at slow-query pressure, table growth and index use, so you learn whether a table outgrew its index.
Is the database even the problem
A few read-only checks rule it in or out, which stops you tuning something that was never at fault.

AWS

Something is open to the internet
Reads every security group and names the rules open to 0.0.0.0/0, so nobody has to parse CIDR lists out of nested JSON. It cannot change the rule itself, so it tells you the exact group, port and range to fix.
Paying for things nobody is using
Unattached Elastic IPs and detached EBS volumes are billed hourly forever. It lists both and marks which are attached to nothing, so the waste is a short list rather than an audit.
The instance is running but nothing responds
Running is not healthy. It reads the EC2 status checks, which fail independently of instance state, and tells you whether the box is failing or only the software on it.
Is this bucket public
Reads the bucket policy, versioning, encryption and public-access block together, and flags any statement granting access to everyone with no condition narrowing it.

Jenkins

The build failed and the log is enormous
Reads the console log and tells you which step failed and why, instead of handing back thousands of lines with the error still buried in them.
A build is stuck in the queue
Reads the queue and the node list together, because a stuck build is almost always an offline agent, a label nothing matches, or an executor already busy.
Which test actually broke
Reads the test results directly and names the failing tests, so triage starts at the test rather than at a red build.
Somebody needs to trigger a deploy
Triggers the job with the parameters you state and shows every one of them first. The approval is bound to those exact parameters, so it cannot start a different deploy.

Certificates

The certificate expired
Issues a replacement over DNS validation with no downtime, and sets up renewal properly this time.
Nobody knows what is about to expire
Checks every registered server in one pass and gives you the expiry dates together.

Servers

The server is out of disk
Finds what is consuming it, usually unrotated logs or old images, and offers to clear it with a retention limit.
A service will not start after a reboot
Reads the service state and the journal, and tells you what it failed on rather than that it failed.
Permission denied writing to a folder
Compares folder ownership against the user the service runs as, and proposes the change as a diff.

Local

It works on everyone else's machine
Finds the runtime version the project targets, compares it with yours, and installs the right one alongside.
A process will not die
Kills the whole process tree rather than the launcher that spawned it.
It starts and immediately exits
Keeps the output, reads the real error, and tells you what the app said on the way down.
Fit check

Where it is not the answer

Three things it does not do, so nobody finds out after buying.

It does not watch your systems around the clock

There is no alerting and no paging. It works when you ask it to. If you need to be woken up at night, you still need a monitoring tool, and this does not replace one.

It does not replace your CI pipeline

If you already have one, keep it. The agent covers the parts either side: the local build that will not start, and the server that needs looking at.

It does not act on its own

Nothing changes without a person approving it. That is deliberate, but it does mean it will not quietly fix things while you sleep.

Questions

Whether it fits you

Is this useful if I am a solo developer with one server?
Yes, and it is one of the clearest cases. With no ops team, every hour on the server is an hour off the product, and the tasks you do rarely are the ones you relearn every time. Being able to ask why the site is down, or have a wildcard certificate that renews itself, removes work that has no one else to go to.
We already have a DevOps engineer. What does this add?
It removes the queue in front of them. Most questions reaching an ops person are not hard, they are just questions only that person can answer today. Developers self-serve the read-only answers, ops keeps approval on anything that changes, and the access does not have to widen for the queue to shorten.
Does it work on servers we inherited and never documented?
That is one of the strongest uses. It reads the live machine and reports what is actually there, including the operating system, web server, containers, databases and certificate expiry, so the server becomes its own documentation instead of relying on notes nobody kept current.
Can several people on a team use it at once?
Yes. Each person uses their own SSH access, so nobody gains reach they did not already have, and the audit log is shared so the team can see what happened and who approved it.
Does it help with Windows servers, or only Linux?
Both. It detects the operating system when it connects and uses the right commands for that machine, including PowerShell, IIS and Tomcat on Windows alongside nginx and system services on Linux.
What is the fastest way to tell whether it will help us?
Point it at one server and ask about a problem you already have rather than a demo scenario. Reading changes nothing, so there is no risk in asking, and an hour is usually enough to know.

Try it on your least favourite server

One machine, one real problem, one afternoon. Reading changes nothing, so the first question costs you nothing either.

Create an account See how it works