Download the PHP package elliottlawson/daytona-php-sdk without Composer

Daytona PHP SDK

A PHP SDK for interacting with the Daytona API to manage development sandboxes.

Requirements

• PHP 8.2 or higher
• Laravel 10.x, 11.x, 12.x, or 13.x (optional, for Laravel integration)

Installation

Configuration

Laravel Applications

1. The service provider will be automatically registered via Laravel's package discovery.

2. Publish the configuration file:

3. Add your Daytona credentials to your .env file:

Configuration Options

The SDK requires three configuration values:

• apiUrl (string): The Daytona API endpoint (defaults to https://api.daytona.io)
• apiKey (string, required): Your Daytona API authentication key
• organizationId (string, required): Your organization ID

Type-Safe Configuration

For better type safety and IDE support, you can use the Config class:

Non-Laravel Applications

You can instantiate the client directly with configuration:

Usage

Using the Facade (Laravel)

The easiest way to use Daytona in Laravel is through the facade:

Creating a Client

In Laravel (Recommended)

Manual Configuration

Managing Sandboxes

Create a Sandbox

Get Sandbox Information

List and Filter Sandboxes

For large result sets, listSandboxesPaginated() returns one page at a time using Daytona's cursor pagination:

listSandboxesPaginated() returns a PaginatedSandboxesResponse:

• $response->items — Sandbox[] in the current page
• $response->nextCursor — cursor for the next page, or null when exhausted
• $response->hasMore() — whether another page is available
• $response->count() / $response->isEmpty() — page size helpers

SandboxFilter supports both the modern query params (states, isPublic, name, cursor, limit) and the legacy ones (state, user, public) for older Daytona versions. Filters can be built with named constructors (byLabels(), byId(), byName(), byState(), byStates(), byUser(), byPublic()) or chained with the with*() methods (e.g. withCursor(), withLimit(), withStates()).

Start/Stop Sandbox

Working with Files

Using the Sandbox Object (Recommended)

Executing Commands

Session Management for Long-Running Commands

The SDK provides session support for managing long-running processes like development servers, build watchers, and background tasks.

For more details on session management, see Session Management Documentation.

Git Operations

Using the Sandbox Object (Recommended)

Using the Client Directly

Complete Example

Using the Facade

Using Dependency Injection

Advanced Usage

Working with Sandbox Data

State Management

Preview URLs

Access services running in your sandbox through preview URLs:

Preview URLs allow external access to services running in your sandbox:

• Public sandboxes: URLs are publicly accessible
• Private sandboxes: Require authentication token in x-daytona-preview-token header
• URL format: https://{port}-{sandboxId}.{runner-domain}

Error Handling

The SDK provides specific exception types for different error scenarios:

Exception Types:

• ConfigurationException - Missing API keys, invalid configuration
• SandboxException - Sandbox creation, state transitions, lifecycle errors
• FileSystemException - File read/write/delete operations
• CommandExecutionException - Command execution failures
• GitException - Git operations (clone, commit, push, etc.)
• ApiException - HTTP API errors with status codes and responses

All exceptions extend the base ElliottLawson\Daytona\Exception class.

Using the Sandbox Object

For a more object-oriented approach, you can work with the Sandbox object:

Testing

Test Configuration

The test suite is split into two groups:

• Feature tests: Unit tests that don't require external services
• Integration tests: Tests that require a running Daytona server

By default, composer test or vendor/bin/pest only runs feature tests. This allows for quick testing during development without needing a Daytona server.

Error Handling

All SDK methods throw Exception on errors:

License

MIT