Ryker / Docs / Repositories and tools
Repositories and tools
An environment is the set of repositories and tools Ryker can use in a conversation. Give it enough context to understand the system, then choose where it may make changes.
On this page
Group related repositories
A service rarely lives in one repository. Its API, web client, deployment configuration, and shared libraries may all be separate. Ryker can read them together to understand how a change in one affects the others.
Under Work › Environments, create an environment and add the repositories it needs. Choose a default repository, which must have read/write access. Other repositories can be read-only or read/write. A code task changes the default unless it selects another writable repository, and reads the others as context. Name the target in your request when there is more than one.
For example, an environment for a checkout service could give Ryker read/write access to the API and read-only access to the storefront and deployment configuration. It can check the callers and deployment settings while preparing an API fix.
Add a repository
- Install the GitHub App on the repository.
- Import it under Work › Repositories. Ryker reads the code and keeps reference notes there. Importing does not change files or open a pull request.
- Add it to an environment and choose its access level.
The App installation limits which repositories Ryker can access at all. The environment narrows that list for each conversation. Importing a repository alone does not make it available everywhere.
Choose an environment for a conversation
Slack channels, webhook sources, and browser Chat conversations each use one environment. For Slack, choose it under Work › Channels or through the channel’s Customize flow. A newly joined channel uses the default environment if you already chose one.
Choose No environment for a Slack channel where Ryker should talk without repository or Emisar access. In Chat, choose the environment for that conversation. A task or incident keeps the environment of the conversation that started it.
Add access to running systems
Code explains what a service should do. Logs, metrics, and deployment status show what it is doing now. Connect Emisar when Ryker needs both views.
In Emisar, create an MCP key for a person or service account with access to the required runners. Add the key under Integrations › Emisar in Ryker, then choose that account in the environment. The first connected account is assigned to environments that have none; assign later accounts on the Environments page.
The account’s runner access, Emisar’s action policy, and the runner’s host permissions determine what Ryker can do. For read-only investigations, allow the required read actions and restrict host permissions. For fixes, allow the needed actions and choose which require approval. An MCP key has no separate read-only switch. See Emisar’s security model for how these limits work together.
Without Emisar, Ryker can still read code and prepare changes. It can explain an infrastructure change, but cannot carry it out on your systems. Once connected, follow an alert through investigation, approval, and recovery.
What a conversation can change
Ryker sets the repositories, tools, and execution limits before work starts; co:op enforces the sandbox limits. A message or remembered instruction cannot give the task more access.
Read/write repository access lets a confirmed task edit its working copy. Opening a draft pull request is a separate setting. Infrastructure actions follow Emisar’s approval policy.