Go & Ruby SDKs
Relevant source files
The following files were used as context for generating this wiki page:
The Daytona Go and Ruby SDKs provide programmatic interfaces for developers to interact with Daytona's secure, isolated sandbox infrastructure. These SDKs allow for the automated creation, management, and orchestration of sandboxes, enabling features such as remote code execution, file system manipulation, and Git operations within an elastic environment.
Both SDKs serve as wrappers around the Daytona API, abstracting the complexity of HTTP requests into idiomatic language constructs. While the Go SDK leverages strong typing and concurrency primitives like channels for build logs, the Ruby SDK provides a dynamic interface compatible with Ruby versions 3.2.0 and higher.
Sources: README.md:120-142, libs/sdk-go/README.md:1-10, libs/sdk-ruby/README.md:1-5
Architecture and Core Components
The SDKs are structured into logical services that correspond to different functional areas of a Daytona Sandbox. The central entry point for both is a Client or Daytona object that manages authentication and high-level sandbox lifecycle.
Service Modules
Both SDKs implement a modular architecture where specific operations are delegated to specialized services:
| Service | Responsibility |
|---|---|
| Sandbox Service | Core lifecycle: Create, Start, Stop, Delete, List. |
| FileSystem Service | Operations on files: Upload, Download, List, Search. |
| Git Service | Repository management: Clone, Branching, Status. |
| Process Service | Code execution and shell command processing. |
| Snapshot Service | Managing persistence through sandbox state snapshots. |
| Volume Service | Managing persistent storage volumes. |
Sources: libs/sdk-go/README.md:143-200, libs/sdk-ruby/scripts/generate-docs.rb:12-26
Component Relationship
The following diagram illustrates how the SDK components interact with the Daytona API and the target Sandbox environment.
The SDK Client initializes using configuration (API keys/URLs) and returns a Sandbox object which provides access to sub-services for deep interaction.
Sources: libs/sdk-go/README.md:15-60, libs/sdk-ruby/README.md:20-40
Configuration and Authentication
SDKs can be configured through environment variables or explicit configuration objects. The primary requirement is a Daytona API Key, which is generated via the Daytona Dashboard.
Configuration Parameters
| Parameter | Env Variable | Description | Default |
|---|---|---|---|
| API Key | DAYTONA_API_KEY | Key for authenticating requests. | N/A |
| API URL | DAYTONA_API_URL | Endpoint for the Daytona API. | https://app.daytona.io/api |
| Target | DAYTONA_TARGET | Region for sandbox deployment (e.g., us, eu). | N/A |
Sources: libs/sdk-go/README.md:73-85, libs/sdk-ruby/README.md:42-49
Go Client Initialization
In Go, the client is created using NewClient() (defaults) or NewClientWithConfig().
Sources: libs/sdk-go/README.md:78-95
Ruby Client Initialization
In Ruby, the Daytona::Daytona class is instantiated, optionally taking a Daytona::Config object.
Sources: libs/sdk-ruby/README.md:20-33
Sandbox Lifecycle Management
The lifecycle of a sandbox follows a standard flow: Creation, Execution, and Deletion.
Sandbox Creation Flow
The creation process involves defining parameters such as language, environment variables, or custom images. The Go SDK specifically supports real-time log streaming during the build process via Go channels.
Key Methods
- Create: Initializes a new sandbox. Returns metadata and, in Go, a build log channel.
- Start/Stop: Manages the operational state of the sandbox. Both SDKs support timeout configurations for these operations.
- Delete: Removes the sandbox. It is considered a best practice to use
defer(Go) or ensure blocks (Ruby) for cleanup. - List: Retrieves a paginated list of available sandboxes, filterable by labels.
Sources: libs/sdk-go/README.md:118-135, libs/sdk-go/README.md:175-195
Build and Documentation Tooling
Both SDKs utilize the Nx build system for task orchestration, including building, testing, and documentation generation.
Nx Targets
The project.json files define standard targets for both libraries:
- build: Compiles the Go code or builds the Ruby
.gemfile. - test: Runs the test suite (
go testfor Go;rake specfor Ruby). - docs: Generates Markdown documentation for the API reference.
- lint: Executes static analysis tools (
golangci-lintfor Go;rubocopfor Ruby).
Sources: libs/sdk-go/project.json:7-75, libs/sdk-ruby/project.json:7-60
Documentation Generation
Documentation is automated to maintain parity with the source code:
- Go: Uses
gomarkdocwith custom templates to generate.mdxfiles for the technical documentation site. - Ruby: Employs a custom Ruby script (
generate-docs.rb) that uses theYARDregistry to parse class metadata and format it into MDX, including attributes, examples, and method signatures.
Sources: libs/sdk-go/project.json:76-92, libs/sdk-ruby/scripts/generate-docs.rb:1-50
Summary
The Go and Ruby SDKs provide a standardized way to manage Daytona's infrastructure. While they share a common service-based architecture and configuration model, they are tailored to their respective ecosystems—Go focuses on concurrency and performance, while Ruby emphasizes developer ergonomics and ease of integration. Through Nx-managed build pipelines and automated documentation, the SDKs ensure a consistent and reliable experience for developers automating sandbox workflows.
Sources: libs/sdk-go/README.md:200-210, libs/sdk-ruby/README.md:110-120