Skip to main content
Alpha Feature - Source code editing is currently in alpha. Monk makes targeted fixes to resolve deployment issues, not general code refactoring.

​
What It Does

When deploying your application, Monk may discover issues in your source code that prevent successful deployment - wrong ports, missing environment variables, incorrect connection strings, or Dockerfile problems. Instead of just reporting these issues, Monk can fix them directly in your code. Monk makes targeted, deployment-focused code edits to get your application running successfully.

​
How It Works

​
When Monk Edits Code

During deployment, if Monk encounters fixable issues: Example - Wrong Port Configuration: 
Monk: I found an issue: Your server listens on port 8080,
      but the Dockerfile exposes port 3000.

      I can fix this in server.js. Should I proceed?

You: Yes, fix it

Monk: [Makes targeted change to port configuration]
      Fixed! Server now uses port 3000 to match Dockerfile.
Monk shows you a diff of the proposed changes before applying them. You can:
  • Approve - Apply the fix
  • Reject - Skip this fix
  • Revert - Undo after seeing the result

​
Types of Fixes Monk Makes

Deployment-related fixes:
  • Port configuration - Aligning server port with Dockerfile EXPOSE
  • Environment variables - Reading from correct env var names
  • Connection strings - Fixing database URLs, Redis hosts
  • Build commands - Correcting package.json scripts, Makefiles
  • Entry points - Fixing main files, startup commands
Containerization fixes:
  • Dockerfile issues - EXPOSE directives, CMD/ENTRYPOINT
  • Build scripts - Missing build steps, incorrect paths
  • Health checks - Adding or fixing health check endpoints
  • Dependencies - Critical missing dependencies for deployment
Configuration fixes:
  • Config file paths - Fixing paths that work locally but fail in containers
  • Static file serving - Correct asset paths for containerized apps
  • API endpoints - Environment-aware endpoint configuration

​
What Monk Does NOT Edit

Monk’s code editing is not for general development. It won’t:
  • ❌ Add new features to your application
  • ❌ Refactor code for better structure
  • ❌ Fix business logic bugs
  • ❌ Optimize performance (unless deployment-blocking)
  • ❌ Modify your application’s core functionality
Scope: Deployment enablement only, not software development.

​
Files Monk Can Edit

​
Source Code Files

  • JavaScript/TypeScript: *.ts, *.tsx, *.js, *.jsx, *.mjs, *.cjs
  • Python: *.py
  • Go: *.go
  • Java/Kotlin: *.java, *.kt
  • Rust: *.rs
  • Ruby: *.rb
  • PHP: *.php
  • C/C++: *.c, *.cpp, *.h, *.hpp
  • Shell scripts: *.sh, *.bash

​
Build & Configuration Files

  • Package files: package.json, requirements.txt, go.mod, Cargo.toml, Gemfile, composer.json
  • Build configs: tsconfig.json, jsconfig.json, pyproject.toml, Makefile, Procfile
  • Docker: Dockerfile, docker-compose.yml
  • CI/CD: .github/workflows/*.yml, netlify.toml, vercel.json

​
Files Monk Cannot Edit

  • 🚫 Monk templates - MANIFEST, *.yaml (use template editor instead)
  • 🚫 Environment files - .env, .env.production (security)
  • 🚫 Lock files - package-lock.json, yarn.lock, etc. (integrity)
  • 🚫 Generated files - dist/, build/, target/ directories
  • 🚫 Binary files - Images, fonts, archives

​
Example Scenarios

​
Scenario 1: Port Mismatch

Problem: Dockerfile exposes 3000, but Express app listens on 8080 Monk’s fix: 
// server.js - BEFORE
const port = 8080;
app.listen(port);

// server.js - AFTER (Monk's fix)
const port = process.env.PORT || 3000;
app.listen(port);
Why: Aligns code with containerization expectations

​
Scenario 2: Missing Environment Variable

Problem: App crashes because DATABASE_URL not read from environment Monk’s fix: 
# config.py - BEFORE
DB_URL = "postgresql://localhost/mydb"

# config.py - AFTER (Monk's fix)
import os
DB_URL = os.environ.get("DATABASE_URL", "postgresql://localhost/mydb")
Why: Makes app work with Monk’s configuration injection

​
Scenario 3: Incorrect Connection String

Problem: Hardcoded localhost Redis connection fails in production Monk’s fix: 
// redis.js - BEFORE
const redis = new Redis({ host: 'localhost', port: 6379 });

// redis.js - AFTER (Monk's fix)
const redis = new Redis({
  host: process.env.REDIS_HOST || 'localhost',
  port: parseInt(process.env.REDIS_PORT || '6379')
});
Why: Allows Monk to inject correct Redis connection details

​
Scenario 4: Dockerfile Build Issue

Problem: Dockerfile COPY command fails because path is wrong Monk’s fix: 
# Dockerfile - BEFORE
COPY src/app /app

# Dockerfile - AFTER (Monk's fix)
COPY ./src /app/src
Why: Fixes containerization build errors

​
Approval & Review Process

​
You Stay in Control

Every code edit goes through review: 1. Monk proposes changes: “I found 3 issues I can fix in your code. Should I proceed?” 2. Monk shows diffs: You see exactly what will change (side-by-side diff in IDE) 3. You decide:
  • Approve all fixes
  • Approve specific fixes
  • Reject and handle manually
  • Ask Monk to try a different approach
4. Changes applied: Monk writes the approved changes to your files 5. You can revert: If something doesn’t look right, ask Monk to revert Changes tracked so rollback is always possible

​
When Code Editing Happens

​
During Deployment

Most commonly, during initial deployment: 
deploy this project
Monk may find:
  • Container build fails due to Dockerfile issue
  • App crashes on startup due to config problem
  • Health check fails due to wrong port
Instead of stopping, Monk proposes fixes to resolve these issues.

​
On Demand

Ask Monk to fix specific deployment problems: 
fix the Dockerfile build error

update my code to use environment variables

fix the port configuration for deployment
Monk examines the issue and proposes targeted fixes.

​
After Failed Deployments

If a deployment fails due to code issues: 
Monk: Deployment failed. The API server expects REDIS_URL 
      but your code only reads REDIS_HOST and REDIS_PORT.
      
      I can update your code to read from REDIS_URL instead.
      Should I fix this?

​
Limitations

​
Alpha Status

This is an alpha feature:
  • Works well for common deployment issues
  • May not catch all edge cases
  • Best for straightforward codebases
  • Complex fixes may need human review
Monk errs on the side of caution - if unsure, it will ask rather than make potentially incorrect changes.

​
Not a Code Generator

Monk does not:
  • Generate new features
  • Write application logic
  • Implement business requirements
  • Create new components or modules
Use your regular coding assistant for application development. Use Monk’s code editor for deployment fixes.

​
File Type Restrictions

  • Cannot edit template files (use Monk template editor)
  • Cannot edit secrets (.env files)
  • Cannot modify lock files or generated code
  • Focused on source files and build configs

​
What Makes This Different

Traditional deployment error resolution:
  1. Deploy fails
  2. Read error logs
  3. Search for solution
  4. Edit code manually
  5. Redeploy
  6. Repeat if still broken
With Monk code editing:
  1. Deploy
  2. Monk detects and diagnoses issue
  3. Monk proposes fix with diff
  4. You approve
  5. Monk applies fix and redeploys
  6. Success
Faster iteration from error to resolution.

​
Safety & Security

How Monk keeps editing safe:
  • ✅ Diff approval required - You see and approve all changes
  • ✅ Minimal changes - Only fixes what’s needed, preserves your code style
  • ✅ Revertible - Can undo changes if needed
  • ✅ Scoped to deployment - Won’t modify business logic
  • ✅ File type restrictions - Cannot edit secrets or templates
  • ✅ No arbitrary edits - Only deployment-focused fixes
Your code stays yours - Monk assists with deployment issues, you control all changes.

​
Best Practices

​
1. Review All Diffs

Always review what Monk changes:
  • Check the diff makes sense
  • Verify it aligns with your code style
  • Ensure no unintended side effects

​
2. Test After Fixes

After Monk fixes code:
  • Verify the deployment works
  • Test the affected functionality
  • Ensure nothing broke

​
3. Commit Fixed Code

Once deployment succeeds with Monk’s fixes:
  • Commit the changes to version control
  • Document what was fixed and why
  • Share with team if relevant

​
4. Use for Deployment Issues Only

Don’t ask Monk to:
  • “Refactor this function”
  • “Add a new API endpoint”
  • “Optimize this algorithm”
These are outside Monk’s code editing scope.

​
Future Enhancements

As the feature matures: Improved detection - Catch more subtle deployment issues Smarter fixes - Context-aware changes that better match your code style Learning - Remember your preferences for future fixes Broader scope - Support more file types and frameworks