Capability

From code to a running site, and know what shipped

It builds the deployment with you: the deploy script, Docker, nginx and pipeline files, a ready server, then the release itself, checked afterwards.

Deploy scripts it writes or you have Bash PowerShell Docker and Compose Jenkinsfile GitHub Actions Terraform nginx and IIS Linux and Windows servers
In your words

Ask it like this

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

›this server is brand new, get the app live on it ›write a deploy script for this project and save it ›add a Jenkinsfile that builds and deploys to staging ›write the Terraform for one EC2 instance and plan it ›deploy the latest to staging ›why did the deploy fail last night
Capability

What it does here

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

  • Writes the deploy script for your project in Bash or PowerShell, saved in your script library to run again
  • Writes the Dockerfile, compose file, nginx site and CI pipeline file (a Jenkinsfile or a GitHub Actions workflow), each shown as a diff first
  • Writes Terraform files and runs terraform plan and apply on your machine, each command approved by you
  • Sets up a bare server: installs Docker, nginx, a database and certbot, moves the app across, issues the certificate
  • Already have scripts or a pipeline? It reads and runs those instead, and triggers your Jenkins builds
  • Streams the output live, reads a failure for its cause, and checks the site afterwards, with every step in an audit log
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

this project has no deploy yet, get it onto staging

read the project checked the server drafted the deploy script

It is a Node app with a Dockerfile but no deploy script. I have drafted one that builds the image, replaces the container and reloads nginx; approve it on the card and it is saved to your scripts under Staging. Then shall I run it?

go ahead

streamed the run container replaced site responded

Finished in 1 minute 52. The new container is running, nginx reloaded cleanly, and staging is returning 200. Next time it is one click in Scripts, or just ask.

Deployed · staging 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.

There is no deploy process at all

Releases are a person typing commands from memory on the server, slightly differently each time.

What it does. It reads the project and writes the deploy script, the Docker and nginx files and a CI pipeline file for it, shows you each one, and saves the script in your library so the next release is one click.

The server is brand new

There is nothing to deploy onto yet, so the first release means an afternoon of setup before any code moves.

What it does. It installs what the project needs, sets up the web server, moves the app across and issues the certificate, showing you the whole plan before step one.

Only one person can deploy

The steps live in one engineer's head, so releases queue behind whoever knows the order and the gotchas.

What it does. The steps become a script in a shared library, organised by group, with every version kept. Anyone asks in plain language, sees the plan, and watches each step run.

The deploy script failed and the output is gone

It ran, something broke, and the terminal that had the output is closed.

What it does. Output is streamed and kept, so the failure is still there to read afterwards. It reads the actual error rather than reporting that the script exited non-zero, and can fix the script with you.

It said success but the site is unchanged

The script exits zero, and yet the old version is still being served.

What it does. It confirms afterwards rather than trusting the exit code: what is actually running, whether the service restarted, and whether the site responds.

Setting up a second environment

A new environment means copying a working one and carefully changing the parts that differ, which is exactly where mistakes hide.

What it does. It copies the configuration on the server and changes only the keys that should differ, showing you a diff of each one before writing.

Start to finish

What happens between the question and the fix

  1. You say what you want shipped

    Which project, which server, in plain words.

  2. It reads the project first

    The stack, the build, and any deploy script or pipeline you already have.

  3. It writes what is missing

    The deploy script, Docker and nginx files, a pipeline file or Terraform, each shown to you before it is saved.

  4. You see the plan before step one

    Every step listed up front, and each command shown as it comes.

  5. It runs and confirms what shipped

    Output live, then a check that the service is running and the site responds, recorded in the audit log.

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

Deployments, specifically

Do I need a deploy script or a pipeline first?
No. It writes them with you: the deploy script, the Docker and nginx files, and a pipeline file for Jenkins or GitHub Actions, each shown before it is saved. If you already have scripts or CI, it uses those instead.
Does it replace our CI pipeline?
It does not have to. If you have CI, it triggers and reads your Jenkins builds and can write or update the pipeline file in your repository. If you have none, it can write one, or deploy straight from a script.
Can it work with Terraform?
Yes. It writes the Terraform files and runs terraform plan and apply on your own machine, each command shown to you and approved first, so your state and credentials stay where they are.
Can it deploy without asking me?
No. You see the plan before anything starts and each step before it runs. On a system that earns money, an unattended deploy is a risk we did not want to offer.
Where do the scripts it writes go?
Into your script library in the app, organised in groups, with every version kept in history. You can open, edit and run each one yourself, or ask the agent to.
Is there a record of what was deployed?
Yes. Every action, the approval and the result are written to an audit log you can read, which is usually the fastest answer to "what changed this afternoon".
Also covered

The rest of the stack

Every script in one place, written with you

A library for every script your team runs on its servers: written with the agent or by you, organised in groups, every version kept, run with one click.

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 →

It runs on your machine too

Build, run and fix projects on your own computer, including installing the runtime the project needs.

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.