An extra pair of hands.Right in your team.

Ryker is a self-hosted AI teammate in Slack and GitHub. It investigates alerts, works on code, and follows through.

Run it yourself View on GitHub

engineering

Thread

Today

You 9:41 AM

The build is green, but the deploy failed again.

@Ryker can you take a look?

Ryker APP9:41 AM

I’ll check the build and the image mirror.

Ryker APP9:43 AM

The mirror is still using the old registry credentials. They rotated at 9:30, but the mirror logs show it hasn’t reloaded them.

pull failed: authentication required

The job template writes the new file, but change_mode = "noop" leaves the process running.

You 9:44 AM

Can you prepare a fix?

Ryker APP9:44 AM

I’ll restart the mirror when its credentials change and add an alert for failed authentication.

Reload registry credentials when they change
Repository: your-team/deploy-tools

Done when:
• Changed credentials reload.
• Authentication failures trigger an alert.

✓ Task started in this thread.

Ryker APP9:44 AM

Reload registry credentials when they change

The request
Restart the mirror when its credentials change. Add an alert for failed authentication.

Progress

✓ Workspace setup

✓ Planning

✓ Implementation · 2/2 subtasks

✓ Reload changed registry credentials

✓ Alert on authentication failures

✓ Self-review and checks

✓ Draft PR #42

✓ CI · 3/3

✓ Review and merge · merged

Repository
your-team/deploy-tools

The pull request was merged. · PR #42

Updated 23 Oct, 09:59 UTC

Ryker APP9:50 AM

Opened #42 · Reload registry credentials when they change. CI is running; I’ll follow up on the results.

Ryker APP10:12 AM

#42 is merged, and the deployment event reports the new revision is running.

The mirror loaded the current credentials. A fresh image pull succeeded.

your-team / deploy-tools

Reload registry credentials when they change #42

MergedYou merged into main from ryker/registry-auth

Reload changed credentials. Alert if signing in fails again.

deploy/registry.nomad.hcl+1 −1

1818 template {

1919 source = "local/auth.ctmpl"

2020 destination = "secrets/auth.json"

21− change_mode = "noop"

21+ change_mode = "restart"

2222 }

alerts/registry.yml+2

1+alert: RegistryAuthenticationFailed

2+expr: registry_auth_errors_total > 0

2+expr: rate(registry_auth_errors_total[5m]) > 0

All checks passed3 / 3

✓FormattingPassed

✓Template validationPassed

✓Alert testsPassed

Ryker bot

The alert test failed because the counter stays above zero after errors stop. I’m switching to a five-minute rate and adding a check that the alert clears after recovery.

alerts/registry.test.yml+4

18+alert_rule_test:

19+ - eval_time: 10m

20+ alertname: RegistryAuthenticationFailed

21+ exp_alerts: []

Ryker added commit 7bd42ea · Fix alert recovery

Ryker bot

The updated commit passes all three checks. The alert now clears once authentication recovers.

You ✓ Approved

Looks good. Marked ready and approved. I’ll merge this now.

You merged this into mainfrom ryker/registry-auth

From “what broke?”
to “here’s why.”

Ask a question, or let Ryker pick up an alert. It reads the conversation, checks the tools you’ve connected, and brings the evidence back to the thread.

Ask a follow-up. Challenge a finding. Point it in another direction. The work stays in the conversation.

Working together in Slack

A fix you can review.
And work that follows through.

Ryker prepares the change in a separate copy of your project that runs inside a sandbox, runs its checks, and can open a draft pull request when you’ve enabled it.

Failed checks and review feedback go back to the same task. Your team reviews and merges. Matching deployment updates bring Ryker back to check the result.

From conversation to pull request

A DevOps teammate.
With the right tools.

Ryker uses co:op’s sandbox to write and test code, and Emisar’s secure remote access to work on your systems. When an alert arrives, it can investigate, prepare a fix, and ask for approval before applying it.

Ryker

The teammate in your chat.

Investigates problems, writes and tests code, opens pull requests, and makes approved changes to your systems.

How Ryker works

co:op

A sandbox for the work.

Runs the model in a container with a separate working copy of your project. A place to read code, prepare a fix, and run its tests.

Explore co:op

Emisar

Secure access to your systems.

Connects the work to your infrastructure and tools. You choose what it can reach, which actions need approval, and see a record of what ran.

Explore Emisar

What’s on your plate?

A change to make. A problem to solve. A conversation worth joining.

Ryker writes the code and sees it through.

Ask for a feature or a fix. Ryker makes a plan, writes the code in its own working copy, runs the tests, and opens a draft pull request.

It fixes failing checks and works through review feedback in the same PR. The task card keeps you up to date, and Ryker asks when it needs a decision.

From request to pull request

engineering

Thread

Today

You 9:41 AM

@Ryker make checkout handle a slow payments API.

Ryker APP9:42 AM

I’ll read your-team/payments-api for its timeout rules, then change checkout and test the retry.

Handle slow payment responses
Repository: your-team/checkout

Done when:
• Checkout handles a slow response.
• Retrying cannot charge twice.

Limits:
• Change checkout only.

✓ Task started in this thread.

Ryker APP9:43 AM

Handle slow payment responses

The request
Make checkout handle a slow payments API. Read payments-api for context; change checkout only.

Progress

✓ Workspace setup

✓ Planning

✓ Implementation · 2/2 subtasks

✓ Reuse the idempotency key on retry

✓ Cover a slow response and a lost reply

✓ Self-review and checks

✓ Draft PR #57

✓ CI · 3/3

◷ Review and merge ← 🙋 your turn

Repository
your-team/checkout

Draft PR created. Open it to review the changes. · Open draft PR #57

Updated 23 Oct, 09:56 UTC

Ryker APP9:44 AM

Should checkout retry automatically, or ask the customer to try again?

Answered

You 9:45 AM

Retry automatically. Keep the same idempotency key so we can’t charge twice.

Ryker APP9:56 AM

Opened #57 · Handle slow payment responses. The slow-response and lost-reply tests pass. Retries reuse the original idempotency key.

A useful review.
Right on the line.

Ask Ryker to look at a pull request. It reads the change and discussion, then leaves its findings where you’re already reviewing.

Reply, ask a follow-up, or push an update. The conversation stays with the pull request. Your team decides what to merge.

Working together on GitHub

your-team / payments-api

Retry payment requests #86

OpenYou want to merge into main

You PR comment

@Ryker can you review the retry path?

src/payments.tsLine 24 · Outdated

2323 return retry(() => charge({

24+ idempotencyKey: randomId(),

2525 amount

2626 }));

Ryker botReview comment

src/payments.ts · line 24

Each retry creates a new key. If the first payment succeeds but its reply times out, the retry could charge again. Create the key once and reuse it.

Ryker requested changes

You commented

Good catch. I moved the key outside the retry and added a test for the lost reply.

Ryker botreviewed

The new diff reuses the original key. The added test covers a timeout after the first charge succeeds.

Ryker turns Slack alerts into fixes.

Your monitoring, CI, and deployment tools already post to Slack. Ryker can pick up those notifications, investigate the problem, and prepare a fix without waiting for a mention.

You review and approve the change. Ryker applies it through Emisar and checks that the issue is resolved. The conversation and progress stay in Slack.

Set up alerts in Slack

inc-checkout-timeouts

Messages

Today

Monitoring APP10:12 AM

Checkout timeouts are rising.
8% of requests failed in the last five minutes.

Ryker APP10:14 AM

The connection pool is full. The errors started just after the deployment reduced its limit. I’m preparing a rollback to restore the previous limit.

You 10:15 AM

Let’s bring the responders into a room.

Ryker APP10:15 AM

Investigate checkout timeouts

Today

Ryker APP10:16 AM

Pinned by Ryker

Incident · Checkout requests timing out
Status: Investigating

The connection pool is full after its limit was reduced.

What this investigation is establishing
✓ Find when the timeouts began
✓ Verify recovery after restoring the pool limit
▸ Establish why the limit changed

Ryker APP10:18 AM

The rollback is ready for your approval in Emisar. It restores the previous pool limit. I’ll apply it once approved, then check recovery.

Teammate 10:19 AM

I’ve approved the rollback in Emisar.

Ryker APP10:19 AM

The rollback finished and restored the previous pool limit. I’ll check the request and pool metrics again in two minutes.

Ryker APP10:21 AM

Checkout is recovering. Timeouts are below 0.1% in the two minutes since the change, and the pool has room again.

You 10:22 AM

Please summarize the recovery and what we still need to investigate.

Ryker APP10:23 AM

Restoring the pool limit brought timeouts back below 0.1%. We still need to establish why the limit changed and whether it can recur.

In the conversation.
Before you ask.

Set a channel to Be proactive. Ryker can spot a missed detail, connect it to earlier work, or ask a useful question without waiting for a mention.

Keep talking as you normally would. You don’t need another mention for every follow-up.

Choose when it joins in

engineering

Messages

Today

You 11:42 AM

The retry change is ready: #86 · Retry payment requests. Hoping to ship after lunch.

Teammate 11:43 AM

Looks good to me.

Ryker APP11:44 AM

One thing before this ships: each retry creates a new idempotency key. If the first charge succeeds but its reply gets lost, the retry could charge again.

You 11:45 AM

Ah, I missed that. Can you point me to the line?

Ryker APP11:45 AM

Line 24 in src/payments.ts creates the key inside the retry. Create it once before the loop and reuse it for each attempt.

idempotencyKey: randomId(),

Teammate 11:46 AM

On it. I’ll add a lost-response test, too.

Ryker APP11:46 AM

Exactly—the payment went through, but the reply didn’t. That’s the case to cover.

A little less on your mind.

Context that carries over. Feedback that sticks. Work you don’t have to keep asking for.

Ryker sees multiple repos at once.

Choose the repos it can read. Ryker uses them together to understand how a change affects the rest of your system.

Through Emisar, it checks logs, deployments, and running systems alongside the code. It can trace a problem across services without you having to piece it all together.

Give it the right context

engineering

Thread

Today

You 9:30 AM

@Ryker why does checkout time out when payments looks healthy?

Ryker APP9:31 AM

Checkout’s client gives up after 2 seconds, but payments-api’s handler allows up to 5.

Ryker APP9:32 AM

I checked production through Emisar. The request logs show these payments completing after checkout has already timed out. Checkout stops waiting too soon.

You 9:33 AM

Is mobile affected too?

Ryker APP9:34 AM

The mobile client waits 5 seconds, matching the API. Checkout is the client with the shorter limit.

You don’t have to
explain it all again.

Ryker carries useful context from one conversation to the next: the decisions you made, the problems you solved, and what’s still waiting.

It can show where that context came from. Ask it to remember a decision or save guidance for the team. You can see what’s saved, who it applies to, and when it expires.

What it remembers

engineering

Thread

Monday

You 10:24 AM

Let’s keep the old billing API until the mobile rollout finishes. @Ryker remember that for the team for the next month.

Ryker APP10:25 AM

Old billing API
Keep the old billing API until the mobile rollout finishes; older app versions still use it.

Kind
Fact

Applies to
Whole workspace

Source
#engineering

Expires
Nov 18, 2026

Memory saved · saved by You · 19 Oct, 10:26 UTC

Thursday

You 2:08 PM

@Ryker why do we still have two billing APIs?

Ryker APP2:09 PM

In Monday’s discussion in #engineering, you decided to keep the old API until the mobile rollout finishes. Older app versions were still using it.

I’ll check the current rollout before suggesting we remove it.

You 2:10 PM

For the next three months, always check current usage before recommending we remove an API. Remember that for the team.

Ryker APP2:11 PM

Before removing an API
Check current usage before recommending removal. Include which clients still depend on it.

Applies to
Whole workspace

Source
#engineering

Expires
Jan 20, 2027

Guidance saved · saved by You · 22 Oct, 14:12 UTC

Friday

You 9:10 AM

@Ryker can we remove the old billing API yet?

Ryker APP9:11 AM

Not yet. Today’s access logs show 128 requests to the old API from app v3.8. I’d keep it while those clients still depend on it.

It learns from your feedback.

Tell Ryker what you want it to do differently. It can save your correction and use it in later work in that conversation.

You can see the saved guidance and remove it whenever you like.

How feedback becomes guidance

infrastructure

Thread

Monday

You 9:41 AM

@Ryker review this scale-up plan.

# aws_ecs_service.billing
~ desired_count = 2 -> 4

Ryker APP9:42 AM

The Terraform plan scales billing up. No resources are being replaced.

You 9:43 AM

Always show the before-and-after replica counts in these reviews.

Ryker APP9:44 AM

This plan takes billing from 2 to 4 replicas. I’ve saved your instruction for reviews here.

Replica counts in plan reviews
Always show the before-and-after replica counts in these reviews.

Applies to
This conversation

Expires
Until removed

Source
#infrastructure

Guidance saved · saved by You · 19 Oct, 09:44 UTC

Tuesday

You 9:41 AM

@Ryker review today’s plan.

# aws_ecs_service.billing
~ desired_count = 4 -> 6

Ryker APP9:42 AM

Billing: 4 → 6 replicas (+2). Today’s plan adds two tasks; it doesn’t replace the service.

Check back on schedule.

“Check this tomorrow.” “Look at production every weekday.” Give Ryker a time and a place to bring the answer.

You confirm the schedule and timezone. It does the check when it’s due and returns to the conversation with what it found.

Set up a schedule

releases

Thread

Monday

You 4:30 PM

@Ryker check production every weekday at 9, Berlin time. Post the result here.

Ryker APP4:31 PM

I’ll check the deployment and recent errors each weekday.

Check production
Check deployment status and error logs.

When
Every weekday at 09:00 Berlin time

Channel
#releases

Next run
Tuesday at 9:00 AM

Expires
No expiry

Access
Read-only

Schedule saved · saved by You · Monday at 4:31 PM

Tuesday

Ryker APP9:01 AM

All six instances are on the latest revision, and the application logs show no new errors in the last hour.

Tell it what to
keep an eye on.

Some work comes up again and again. Ask Ryker to review new plans, look into alerts, or follow deployment updates.

You confirm what it should watch and what it should do. When a matching event arrives, Ryker starts the work.

Give it a standing request

infrastructure

Thread

Monday

You 11:00 AM

@Ryker when a Terraform plan is posted here, review it for risky changes.

Ryker APP11:01 AM

I’ll watch messages here and review posted Terraform plans.

Review new Terraform plans
Review posted plans for risky changes and reply in the plan’s thread.

Channel
#infrastructure

Source
slack

Event filter
All slack events posted here

Expires
Until disabled

Access
Read-only

Standing rule saved · saved by You · Monday at 11:02 AM

Monday

CI APP2:16 PM

Terraform plan ready for review.

# aws_db_instance.primary must be replaced
-/+ resource "aws_db_instance" "primary" {
  storage_encrypted = false -> true # forces replacement
}

Plan: 1 to add, 0 to change, 1 to destroy.

Ryker APP2:17 PM

This plan replaces the primary database. The encryption change forces replacement. Check the migration and restore plan before applying.

Transparent by design.

Explore the console

See the context, tools, and checks behind each answer. Change the models, instructions, and memory that shape the next one.

Ryker’s request timeline with the recorded model, instructions, messages, saved knowledge, and tools used to investigate a checkout timeout. — Follow the work, step by step.
See the exact briefing, the tools Ryker used, and the checks on its answer. The timeline also records the model, reasoning effort, timing, token usage, and recorded cost.
Read a request’s timeline

Ryker’s Usage & cost page showing recorded spending, token use, cache hit rate, daily usage, and time spent in each stage. — See what the work costs.
Track model spending and token use over time. Break it down by model, channel, repository, or person, then open the requests behind the totals.
Understand usage and cost

Ryker’s Feedback page with daily positive and negative feedback, categories, requests to review, and a correction linked to its original conversation. — Learn from your team’s feedback.
See reactions, repeat questions, and corrections together. Open the original request to understand what went wrong and improve the instructions or setup behind it.
Work through feedback

Ryker’s Schedules page with a morning health check, weekly dependency review, and paused rollout check, including their cadence, channels, repositories, and next runs. — Keep recurring work in one place.
See what runs next, how often, and where the results go. Open a schedule to read its run history, run it now, or pause it when the job is no longer needed.
Set up scheduled work

Ryker’s model settings with separate model, reasoning effort, account, and fallback controls for routing, conversation, and deeper work. — Choose the model for the job.
Use different models for routing, conversation, and deeper work. Set the reasoning effort and account for each, with a fallback when the first choice is unavailable.
Configure Ryker

Ryker’s actual instructions editor with team-wide coding guidance and additional instructions for an engineering channel. — Tell it how your team works.
Write instructions for every conversation, then add guidance for individual channels. Ryker uses your changes from its next step.
Set your team’s instructions

Ryker’s saved Payment retries topic, showing whether it is in use, the source message, linked request, update history, and Forget topic control. — See what it learned, and where.
Open a saved topic to read its sources and update history. See whether Ryker is using it, follow it back to the conversation, or choose to forget it.
Explore how memory works

Fits the way you work.

Say it. Or send it.

Voice notes, screenshots, logs, and files can be part of the conversation. Recordings are transcribed into words.

What you can send

Sometimes a chart helps.

With a suitable tool connected, Ryker can return a chart or image in the thread, alongside the sources behind its answer.

Pictures with context

A week’s work, caught up.

Turn on a weekly update for PRs, work waiting on people, what it learned, and reported or estimated model cost.

Get the weekly update

There’s a chat here, too.

Talk to the same teammate in your browser. Pick an environment, attach a file, and see the work behind each reply.

Meet it in the browser

A place for every kind of work.

Choose each channel’s repositories, infrastructure access, and when Ryker joins in. It can also watch quietly, building knowledge without interrupting your team’s work.

Choose how it takes part

Your tools can start the conversation.

Configured webhooks bring alerts and deployment events into Ryker’s work, with the environment and destination you choose.

Connect an event source

Run Ryker on
your own infrastructure.

Its memory and work history live in a database you run. You decide who has access, when to upgrade, and how long records are kept.

Connect Slack, GitHub, and your model account, then start with one channel.

Install Ryker Talk to the builder

Install with Docker Compose

git clone https://github.com/AndrewDryga/ryker ryker
cd ryker && ./install.sh

The installer starts Ryker and prints a sign-in link for setup.

An extra pair of hands.Right in your team.

Reload registry credentials when they change #42

From “what broke?”to “here’s why.”

A fix you can review.And work that follows through.

A DevOps teammate.With the right tools.

Ryker

co:op

Emisar

What’s on your plate?

Ryker writes the code and sees it through.

A useful review.Right on the line.

Retry payment requests #86

Ryker turns Slack alerts into fixes.

In the conversation.Before you ask.

A little less on your mind.

Ryker sees multiple repos at once.

You don’t have toexplain it all again.

It learns from your feedback.

Check back on schedule.

Tell it what tokeep an eye on.

Transparent by design.

Follow the work, step by step.

See what the work costs.

Learn from your team’s feedback.

Keep recurring work in one place.

Choose the model for the job.

Tell it how your team works.

See what it learned, and where.

Fits the way you work.

Say it. Or send it.

Sometimes a chart helps.

A week’s work, caught up.

There’s a chat here, too.

A place for every kind of work.

Your tools can start the conversation.

Run Ryker onyour own infrastructure.

From “what broke?”
to “here’s why.”

A fix you can review.
And work that follows through.

A DevOps teammate.
With the right tools.

A useful review.
Right on the line.

In the conversation.
Before you ask.

You don’t have to
explain it all again.

Tell it what to
keep an eye on.

Run Ryker on
your own infrastructure.