Skip to main content

​
What It Does

Your backend services - API servers, workers, background jobs - need to run somewhere. The best approach is putting them inside containers that can run on any cloud VM. After Monk analyzes your code, it autonomously containerizes the components that need it, tests them, and prepares them for deployment. No Dockerfiles required (but they’re used if you have them).

​
How Containerization Works

​
Automatic Container Creation

After code analysis, Monk identifies which components need containerization:
  • API servers - Express, FastAPI, Spring Boot, Go HTTP servers, etc.
  • Backend services - Node.js, Python, Go, Java, Ruby, .NET services
  • Workers - Celery, Sidekiq, background job processors
  • Scheduled tasks - Cron jobs, periodic workers
For each component, Monk either uses your existing container configuration or generates one from scratch.

​
Using Existing Dockerfiles

If you have a Dockerfile or Containerfile, Monk will:
  1. Attempt to build it - Uses your existing configuration
  2. Test the container - Boots it up to verify it works
  3. Iterate if needed - If there are issues, Monk fixes them automatically
  4. Optimize if possible - Suggests improvements for security and performance

​
Generating New Dockerfiles

If no Dockerfile exists, Monk generates one using best practices: Multi-stage builds - Separate build and runtime stages to minimize image size 
# Example of what Monk generates for a Node.js API
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
Key characteristics:
  • Small base images - Alpine Linux or distroless when possible
  • Security hardened - Non-root users, minimal attack surface
  • Optimized layers - Proper caching for faster builds
  • Framework-specific - Tailored to Django, Rails, Spring Boot, etc.

​
Testing & Iteration

Monk doesn’t just generate containers - it validates they work:
  1. Builds the container - Locally in your IDE
  2. Starts the container - Tests if the service boots properly
  3. Checks health - Verifies the service responds correctly
  4. Fixes issues - If problems occur, Monk iterates to resolve them
Example iteration: 
Monk: Built container for API server
Monk: Testing... Port 3000 not accessible
Monk: Issue found - missing EXPOSE directive
Monk: Fixed Dockerfile, rebuilding...
Monk: Testing... Success! Container running on port 3000

​
Local Build + CI/CD Integration

Containerization happens in two places: Locally - Right in your IDE when you first deploy
  • Monk builds containers on your machine
  • You can test and verify before deployment
  • Fast iteration during development
CI/CD - Automatic rebuilds on code changes
  • Monk configures your CI/CD pipeline
  • Containers rebuild automatically when you push changes
  • Always up-to-date images in production

​
Zero-Config Container Registry

Every Monk deployment includes a private container registry - no setup required:
  • Secure storage - Your container images stored securely
  • Direct push - From your machine or CI workflow
  • Fast deployment - Images pushed directly to runtime environment
  • No external services - No need for Docker Hub, ECR, or GCR accounts
BYOI principle: The container registry runs on your infrastructure, just like everything else Monk manages. Your images never leave your control.

​
How Orchestration Works

​
Monk’s Built-in Orchestrator

Monk features a distributed orchestrator that manages all your containers regardless of where they run. Unlike traditional tools, Monk doesn’t use Kubernetes under the hood. Why containers are first-class citizens in Monk:
  • Direct control - Monk manages containers natively
  • Multi-cloud aware - Works seamlessly across AWS, GCP, Azure, DigitalOcean
  • Unified control plane - One system for everything (replaces both Terraform and Kubernetes functions)
  • Resource efficient - No K8s overhead or complexity

​
Key Orchestrator Capabilities

Live resource tracking:
  • Real-time resource graph of your entire infrastructure
  • Understands dependencies and relationships
  • Tracks lifecycle of every component
Advanced networking:
  • Automatic network segmentation
  • Encrypted connections between services
  • Works across regions and cloud providers
  • See Networking for details
Cost awareness:
  • Determines cost of each resource over time
  • See Cost Tracking for real-time monitoring
Multi-cloud orchestration:
  • Manages containers across different cloud providers simultaneously
  • One-command cluster spin up
  • Works on-prem too
  • See Multi-Cloud Support for details

​
Universal Container Support

While Monk provides a private registry, it can pull from anywhere:
  • Docker Hub
  • AWS ECR
  • Google Container Registry
  • Azure Container Registry
  • Private registries
Just tell Monk to configure one - you’ll need to provide the address and credentials.

​
Example: Multi-Service Application

Let’s see containerization in action with a Python + Node.js application: Your application:
  • FastAPI backend (Python)
  • React frontend (doesn’t need containerization - goes to Netlify)
  • Celery worker (Python)
  • PostgreSQL database (managed service - no container needed)
What Monk does:
  1. Analyzes components - FastAPI and Celery need containers
  2. Generates Dockerfiles: 
    # FastAPI
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

# Celery
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["celery", "-A", "tasks", "worker"]
  3. Builds and tests both containers locally
  4. Pushes to registry in your cloud account
  5. Deploys containers with proper orchestration

​
What Makes This Different

Traditional containerization requires:
  • Writing Dockerfiles for each service
  • Understanding Docker best practices
  • Setting up container registries (Docker Hub, ECR, etc.)
  • Configuring Kubernetes or Docker Swarm
  • Writing orchestration configs (K8s manifests, Helm charts)
  • Setting up CI/CD for container builds
  • Managing container security and updates
With Monk: Containers are created, tested, stored, and orchestrated automatically. You just write application code.

​
Key Capabilities

  • Automatic Dockerfile generation - Best practices built in
  • Multi-language support - Node.js, Python, Go, Java, Ruby, .NET, etc.
  • Existing config support - Uses your Dockerfiles if present
  • Automated testing - Validates containers boot correctly
  • Self-healing - Fixes issues during containerization
  • Local + CI/CD builds - Build locally, rebuild automatically on push
  • Zero-config registry - Private container registry included
  • No Kubernetes required - Native container orchestration
  • Multi-cloud orchestration - Containers managed across any cloud
  • Universal registry support - Pull from any container registry