Daytona, without opening Daytona.
Which sandboxes and snapshots exist, and what they are costing.
- Free to start
- No card
- Reads only, nothing to approve
- Your own account, not a shared login
Ask in your own words.
Nothing to configure and no builder to open. Copy one of these into a thread, swap in your own Daytona details, and Ray takes it from there.
@Ray how many sandboxes are running, and what are we spending?
@Ray which sandboxes have been running longest?
@Ray why did that snapshot build fail?
@Ray what regions can we run in?
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.
13 reads wired, and nothing that writes.
Runs on its own
What Ray reads in Daytona
- Sandboxes, snapshots, and volumes
- Organization usage and available regions
- Sandbox health and build logs
Reading changes nothing, so Ray never stops to ask whether it may look something up.
No send, no spend
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.
- Create, archive, or delete a sandbox
- Run a command inside a sandbox
- Delete files or a git branch
- Touch API keys and organization roles
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.
Ray uses Daytona together with the rest of your tools.
One ask can read Daytona, cross-reference what is in these, and land the finished result back in the thread. Not four connectors taking turns, one teammate with one memory.
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.
Daytona and Ray, answered
The questions teams ask before they connect Daytona. Every answer is how this integration is built rather than a promise about it.
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.