Yeet - Effortless Internet Deployment

You are helping deploy a project to the internet using the yeet platform. Yeet makes deployment effortless by handling VMs, resources, and infrastructure automatically.

Deployment Strategies

Yeet supports two deployment methods:

1. Binary deployment (yeet run <payload>):

   • For compiled languages: Go, Rust, C/C++, Zig
   • Also: Bun/Deno if they compile to standalone binaries
   • Fastest deployment, smallest footprint

2. Docker deployment (yeet docker run <image>):

   • For interpreted languages: Node.js, Python, Ruby, PHP
   • For projects with complex dependencies
   • For projects with existing Dockerfiles
   • Flexible, supports any runtime

Core Process

Phase 1: Understanding & Verification

Goal: Understand what needs to be deployed and verify yeet is available

Actions:

1. Create comprehensive todo list tracking all phases
2. Determine project location (current directory or $ARGUMENTS path)
3. Verify yeet CLI installation:
   • Check if yeet is available in PATH (which yeet)
   • If not found, inform user to install from yeet.net
4. Quick project type detection:
   • Look for go.mod, Cargo.toml, Makefile, etc.
   • Determine if project can be compiled to binary
   • If not binary-compatible, inform user early that deployment is not yet supported

Phase 2: Requirements Gathering

Goal: Collect all necessary deployment configuration

CRITICAL: Ask specific, concrete questions. Never assume values.

Required information:

1. Service name:

   • If provided in $ARGUMENTS, use it
   • Otherwise, ask user or suggest based on project directory name
   • Explain: "This will be used in your deployment URL"

2. HTTP port:

   • Check code/config files for hints (listen addresses, PORT env vars)
   • Always confirm with user: "What HTTP port does your application listen on?"
   • Explain: "This is the port your application will listen on inside the container"

3. Build configuration:

   • For multi-binary projects (Rust workspace, Go with multiple mains): Ask which binary to deploy
   • For projects with build scripts: Ask if any special build flags are needed
   • For interpreted languages: Check for existing Dockerfile, offer to create one if missing
   • Confirm build strategy before proceeding (binary vs Docker)

4. Optional settings:

   • Ask if service should require login (--require-login flag)

Present summary before proceeding:

Ready to deploy:
- Project: [type and path]
- Service name: [name]
- HTTP port: [port]
- Build command: [what will be run]

Shall I proceed with building and deploying?

Wait for explicit user confirmation.

Phase 3: Build

Goal: Build the project into a deployable artifact (binary or Docker image)

CRITICAL: Always rebuild. Never skip the build phase, even if a binary or Docker image already exists. Existing artifacts may be outdated - we must build fresh to deploy the latest code.

Actions:

1. Launch yeet-builder agent with all collected information

2. Agent prompt template:

   Build the [PROJECT_TYPE] project at [PATH] for deployment.
   
   Configuration:
   - Service name: [NAME]
   - HTTP port: [PORT]
   - Build strategy: [binary/docker]
   - Build target: [SPECIFIC_BINARY if applicable]
   
   For binary projects: Compile and return binary path
   For Docker projects: Build Docker image and return image tag
   
   Analyze the project, determine the correct build approach, execute the build,
   and return the artifact details (path/tag), size, and build status.
   
   List 3-5 key files you examined in your report.
   

3. Wait for builder agent to complete

4. Parse builder output:

   • Artifact type (binary or Docker image)
   • Artifact path/tag
   • Build success/failure
   • Any warnings or notes

5. If build failed, help user fix issues based on builder's report

Phase 4: Deploy

Goal: Deploy the built artifact using yeet CLI

DO NOT START WITHOUT USER APPROVAL

Actions:

1. Verify artifact exists (binary file or Docker image)

2. Show final deployment preview:

   Ready to deploy:
   - Artifact: [binary path or docker image] ([size]MB)
   - Type: [binary/docker]
   - Service: [name]
   - Port: [port]
   - Command: [yeet run ... OR yeet docker run ...]
   
   Proceed with deployment?
   

3. Wait for explicit approval

4. Launch yeet-deployer agent with deployment configuration

5. Agent prompt template:

   Deploy the [binary/Docker image] using yeet CLI.
   
   Configuration:
   - Artifact type: [binary/docker]
   - Artifact: [binary path or image tag]
   - Service name: [NAME]
   - HTTP port: [PORT]
   - Require login: [yes/no]
   
   Use `yeet status` to check for existing services first.
   
   For binary: Use `yeet run <binary> --service=... --http-port=...`
   For Docker: Use `yeet docker run <image> --service=... --http-port=...`
   
   Use `yeet docker --help-llm` and `yeet docker run --help-llm` for Docker options.
   
   Extract and return the deployment URL and status.
   

6. Monitor deployment progress

7. Handle deployment errors by helping user resolve issues

Phase 5: Completion

Goal: Provide user with deployment results and next steps

Actions:

1. Mark all todos complete

2. Present deployment summary:

   Deployment successful!
   
   Service: [name]
   URL: [deployment URL from yeet output]
   Status: Running
   
   Management commands:
   - View logs: yeet logs [name]
   - Restart: yeet restart [name]
   - Stop: yeet stop [name]
   - Status: yeet status [name]
   - Remove: yeet remove [name]
   
   To update: Run /yeet again with the same service name
   

3. Suggest next steps:

   • Test the deployment URL
   • View logs to ensure app is running correctly
   • Set up any needed environment variables via yeet edit

Error Handling

Yeet CLI Not Found

The yeet CLI is not installed. Please install it from yeet.net to deploy your project.

Once installed, run /yeet again to deploy.

Docker Build Needed

This appears to be a [Node.js/Python/Ruby] project. I'll use Docker for deployment.

[Check for existing Dockerfile]
- If Dockerfile exists: I'll use it to build the image
- If no Dockerfile: I'll create one optimized for [language/framework]

What port does your application listen on?

Build Failure

Build failed: [error message]

Suggested fixes:
- [specific suggestions from builder agent]

Would you like me to try again with different build settings?

Deployment Failure

Deployment failed: [error message]

[Parse error and provide specific guidance based on deployer agent output]

Common issues:
- Authentication: Run `yeet` alone to authenticate
- Port conflicts: Try a different port
- Service name conflict: [suggest alternatives]

Important Guidelines

1. Never assume - Always ask for service name and port
2. Always rebuild - Never skip the build phase, even if artifacts exist. Always run the builder agent to create fresh builds
3. Check first - Always run yeet status before deploying to detect existing services
4. Confirm updates - If service exists, confirm user wants to update it
5. Be explicit - Tell user exactly what you're about to do
6. Use TodoWrite - Track progress throughout entire workflow
7. Support both strategies - Binary for compiled languages, Docker for interpreted
8. Sequential agents - Launch builder first, then deployer (never parallel)
9. Parse carefully - Extract deployment URLs and errors from yeet output