feat: add Application resource support and fork command

[devin-ai-integration]

Fixes ENG-2931

Summary

Adds Application as a deployable resource type and introduces a bl fork command for forking sandboxes.

SDK update: go.mod uses a replace directive to point github.com/blaxel-ai/sdk-go → github.com/blaxel-ai/sdk-go-staging (commit 97c3065). This staging SDK introduces breaking changes to List/Get signatures (paginated response envelopes, required *Params structs). All call sites and tests are updated accordingly.

Application support (deploy flow):

• PromptForDeploymentType() now offers "Application"
• GenerateDeployment() builds an Application spec with enabled: true and a single revision containing the image + 2048MB memory
• getResource() / getResourceStatus() fetch applications via raw client.Get("applications/<name>") since the staging SDK doesn't yet expose typed Application services

bl fork command (cli/fork.go):

bl fork <source-sandbox> <target-name> [--type sandbox|application] [--traffic N] [--port N] [--memory N]

POSTs to sandboxes/<source>/fork. For --type application, wraps revision params in a spec.revisions[] envelope; for sandboxes, passes them flat.

SDK compat fixes: WorkspaceClient interface, all *.List(ctx) → *.List(ctx, *ListParams{}), *result → result.Data iteration, mock server responses wrapped in {"data": [...]}.

Link to Devin session: https://app.devin.ai/sessions/ebad1673c91847e39d5a2a52e0609acd
Requested by: @drappier-charles

---

Note

Adds Application as a deployable resource type with CRUD operations, revisions-based spec, and a bl fork command. Updates all SDK call sites for breaking paginated response changes from a staging SDK dependency.

^{Written by Mendral for commit 6f4dd33.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[mendral-app]

🔀 Component Interaction Diagram

Here's a sequence diagram showing the key interactions introduced/modified by this PR:

sequenceDiagram
    participant User
    participant CLI as CLI (commands)
    participant Config as core/config
    participant Deploy as cli/deploy
    participant Fork as cli/fork (NEW)
    participant SDK as sdk-go-staging
    participant API as Blaxel API

    %% Deploy Application Flow
    rect rgb(230, 245, 255)
    Note over User, API: New Application Deploy Flow
    User->>CLI: bl deploy
    CLI->>Config: PromptForDeploymentType()
    Config-->>CLI: "application" (new option)
    CLI->>Deploy: GenerateDeployment("application")
    Deploy->>Deploy: Build Application spec (revisions, image, memory, region)
    Deploy->>SDK: client.Apply(applicationManifest)
    SDK->>API: POST /applications
    API-->>SDK: Created
    Deploy->>SDK: client.Get("applications/{name}")
    SDK->>API: GET /applications/{name}
    API-->>SDK: status response (map)
    SDK-->>Deploy: Application status
    Deploy-->>User: Deployment ready
    end

    %% Fork Command Flow
    rect rgb(255, 245, 230)
    Note over User, API: New Fork Command Flow
    User->>CLI: bl fork <source> <target> [--type application]
    CLI->>Fork: ForkCmd()
    Fork->>Fork: Build forkRequest (name, type, spec w/ revisions)
    Fork->>SDK: client.Post("sandboxes/{source}/fork", payload)
    SDK->>API: POST /sandboxes/{source}/fork
    API-->>SDK: Fork result
    SDK-->>Fork: Success
    Fork-->>User: Forked successfully
    end

    %% SDK List Pattern Change (affects all resources)
    rect rgb(245, 255, 230)
    Note over CLI, API: Updated SDK List Pattern (all resources)
    CLI->>SDK: client.Resources.List(ctx, *ListParams{})
    SDK->>API: GET /resources (with query params)
    API-->>SDK: {data: [...]} (paginated envelope)
    SDK-->>CLI: response.Data []Resource
    end

Loading

Summary of Interactions

Flow	Description
Application Deploy	New deployment type routed through GenerateDeployment() → builds revision-based spec → deploys via API → polls status using raw client calls
Fork Command	New bl fork command → POSTs to /sandboxes/{source}/fork → creates either a sandbox or application target with optional traffic/port/memory config
SDK Migration	All .List() calls now pass explicit *ListParams{} and read from .Data field (paginated response envelope); .Get() calls require *GetParams{} structs

Notable design choices:

• Applications use a revisions architecture enabling canary deployments with traffic splitting
• Fork can target either sandbox or application types, bridging the two resource models
• Application status retrieval uses raw HTTP (client.Get with generic map) — typed SDK support appears incomplete
• 18+ call sites updated for the new paginated list response pattern (*array → .Data)

Note

Posted by PR Sequence Diagram · Tag @mendral-app with feedback.

[mendral-app]

Observability Review: ✅ Pass

This PR does not require additional observability instrumentation.

Rationale: This repository (blaxel-ai/toolkit) is a CLI tool with no existing telemetry framework (no PostHog, OpenTelemetry, or structured logging). The observability conventions (analytics events, distributed tracing, operational metrics) apply to backend/controlplane services, not CLI clients.

Changes reviewed:

• SDK API signature adaptations (mechanical — adding *Params{} structs, using .Data field)
• New bl fork command (cli/fork.go) — CLI-only, delegates to server API
• Application deployment type in deploy.go — extends existing CLI deploy flow

All server-side observability (tracing fork operations, tracking application deployments) should be implemented in the controlplane service that handles these API requests, not in the CLI client.

Note

Posted by Observability Coverage Checker · Tag @mendral-app with feedback.

[mendral-app]

✅ Linked to Linear issue ENG-2931 — status set to In Progress

This PR directly implements the scope defined in ENG-2931 (Application Runtime — CLI: deploy, fork, snapshot, preview), assigned to @drappier-charles.

• PR linked: ✅ Issue will auto-close when this PR merges

Note

Posted by Linear Issue Enforcer · Tag @mendral-app with feedback.

[mendral-app]

🧪 Testing Guide

What this PR addresses

This PR adds Application as a new deployable resource type in the Blaxel CLI and introduces a new bl fork command for forking sandboxes into new sandboxes or applications. It also updates the SDK dependency to a staging version that introduces breaking changes (paginated response envelopes, required *Params structs), with all call sites and tests updated accordingly.

Steps to reproduce / exercise new behavior

A. Application deployment flow:

1. Create a project directory with a blaxel.toml (or start fresh with bl deploy)
2. Run bl deploy interactively and verify "Application" appears in the deployment type prompt
3. Select "Application" and confirm the generated resource spec includes runtime and (optionally) region
4. Verify the deployment proceeds through build, upload, and status monitoring stages
5. Confirm bl get applications (or bl get apps) lists the deployed application with workspace, name, status, and created_at columns

B. bl fork command:

1. Ensure you have an existing sandbox (e.g., my-sandbox)
2. Fork to a new sandbox: bl fork my-sandbox my-fork
3. Fork to an application with options: bl fork my-sandbox my-app --type application --traffic 20 --port 8080 --memory 4096
4. Test invalid input: bl fork "my/../sandbox" target — should fail with "invalid sandbox name"
5. Run bl fork --help and verify usage/examples are shown

C. SDK migration (List/Get signature changes):

1. Run go build ./... — should compile without errors
2. Run go test ./... — all tests should pass with the updated mock server responses (JSON wrapped in {"data": [...]} envelopes)

D. Resource type flag:

1. Run bl deploy --help and confirm --type flag documentation mentions application alongside other types

What to verify (expected behavior)

• bl deploy interactive prompt shows "Application" as an option
• Deploying an application generates the correct spec (runtime, optional region) and monitors status until ready
• bl get applications / bl get apps lists applications correctly (paginated response handled)
• bl fork <source> <target> posts to sandboxes/<source>/fork with the correct JSON body
• bl fork --type application wraps params in spec.revisions[] envelope; --type sandbox passes params flat
• bl fork rejects source names containing / or ..
• All existing tests pass (go test ./...) — mock servers return {"data": [...]} format
• bl apply recognizes "Application" resources (alongside "Sandbox")
• Autocompletion for resource names still works (List calls updated to new signatures)
• bl connect and bl drive commands still work correctly with updated SDK iteration patterns

Note

Posted by PR Testing Guide · Tag @mendral-app with feedback.

[mendral-app]

Needs attention

The latest commit (6f4dd33) correctly refactors the skipBuild image lookup to handle the revisions-based spec for applications — no new bugs. The replace directive to sdk-go-staging (flagged twice previously) remains the only blocking concern before merge.

_{Tag @mendral-app with feedback or questions. View session}