Capability

Wildcard HTTPS, sorted in one step

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

Wildcard certificates DNS validation Cloudflare DNS Automatic renewal nginx Apache Caddy IIS Linux and Windows
In your words

Ask it like this

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

›is anything about to expire on these servers ›get me a wildcard certificate for example.com ›when does this certificate expire ›why is the browser saying the certificate is invalid ›is renewal actually set up on this server ›where are the certificate files for this domain
Capability

What it does here

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

  • Covers your apex domain and every subdomain in a single certificate
  • Validated over DNS, so there is no downtime and no traffic rerouting
  • Checks the prerequisites first and walks you through anything missing
  • Your DNS provider token stays on the server, and the agent never reads it
  • Renews itself, so nobody gets the expiry surprise
  • Hands back the certificate and key paths, so it works whether you run nginx, Apache, Caddy or IIS
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

anything about to expire on these servers?

checked 6 servers read certificate dates checked renewal

One. The certificate on api.example.com expires in 6 days and renewal is not set up, so it will not fix itself. Everything else has more than 60 days.

get a wildcard for the whole domain instead

validated over DNS issued wildcard renewal scheduled

Issued. It covers example.com and every subdomain, so new environments are already included. Nothing went offline during validation, and renewal is scheduled. The certificate and key are on the server and I have given you both paths.

Issued · renews automatically
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.

The certificate expired

The site is throwing browser warnings and customers are the ones telling you. Renewal was supposed to be automatic and quietly was not.

What it does. It issues a replacement over DNS validation, so nothing has to go offline for the challenge, and sets up renewal properly this time so the same thing does not happen next quarter.

A new subdomain has no certificate

Every new environment means another certificate request, another renewal to remember, and another thing to forget.

What it does. One wildcard covers the apex domain and every subdomain under it, so new subdomains are already covered rather than becoming a task.

Renewal fails silently

The renewal job exists, it has been failing for weeks, and nobody noticed because nothing alerts on it.

What it does. It checks whether renewal is genuinely configured and working, rather than whether a job merely exists, and tells you which certificates are actually at risk.

Nobody knows what is about to expire

Certificates live on several servers, issued by different people at different times, and there is no single list.

What it does. It checks every server you have registered in one pass and gives you the expiry dates together, so the surprises stop being surprises.

HTTP validation means downtime

The usual approach needs port 80 free or traffic rerouted, which is awkward on a live site behind a proxy.

What it does. Validation happens over DNS instead, so the site keeps serving traffic throughout and no ports need to be opened or freed.

The certificate is issued but the site still fails

Files exist on disk and the browser still complains, usually because the web server is pointed somewhere else.

What it does. It tells you exactly where the certificate and key were written, so you can point the web server at the right paths, and can show you that config change as a diff.

Start to finish

What happens between the question and the fix

  1. You name the domain

    That is the whole input. Wildcard coverage is the default, because per-subdomain certificates are how renewal debt accumulates.

  2. It checks prerequisites first

    DNS access, the tooling on the server, and whether a certificate already exists. If something is missing it says so before starting rather than failing halfway.

  3. You approve the issue

    Shown before it runs, like every other change.

  4. Validation happens over DNS

    No downtime, no port 80 juggling, and no traffic rerouted. Your DNS provider token stays on the server and is never read by the agent.

  5. You get the paths back

    Certificate and key locations, handed straight back. It does not reach into your web server config uninvited, which is why this works the same whether you run nginx, Apache, Caddy or IIS.

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

Ssl, specifically

Does the site go down while the certificate is issued?
No. Validation happens over DNS rather than HTTP, so port 80 does not need to be free and no traffic is rerouted. The site keeps serving throughout.
Can the agent read my DNS provider token?
The token stays on the server and is used by the tooling there, so issuing a certificate does not require handing it to the agent. Key material is also masked unconditionally on the way to the model, and the credential directories these tokens usually live in are refused outright.
Will it change my nginx or Apache config?
Not on its own. It issues the certificate and hands you the file paths. That is deliberate: touching a live web server config as a side effect of a certificate request is how sites go down. If you want the config change too, it will show you the diff and wait for approval like any other edit.
What happens when the certificate expires next time?
Renewal is set up as part of issuing, so it renews itself. It can also check across every registered server whether renewal is genuinely working, which is a different question from whether a renewal job exists.
Does a wildcard cover the main domain too?
Yes. One certificate covers the apex domain and every subdomain under it, which is what stops new environments turning into new certificate tasks.
Does this work on Windows servers?
Yes. The certificate and key are handed back the same way, and IIS can be pointed at them like any other web server.
Also covered

The rest of the stack

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 →

A real file editor for your Linux servers, no nano required

Browse your Linux servers as a file tree and edit files in a real editor with syntax highlighting, find and replace and search across the whole box. Over the SSH access you already have, with nothing installed on the server.

Read more →

Docker, without memorising the flags

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

Read more →

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 →

Try it on something that already annoys you

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