When to Use uc build
Learn when to build images separately from deployment and when to let uc deploy handle it automatically.
The Default: uc deploy
For most users, uc deploy is all you need:
uc deploy
This automatically:
- Builds images for services with
buildsections - Pushes images to cluster machines
- Deploys containers
Use this when:
- You're iterating quickly during development
- You want the simplest workflow
- You're deploying from your local machine
When to Use uc build
Use uc build separately when you need more control over the build process.
1. Test Builds Without Deploying
Verify your build works before deploying:
# Test the build
uc build
# If successful, deploy later
uc deploy --no-build
Use case: You changed your Dockerfile and want to ensure it builds successfully without affecting running services.
2. Build Once, Deploy Multiple Times
Build the image once and deploy to different environments:
# Build the image
uc build
# Deploy to staging
uc deploy --no-build -m staging1
# Deploy to production (same image)
uc deploy --no-build -m prod1,prod2
Use case: Ensures staging and production run identical images.
3. CI/CD Pipelines
Separate build and deploy stages in your pipeline:
# .github/workflows/deploy.yml
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Build images
run: uc build --build-arg VERSION=${{ github.sha }}
- name: Run tests
run: docker run myapp:latest pytest
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- name: Deploy
run: uc deploy --no-build --yes
Use case: Run tests on built images before deploying.
4. Build Specific Services
Build only services that changed:
# Only rebuild the frontend
uc build frontend
# Deploy both frontend and API (API reuses cached image)
uc deploy frontend api --no-build
Use case: Multi-service apps where only some services changed.
5. Debug Build Issues
Troubleshoot build problems in isolation:
# Build with verbose output
uc build --no-cache
# Check the built image
docker images
# Test the image locally
docker run -p 8000:8000 myapp:latest
Use case: Build is failing and you need to debug without affecting deployments.
6. Push to External Registry
Build and push to Docker Hub or other registries:
# Build image
uc build
# Push to Docker Hub
uc build --push-registry
# Deploy from registry
uc deploy --no-build
Use case: Share images across teams or clusters.
7. Pre-warm Cluster with Images
Push images to cluster machines without deploying:
# Build and push to all machines
uc build --push
# Deploy later (images already available)
uc deploy --no-build
Use case: Large images where you want to distribute them in advance.
Comparison Table
| Scenario | Command | Why |
|---|---|---|
| Quick iteration | uc deploy | Simplest workflow |
| Test build | uc build | Verify build without deploying |
| CI/CD build stage | uc build | Separate build from deploy |
| Run tests on image | uc build then test | Test before deploy |
| Deploy to multiple envs | uc build then uc deploy per env | Same image everywhere |
| Build specific services | uc build service | Granular control |
| Push to registry | uc build --push-registry | Share images externally |
Build and Deploy Workflows
Workflow 1: Integrated (Default)
uc deploy
Flow:
Code → Build → Push → Deploy
Best for: Development, single deployments
Workflow 2: Separated
uc build
uc deploy --no-build
Flow:
Code → Build
↓
Push → Deploy
Best for: Testing builds, multiple deployments
Workflow 3: CI/CD
# CI stage
uc build --build-arg VERSION=$CI_COMMIT
# Test stage
docker run myapp:latest npm test
# Deploy stage
uc build --push
uc deploy --no-build --yes
Flow:
Code → Build → Test → Push → Deploy
Best for: Production deployments, automated pipelines
Workflow 4: Registry-based
# Build locally or in CI
uc build
# Push to registry
uc build --push-registry
# Deploy from registry (on any machine)
uc deploy --no-build
Flow:
Code → Build → Registry → Deploy
Best for: Team workflows, multiple clusters
What About --no-build?
The --no-build flag tells uc deploy to skip the build step:
uc deploy --no-build
Use when:
- Images were built separately with
uc build - Using pre-built images only (no
buildsections) - Images were built externally
Behavior:
- Deploys using existing images
- Fails if images don't exist on cluster machines
- Faster deployment (no build time)
What Gets Built?
By default, uc build and uc deploy build all services with build sections:
services:
frontend:
build: ./frontend # Built
api:
build: ./api # Built
db:
image: postgres:16 # Not built (no build section)
Build specific services:
uc build frontend
Build with dependencies:
uc build api --deps
Common Patterns
Pattern 1: Development Loop
# Edit code
vim src/app.py
# Quick deploy (build included)
uc deploy
Pattern 2: Pre-deployment Testing
# Build first
uc build
# Test locally
docker run myapp:latest npm test
# If tests pass, deploy
uc deploy --no-build
Pattern 3: Multi-environment
# Build once
uc build --build-arg ENV=production
# Push to all machines
uc build --push
# Deploy to staging
uc deploy --no-build -m staging1
# Later, deploy to production
uc deploy --no-build -m prod1,prod2
Pattern 4: Selective Rebuilds
# Only frontend changed
uc build frontend
# Deploy both (API reuses old image)
uc deploy --no-build
Decision Tree
Need to deploy?
├─ Yes
│ ├─ Images built recently? → uc deploy --no-build
│ └─ Need fresh build? → uc deploy
└─ No (testing/CI)
├─ Just testing build? → uc build
├─ Running tests? → uc build → test → uc deploy --no-build
└─ Pushing to registry? → uc build --push-registry
Next Steps
- Build Options - Learn about build args, caching, and optimization
- Pushing Images - Understand image distribution to clusters and registries
- Deploy from Dockerfile - See practical examples of building and deploying