Daytona, without opening Daytona.
Read-only dev sandboxes: which environments, snapshots and volumes exist and what they are costing.
In your channel
Ask Ray for something in Daytona and it posts this card in the thread. One click, and the task you asked for carries on where it left off.
What Ray can and cannot do in Daytona
Reading is free, because reading changes nothing. Everything that writes waits for you. The rest is not on Ray’s list.
Runs on its own
What Ray reads in Daytona
- Get entrypoint logs
- Get health
- Get organization
- Get organization usage overview
- Get snapshot
- Get snapshot build logs
- Get user
- Get volume
- List available regions
- List organizations
- List sandboxes
- List snapshots
- List volumes
Reading changes nothing, so Ray never stops to ask whether it may look something up.
Asks first, every time
What Ray answers with
Ray reads Daytona and answers from it in the thread. Writing to Daytona is not switched on yet, so there is nothing here to approve.
Not on the list
Things Ray is never handed
These are left out during curation, so they are not something Ray could do and decides against. They are not in front of it at all.
- Delete api key
- Archive sandbox
- Execute command
- Delete api key user
- Cancel organization invitation
How Ray works with Daytona
No workflow to build, and nothing to maintain when the work changes.
- 01
Connect Daytona
One click, right where you asked. Ray posts a connect card, you authorise Daytona with your own account, and the work you asked for picks up where it left off.
- 02
Ask in plain words
In the conversation you were already having. Nothing to build, no trigger to map, no tab to open.
- 03
Ray answers where you asked
Ray only reads Daytona, so there is nothing here to approve. It looks up what it needs and replies in the thread.
Priya
@Ray the checkout bug is back. Take a look in Daytona, and tell Dana it is being looked at.
Ray
Checked Daytona. The spec was last edited on Tuesday and the open question about refunds is still unanswered.
What does connecting Daytona to Ray actually do?
Ray is an AI teammate that works in your team chat, on Slack today. Connect Daytona and it can do the Daytona part of a request without anyone leaving the conversation: read what it needs, draft the change, and post it for approval before anything is written.
It is not a workflow builder. There is no trigger to configure and no automation to repair when your process shifts. You describe the outcome in the thread and Ray picks the actions, including actions in your other connected tools when the request spans more than one.
Every person on the team connects their own Daytona account, so Ray can only reach what that person can already reach, and the history in Daytona shows who actually asked.
Security and permissions
- You authorise Daytona on its own login screen. Your password never passes through Ray.
- Writes are gated in the execution path, not by a prompt. There is no setting that grants blanket approval.
- Each workspace is isolated at the database level, and that isolation is tested by trying to break it.
- Disconnect Daytona in a message, or uninstall Ray and every connection it held is revoked.
More dev & deploys integrations
Ray uses them together in a single run when a request spans more than one.
Put Ray to work in Daytona.
Free to start, no credit card, and it asks before it acts.