Daytona compatibility

Already have code written for Daytona's SDK? Change one import and it runs on Solari sandboxes: create, stop and start, run commands and sessions, read and write files, use git, snapshot and fork.

Install

npm install @solarisdk/daytona-compat     # TypeScript
pip install solari-daytona-compat          # Python (import solari_daytona)

Change the import

// before: import { Daytona } from "@daytona/sdk"
import { Daytona } from "@solarisdk/daytona-compat"

const daytona = new Daytona({ apiKey: process.env.SOLARI_API_KEY })
const sandbox = await daytona.create({ labels: { project: "demo" } })
const result = await sandbox.process.executeCommand("echo hello")
console.log(result.result, result.exitCode)
await sandbox.delete()

# before: from daytona import Daytona, DaytonaConfig
import os
from solari_daytona import Daytona, DaytonaConfig

daytona = Daytona(DaytonaConfig(api_key=os.environ["SOLARI_API_KEY"]))
sandbox = daytona.create()
print(sandbox.process.exec("echo hello").result)
sandbox.delete()

The key is read from the apiKey / api_key option, then SOLARI_API_KEY. The API URL defaults to https://api.getsolari.com.

What works

• Sandboxes: create (with labels, a name, environment variables, resources and auto-stop), get by id or name, list by label, start, stop, delete, fork.
• Commands: run a shell command with a working directory, environment and timeout; run code; sessions where cd and export carry from one command to the next, with background commands, streaming logs and input.
• Files: upload and download, list, details, search, replace, move, permissions.
• Git: clone, commit, branches, push, pull, status and more, run with the git in the sandbox. Credentials are never put on a command line, in a URL or in an error message.
• Snapshots and images: snapshot a sandbox and create from the snapshot by name; build a named snapshot from an Image (base, debianSlim, pipInstall, runCommands, env, workdir, addLocalFile, …) or a Dockerfile.
• Preview links for a port in the sandbox.

What is different

• Stop is a pause. A stopped sandbox keeps its memory, running processes and disk, and start resumes it where it was. That is more than Daytona's stop keeps.
• Fork and snapshots take a while (about 25 to 40 seconds) and keep memory as well as disk. Snapshots are large and are billed as snapshot storage; deleting a fork deletes its snapshot.
• Auto-stop and TTL use Solari's idle window, which restarts whenever the sandbox is used. A TTL is not a hard deadline. An auto-stop of 0 (never) is not available.
• Preview links carry a signed token in the URL: treat the URL as a secret. Expiring one revokes every token of the sandbox.
• Sessions keep the working directory and environment between commands, but a session is not one long-running shell: a background process started by a command is not part of the session.
• Resources above 8 vCPU or 16 GiB are reduced to those limits, with a warning.
• Local files you add to an Image travel inside the build and are visible in the build log: do not put secrets in them.

What is not supported

These raise SolariCompatUnsupported, a subclass of DaytonaError that names the feature, so nothing is silently ignored:

• PTY (terminal) sessions, the code interpreter (contexts, charts), computer use
• LSP servers and SSH access
• Network allow-lists and block-all, outbound proxy
• Volumes, secrets service, warm pools
• GPU, spot, regions, organisation and JWT sign-in
• Archive, recover and resize; auto-archive and auto-delete intervals

The full list, call by call, is the COMPAT.md file in each package.