Daytona Can Now Operate Your Servers Without Seeing The Keys

July 16, 2026

Save a server's SSH key once in the Vault and Alfrada OS can use the existing Code Execution capability to work on it — pull logs, check disk and service health, edit config, or run a deploy. The operation runs from a dedicated ephemeral Daytona sandbox, not Alfrada's API server. You never paste the key into chat, and model-generated Python never receives it.

What you can do

• Connect a server without pasting secrets in chat. When a task needs a server Alfrada OS hasn't got, a secure popup asks for host, port, username, and private key. Optional bastion/jump-host fields cover private-network servers. Everything is stored in the encrypted Vault.
• Use one Daytona execution surface. The existing Code Execution capability now has a server target. Alfrada OS supplies the remote command and an opaque Vault label; the backend resolves the key and injects it only into a fixed Daytona runner process.
• Keep credentials out of generated code. The key and passphrase are process-scoped environment values. They are not placed in model-generated Python, the remote shell command, tool output, or a sandbox file.
• Self-cleaning isolation. Server work uses a dedicated ephemeral sandbox which auto-stops after its idle window and deletes immediately when stopped. It is separate from the persistent Python analysis sandbox.
• Daytona security posture. Daytona has achieved SOC 2 Type I (Type II is in progress), and Alfrada OS explicitly targets Daytona's Europe (eu) region for these sandbox workloads. Daytona's ephemeral mode reclaims compute, memory, and local storage and revokes session-scoped credentials when the sandbox stops.
• Read freely, change carefully. Read-only commands (listing files, reading logs, checking status) run immediately. Anything that could change state — installs, restarts, edits, deletes, deploys — pauses for your approval, exactly like the other sensitive actions in the Safety Center.
• Know which servers exist. Once you've saved one or more servers, Alfrada OS is told how many it can reach and their labels (never the keys), so it can offer to use the right one instead of asking you to re-explain your infrastructure.
• Multiple servers, one per teammate or environment. Save prod-exoscale, staging, db-box — Alfrada OS asks which one to target when it's ambiguous, and uses the only one automatically when there's just one.
• Let longer operations breathe. Alfrada OS can set the sandbox idle window from 5 minutes to 24 hours per call. For a background deploy or build, it launches safely, schedules wake_me, and checks the result later in the same conversation.
• A runtime playbook teaches the full workflow. Before server/devops work, Alfrada OS can read Daytona Server Operations & DevOps for credential capture, bounded diagnostics, write approvals, direct/bastion routing, lifetime choices, wake-up follow-through, verification, and failure handling.

Where this shows up

• You ask "is my server running low on disk?" — Alfrada OS connects to your saved server, runs df -h, and reports back. No approval needed, because it only read.
• You ask "restart nginx on prod" — Alfrada OS recognises this changes state, so it pauses and asks you to approve before running systemctl restart nginx.
• You just signed up for a new VPS and say "pull yesterday's error logs from it." Alfrada OS doesn't have it yet, so the secure popup appears; you paste the key once, and every future session can reach that box.
• You ask for a long container build — Alfrada OS starts it in the isolated server workflow, keeps Daytona available for the follow-up window, and wakes later to inspect progress.

Try it

• "Save my Exoscale server so you can SSH into it."
• "Check disk usage and the last 50 lines of the nginx error log on prod."
• "On my staging server, show me which Docker containers are running and their status."
• "Deploy the latest main branch on prod-exoscale, keep the sandbox for 45 minutes, and wake in 10 minutes to check the rollout." (Alfrada OS pauses before anything that writes.)

Test it safely

1. Store your existing SSH connection: ask "Save my test server for Daytona access." In the secure popup, use the host, port, and username from your working SSH setup, then paste the matching private key (and passphrase if it has one). Never paste the key into chat.
2. Prove read-only access first: ask "On my test server, run hostname, whoami, date, uptime, df -h and free -h. Do not change anything." This should run without a write approval and return a Daytona sandbox ID.
3. Prove the write gate: ask "On my test server, create /tmp/alfrada-daytona-test, show its stat, then stop." The file creation should pause for SSH command execution approval. After approving, verify it exists; remove it in a separate approved call.
4. Prove ephemeral cleanup: set a 5-minute idle window, note the returned sandbox ID, and check the Daytona dashboard after more than 5 idle minutes. It should stop and be deleted. Run another read-only check afterwards; Alfrada OS should reconnect through a newly created ephemeral sandbox.
5. Prove wake-up follow-through: ask "On my test server, run a harmless background job that waits 60 seconds and writes the current date to /tmp/alfrada-wake-test; keep Daytona for 10 minutes, wake in 5 minutes, and verify the file." The launch should require approval, wake_me should resume the conversation, and the follow-up should read the result.

Heads up

• The key never enters chat, generated Python, or the remote command. It is decrypted by the backend and injected only into the environment of Daytona's fixed server runner.
• Ephemeral does not mean logless. The deleted sandbox leaves no persistent runtime filesystem or memory, but command output is returned to Alfrada OS and Daytona keeps administrative/sandbox lifecycle audit logs for security and compliance. We do not claim zero logging.
• Read vs. write is a safety line, not a guess. Commands Alfrada OS can't confidently classify as read-only are treated as writes and gated. You can flip SSH command execution to auto-approve in Settings → Safety Center if you want unattended devops (recommended only for servers you fully trust the workflow on).
• Add, edit, and revoke servers anytime in Settings → Account → Vault, alongside your web logins and API keys.
• The ephemeral sandbox is a transport boundary, not long-term storage. Remote background jobs continue on your server; Daytona can reconnect on the next call even if its prior sandbox has already self-deleted.
• Host-key verification is not enforced yet. Hardened host-key pinning remains a follow-up.

Official references: Daytona Security Exhibit · Regions · Ephemeral sandboxes · Audit Logs